En général, j’utilise la notation .ma-classe-css pour nommer les classes réutilisables par n’importe quel élément HTML. Cette notation est en fait un raccourci pour *.ma-classe-css où * est utilisé comme joker universel (les tirets ne sont là que pour le référencement).
Me souvenant que le reset * { margin: 0; padding: 0; } n’était pas optimum en terme de performances, je me suis dit que l’utilisation de div.ma-classe-css (en préfixant le nom de la classe avec la balise HTML à laquelle elle s’applique) permettrait certainement au navigateur de parcourir le DOM plus rapidement en raison du nombre réduit d’éléments sur lesquels boucler.
Et … ?
Tu as fait un bench sur les différents navigateurs des différentes plateformes ? Je pense qu’il faudrait s’adresser aux constructeurs des navigateurs pour valider auprès d’eux leur préconisations (et espérer qu’elles coïncident).
C’est probablement exact mais je ne sais pas si la différence sera(it) réellement perceptible comparé au temps global d’affichage d’une page.
À propos, si le reset * { margin: 0; padding: 0; } n’est pas optimum, que faut-il plutôt utiliser ?
@comme une image > J’ai écrit pas mal de billets sur le sujet des reset CSS dont notamment 5 resets à la loupe : suivi de la mise à jour du reset d’Eric Meyer et pour finir une traduction des frameworks CSS qui contient des éléments de resetting 😉
Pour des infos concernant les performances du reste global cf. l’article paru sur developper mozilla
Voui la théorie tient la route !
Mais le truc c’est de savoir dans quel ordre le navigateur parse le document xhtml pour appliquer la feuille de style.
Car il suffirait qu’il check d’abord les classes et les id (attributs) avant les noms de balise, et du coup c’est l’effet inverse qui se produit. Ceci dit il serrait illogique qu’il ne commence pas d’abord par checker la structure dom ^^
Ps: ahhh cool l’abonnement est réapparu 😀
Wahou ! Merci pour cette riche réponse… (J’ai encore tellement de choses à apprendre ! et je me réfugie derrière cette chimère de vouloir faire parfait du premier coup pour ne pas me lancer et commencer enfin à créer mon thème WP !)
Cela étant, pour le dernier lien donné, sur Mozilla, il permet d’avoir des éléments sur Firefox mais pas sur les autres navigateurs. Or, s’il n’y avait que Mozilla, on n’aurait pas besoin de reset CSS 😉 Il ne reste donc qu’à espérer que ce qui est vrai pour FF le soit à peu près pour IE et Opéra, mais rien de certain…
D’ailleurs, ce lien Mozilla donne la réponse à ta question !!!
Don’t qualify class-categorized rules with tag names
Similar to the rule above, all of our classes will be unique. The convention you should use is to include the tag name in the class name.
* BAD – treecell.indented { }
* GOOD – .treecell-indented { }
@comme une image >
J’avoue n’avoir jamais vraiment compris cette section. D’un côté, je comprends qu’il ne faut pas ajouter le tag à la classe, puis que « chacune de nos classes seront uniques », ce qui va à l’encontre de l’idée de classes, mais que nous devrions préfixer la classe avec le tag, et enfin, l’exemple BAD vs GOOD qui ne me parle absolument pas ^^
Si quelqu’un peut expliciter ces subtilités, merci d’avance !
Je ne prétendrais pas détenir l’interprétation exacte de ce que j’ai lu là-bas, n’ayant qu’une connaissance bien imparfaite des CSS (par exemple, faudrait que je me replonge dans une doc pour comprendre la notation xxx > yyy) et moins encore du fonctionnement des navigateurs, mais voilà ce que, moi, j’ai compris :
1/ à partir du moment où l’on utilise un id, inutile de préciser à quel tag il s’applique puisque, par définition, un id est (censé être) unique et ne s’applique donc qu’à un seul élément de la page, quel que soit son tag.
2/ le truc sur les classes, disent-ils, est similaire à cette règle ci-dessus. En gros, si tu précises une classe, pas la peine de se fatiguer à indiquer le tag parce que, là encore, une fois que le parser a chopé la classe, pas la peine de lui indiquer du boulot supplémentaire.
Bon, moi, ce que j’en comprends, c’est qu’en conséquence, il ne faut pas utiliser le même nom de classe pour des tags différents, et d’ailleurs, ils conseillent d’utiliser le tag dans le nom de classe pour lever toute ambiguïté.
Ce qui donne un truc du genre :
BAD :
HTML => < div class= »orce » …
CSS => div.orce { …
GOOD :
HTML => < div class= »div-orce » …
CSS => .div-orce { …
Autrement dit, pour en revenir à ton article : ton intuition ne serait pas juste.
oups j’ai oublié les ;
Ça ne te tente pas d’essayer « WP AJAX Edit Comments » ? 😉
(et puis on n’est pas en April !)
@comme une image > yep, tu as l’air d’avoir saisi le truc, merci pour tes lumières 🙂
Pour l’édition des commentaires, faudra que je me penches dessus, car c’est effectivement une fonction dont je me sert quand elle est dispo chez les autres 😉
April, lol, oui, j’ai zappé la version française de wp 2.5, je mets ça dans les tuyaux aussi 😉
Ca y est j’ai installé la VF et ajouté le plugin wp ajax comment pour voir ce que ça donne 🙂
Pour la VF, c’est pratique pour avoir les date en français sur le blog, mais pour l’admin, certaines lignes sont un peu longue et bouffe un peu les fonctions, dans les widgets notamment…
test pour wp ajax edit comment
C’est vrai que pour les widgets, ça déconne un peu la mise en page (et je ne me suis même pas posé la question, je pensais que c’était itou en V.A. parce que j’utilise la V.F. depuis le début – accessoirement j’ai joué les relecteurs sur la traduction de la 2.5 donc s’il reste des coquilles, on peut me taper).
Mais en toute franchise, je ne modifie pas mes widgets très souvent, la gêne est donc modérée (et pour l’admin, je ne saurais trop te recommander si tu ne l’utilises pas encore Ozh’ Admin Drop Down Menu qui simplifie drôlement l’admin).
Merci, je testerais Ozh’… Par contre, le plugin wp ajax edit comment ne semble pas fonctionner chez moi 🙁
Hello,
Pour ma part j’ai tendance à utiliser des classes «génériques» nommées «title», «subtitle», «twocol», «normal», etc. Mais je ne les cible jamais directement, je passe toujours par le contexte:
div#latest-news h2 {}
div#latest-news p.subtitle {}
div#latest-news p.normal
div#main div.twocol .title {}
div#main div.twocol .normal {}
Des choses du genre.
Le seul inconvénient c’est si on désire ensuite utiliser le style de « div#main div.twocol .title » pour un élément ayant la classe « title » dans un autre conteneur. On aurait alors intérêt à avoir une classe spécifique à ce style et jamais utilisée dans le reste du site (ce qui disqualifie les noms génériques comme «title», «normal», etc.), et à utiliser cette classe aux endroits voulus. Sauf qu’on obtient le problème inverse: ça risque de ne pas être assez précis et pas facilement adaptable.
Dans tous les cas l’évolution du contenu (notamment l’arrivée des contenus non prévus au départ dans les maquettes graphiques ou les éventuelles maquettes ergonomiques) n’est jamais bien facile à gérer, je trouve. Si on veut factoriser les styles, on se retrouve à devoir réécrire des parties de feuille de style déjà faites, voire à modifier des templates.
J’essaye d’être le plus concis possible quand je dois créer une classe. Déjà parce que je déteste écrire des choses inutiles, ensuite parce que ça me fait un fichier CSS plus light au final – c’est aussi un gage de rapidité – et enfin parce que ça me permet d’éviter la surenchère à la spécificité. Donc, s’il n’y a pas besoin d’ajouter le tag, je ne le met pas. Je n’ai jamais rien lu qui indique que rajouter le nom de la balise devant la classe ou l’identifiant aide à une interprétation plus rapide de la part des navigateurs, je pense que ça se saurait depuis le temps que CSS existe. Par contre je fais toujours attention à la spécificité des différentes classes pour éviter les conflits. (http://www.yoyodesign.org/doc/w3c/css2/cascade.html#specificity).
Salut à tous,
voila une discussion bien intéressante, comme beaucoup d’autres sur ton blog Bruno. Je me permets d’apporter mes 2 cents comme disent les anglais 🙂
Je ne suis pas persuadé de l’augmentation des performances de la page en qualifiant plus ou moins les tags. Je rejoins l’avis de Frank quand il dit qu’il ne qualifie son tag que s’il y a une nécessité (entre paresseux on se comprends :-))
Si tu nous fais tout d’un coup une phobie sur la rapidité d’interprétation de ton code, réfléchis un peu à la longueur du nom de ta classe! Dans l’absolu, toutes ces infos doivent aussi arriver au navigateur qui doit les interpréter;
div#latest-news p.normal ul li.trimmed est bien plus long à passer que div#l p.n ul li.t ça en fait des caractères économisés !
Non franchement, une bonne structure hiérarchique, l’emploi parcimonieux de qualification des tags me semble être LA voie à suivre si tu veux accélérer l’interprétation du code.
Merci pour vos interventions.
Olivier
@Florent V. > Concernant le contexte, j’ai tendance à faire une peu la même chose, mais en re(lisant) les conseils de Mozilla, il semble que div#main {} soit moins « performant » que #main {}.
Là, encore, ça me parait assez logique. Par contre, ce que je trouve moins intuitif, c’est que .maclasse soit plus performant que div.maclasse.
Concernant le contexte, en fait il manque un « with » au css comme en javascript 😉
@Frank Taillandier > J’étais justement tombé sur une lecture qui allant dans le sens de spécifier la balise devant la classe, mais impossible de remettre la souris dessus 🙁
Après réflexion, si on part du principe que le navigateur fait un Array des balises d’une part et un Array des classes d’autre part, il est tout à fait possible que « div.maclasse » oblige les navigateurs à parcourir deux Array et à y effectuer des opérations complexes pour trouver l’intersection…
@Olivier > Je suis tout à fait d’accord avec tes conclusions. Quand à la phobie sur les performances, j’en suis loin 😉 En fait, je préfèrerais toujours une dénomination longue et compréhensible à une courte qui ne veut plus rien dire 15 jours après 😉
Disons, que depuis quelques temps, je prends conscience que je suis un grand gaspilleurs de ressources : je n’optimise pas suffisamment mes images, j’ai tendance à multiplier le nombre de CSS importées, alors de temps à autres, je bats ma coulpe pour me remettre les idées en place 😀
Sinon, dans le genre phobie, j’ai lu plein de fois que certain omettait les point-virgule après la dernière déclarations pour économiser un signe… Là, je crois que c’est grave 😉
Je pensais trouver un vraie réponse avec plein de tests dans ton article, je suis un peu déçu là! 😀
Ces trucs de reset, c’est vraiment du travail d’amateur.
Si les marges d’un élément posent problème, il suffit les spécifier. Inutile de mettre tout le monde à zéro pour re-spécifier ensuite. 😐 Ça c’est du gaspillage de temps et de perf à grande échelle.
@David > héhé, à défaut de trouver une vraie réponse, ça fait peut-être une vraie question à résoudre de manière collective 😀
Sur les reset CSS : plutôt que de faire du reset plus ou moins sélectif tout au long de la feuille de style, j’ai opté pour un reset explicite pour me faciliter l’intégration.
En même temps, je pense avoir suffisamment expliqué les avantages et les inconvénients des reset pour me sentir à l’aise sur le sujet. Donc OUI, le reset CSS n’est pas forcément la panacée, mais NON ce n’est pas forcément n’importe quoi non plus ^^
la VF, c’est pratique pour avoir les date en français sur le blog, mais pour l’admin, certaines lignes sont un peu longue et bouffe un peu les fonctions, dans les widgets notamment…
Salut,
Eric a fait un article sur le sujet, http://performance.survol.fr/2008/05/performance-des-selecteurs-css/