Reprise du message précédent :

C'est un processus (OS) par onglet

Sans aucune primitive de locking ou autre? Yeah right...

Arrête de faire ton pédant là
 
Je suis parfaitement d'accord sur le fait de faire un style général sur les strong. Et après on modifie au coup par coup

http://www.quirksmode.org/blog/arc [...] _br_1.html

 
Par contre, on peut la jouer coopératif, faire des ptits bouts de boulot et relacher la main régulièrement pour pas tuer la machine.

Ca change rien à ce que je dis
Surtout que comme le dit Nazztazz strong et gras ne sont liés que d'usage. Et surtout parce que les personnes qui veulent mettre en avant du texte utilisent du gras (ça devrait d'ailleurs être de l'italique, Yell?) car c'est ce qui est le plus visible.
 

Et si y'a pas de JS y'a pas de coloration, et on emmerde l'utilisateur pour qu'il déclenche la coloration, et puis c'est relativement lourd. Donc oui y'a des solutions coté client mais c'est pas forcément le plus fiable/performant.
 
D'ailleurs tu prends l'exemple du forum qui rame quand la page à highliter est trop large, je suis pas sur que pygments se comporte pareil avec les mêmes données par exemple ( a vérifier, mais il me semble qu'il y'a un benchmark qui traine somewhere )
 

Pour le gras ok, pour la couleur pas ok.
Ou est l'intérêt? D'un point de vue sémantique c'est moisi, autant limiter au strict minimun le style de ce genre de balise. Faut penser au coté pratique/maintenance un peu, surtout quand on pense ses css orienté objet ou domaine.

Il passe encore?
 
edit:

Ouip, florentP c'est nijule

Je crois que c'est ça ouais

Design, esthétique... Genre le texte en gris foncé, et les strong en gras + noir pour bien les renforcer. Y'a des polices dont le gras est assez léger

Il s'avère que dans mon cas, le designer passe certains mots important en gras et dans une autre couleur.
C'est pour cela que je voulais styler la balise strong.

5 Amazing HTML5 Features to Look Forward to

Si le forum rame c'est que la fonction de coloration sytaxique est null niveau performance. Il n'y a qu'à ouvrir n'importe quel IDE/editeur de texte pour voir qu'ils ne faut pas 30 secondes pour faire la coloration syntaxique d'un code de quelques milliers de caractères

Et c'est toujours un séide de Joce ?

Sûrement.

Je suis bien d'accord, mais ça semble interessant/performant dans certains cas où la charge pour le serveur peut être trop importante vu que google code l'utilise

A voir comment la coloration est faite dans les IDE, si tout le code est directement coloré à l'ouverture ou au fur et à mesure / threadé, le forum doit obligatoirement colorer tout le code avant d'envoyer la page ! Puis j'imagine que le serveur HFR a d'autres choses choses à faire que colorer du code, donc normal qu'il soit plus lent qu'un PC qui n'a que ça a faire !

C'est pas vraiment comparable !

c'est quoi déjà le raccourci d'écriture php pour éviter d'écrire if () {} else {} ??

( test ) ? vrai :  fuax ;

ok merci

simplement appelé opérateur ternaire

rassurez moi, 0,8s pour générer une page en php, c'est énorme non?
Quand je vois le temps de génération sur HFR, je pense que oui c'est énorme

ça dépend de ce que tu fais sur ta page ? si tu fais du traitement d'image ou un truc lourd en BDD

 
Ça dépend du contenu, mais ça me semble beaucoup oui

question débile en php, je suis en train de faire une petite appli de QCM, j'ai mis un DIV avec des informations de débug pour que je puisse voir l'état de mes variable PHP, variable de sessions etc...
 
sauf que mon div qui contient les instructions PHP pour afficher le debug est AVANT le code de l'appli... PHP ne traite pas toute la page avant de l'exécuter?

bah justement, ça fait pas grand chose à part récupérer des données en BDD et les afficher, mais je soupçonne une grosse uzinagaz avec des milier d'include pour pas grand chose, il fait dans les 90 query alors qu'a mon avis on pourrait réduire ce nombre de moitié en faisant des requêtes un poil mieux pensées.
 
 
Bref je crois que j'vais tenter de tout refoutre à plat pur voir

ouai c'est du front office, c'pour ça que ça me parait énorme 800ms
pour le cache, normalement y'a smarty qui s'en occupe mais je suis pas convaincu
pour php apc je n'crois pas, je voulait m'y pencher dessus j'ai oublié entre temps

Commence surtout par profiler pour voir où le temps est perdu

 
non mais je crois que c'est ma structure qui est moisi, je fais faire un include en début de page de tous les tests et afficher ce qu'il faut sur ma page.

Habituellement, une page du forum met quelques centièmes de secondes à être générée. Lorsque que les gros flans se sont amusé à poster quelques centaines de lignes de codes sur blabla@prog, la page mettait plusieurs dizaines de secondes à être générée. On peut en tirer plusieurs conclusions:
-dans ce cas précis la coloration syntaxique était ce qui prenait le plus de temps dans la génération de la page.
-la coloration sytaxique est effectué à chaque demande de page ce qui est un gachis de performance monumental. Si la coloration était effectuée à la création/édition du post, on ne se rendrait même pas compte du pb de perfs.
-la coloration syntaxique est affreusement lente alors qu'elle ne devrait pas être fondamentalement plus complexe que l'interpretation du bbcode.
 
Avant de chercher des solutions débile comme faire la coloration syntaxique en JS, il faut chercher à comprendre pourquoi ça rame et comment on peut améliorer la situation à moindre frais.

0,8s pour 90 requêtes c'est pas mal
Par contre 90 requêtes pour une seule page c'est un poil monstrueux

j'viens de checker, je suis même pas sur que le cache de smarty soit actif en fait, c'est un sac de noeud cet appli
 

ouai, codé avec les pieds, c'est l'horreur, avec une espèce d'architecture à moitié MVC mais qu'au final c'est juste n'importe quoi

Un ptit peu si, y'a des langages avec des grammaires nettement plus complexes que du bbcode†, et ce même si le bbcode était géré par un vrai parseur au lieu de la soupe buggée actuelle. Après on peut aussi avoir un bbcode foireux ET une coloration foireuse, du coup tout va plus vite \o/
 
†au point d'avoir besoin de type de parseur complètement différent, pas simplement parceque y'aurait plus de tokens différents.

Ca c'est complètement faux, surtout que sur HFR le BBCode est interprété avec un parser La Rache à grands coups de preg_replace

Je vais en avoir pas mal du temps, j'hésitais à commencer à tout refaire propre avec un framework genre zend, mais ça n'empèche que pour garder tout l'existant ça risque d'être bien galère
 
Y'a quand même des trucs que j'ai du mal à calculer comment c'est possible d'écrire ça :

define('USE_CACHE', false && (count($_GET) == 0) && (count($_POST) == 0));

chez moi FALSE && CE_QUON_VEUT, ça fait toujours FALSE  

ah ouai ça s'tiens, et non y'a pas de comm, d'ou mon incompréhension