WebDev-FR

Via un billet posté sur le blog de Rebecca Murphey (découverte grâce au lancement de JSMag), je suis tombé sur une présentation de Nicole Sullivan concernant les bonnes pratiques à adopter lors du développement de la couche CSS d’un site, pratiques qu’on pourrait plus ou moins assimiler à de la conception orientée objet appliquée aux CSS.

Ce qu’il faut en retenir (ce que j’en ai retenu)

L’un des principaux problèmes des feuilles de styles est leur tendance à gonfler, gonfler, gonfler ce qui les rend plus coûteuse en bande passante mais aussi en maintenabilité (sans compter les risques liés aux styles s’écrasant mutuellement).

La raison est relativement simple : il n’est pas forcément évident de réutiliser des styles déjà existants. On a tendance à concevoir les règles CSS par rapport au contenu d’une page, éventuellement à réutiliser ce qui a été fait sur une page similaire si les similitudes sont flagrantes.

Nicole recommande une approche bien plus pérenne : séparer la structure et le design (ce qui ne veut pas uniquement dire avoir une feuille de style externe mais se baser sur des classes CSS et non sur des balises particulières) et séparer le contenu du contenant.

En fait, il vaut voir une bonne conception CSS comme un assemblage de Legos : commencez par créer votre collection de briques. Une fois que la collection de brique est prête, vous pouvez commencer à créer vos pages, autrement dit vous pouvez commencer à assembler vos briques ensemble pour aboutir au résultat graphique attendu.

Les 10 best practices qu’elle cite :

1. Créez une bibliothèque de composants
2. Utilisez des styles en accord avec la sémantique
3. Concevez des modules avec un fond transparent
4. Soyez flexible
5. Apprenez à aimer les grilles
6. Minimisez l’emploi des sélecteurs
7. Séparez la structure et le design
8. Séparer le contenu et le contenant
9. Etendez les objets en appliquant plusieurs classes sur un élément HTML
10. Utilisez des feuilles de style de reset et de gestion des polices

Et les 9 choses à éviter :

1. Evitez les styles dépendants de l’endroit où vous vous trouvez sur le site
2. Evitez de créer des styles qui dépendent des balises utilisées
3. Limitez l’utilisation d’IDs : ils doivent se limiter aux zones principales, pour le reste utilisez des classes
4. Fuyez les coins arrondis ou les ombres appliqués par-dessus des fonds non-unis (image de fond ou dégradé).
5. Evitez de faire un sprite contenant toutes vos images, à moins que vous ayez qu’un faible nombre de pages
6. Tentez d’éviter les alignements sur la hauteur
7. Le texte c’est du texte, pas une image contenant du texte
8. Evitez la redondance
9. Evitez l’optimisation prématurée

Maintenant si on va un peu plus dans les détails pour certaines parties…

Séparez le contenu du contenant

Ca veut dire qu’un module est composé :

• d’une brique pour la gestion de la bordure (coin arrondis ou carrés, couleur, ombre)
• d’une brique pour le fond (fond uni, image de fond en filigrane, dégradé)
• d’un ensemble de briques pour le contenu

Autrement dit, un module devrait avoir 3 classes afin de définir à quoi doit ressembler sa bordure, quel est le fond à appliquer et comment le contenu doit être organisé.

Séparez la structure et le design

Prévoyez à l’avance la structure basique d’un bloc : faut-il un header dans un bloc ? faut-il un footer ?

De cette manière, créer un bloc se limitera à appliquer les bonnes classes (”block”, “hd”, “ft”, “bd”) au contenu du block.

Une fois que cette structure est définie, vous pouvez alors concevoir les différents design qui s’appliqueront sur cette structure : une brique avec des coins arrondis, une brique pour gérer le fond en dégradé, etc.

Faites des modules transparents

Si vous voulez des coins arrondis, préférez une solution où le coin est créé par l’extérieur et non par l’intérieur, autrement dit une solution où l’image du coin est transparente à l’intérieur et unie à l’extérieur. Cette solution vous permettra d’appliquer n’importe quel fond à l’intérieur de votre bloc, que ce soit une couleur unie ou une image en arrière-plan.

Bémol : le bloc ne pourra être placé que sur un fond correspond à la couleur extérieure de vos coins arrondis (typiquement le fond de votre page).

Soyez flexible

Faites de la gym. Faites en sorte que vos briques puissent s’adapter en largeur et en hauteur. En hauteur pour pouvoir s’adapter à la hauteur du contenu, en largeur pour pouvoir réutiliser votre brique dans n’importe quelle zone de votre grille même si la largeur varie.

C’est la grille qui doit gérer la largeur, les blocs doivent ignorer pour quelle partie de la grille ils ont été conçus.

Tentez une approche UML

Tentez de mettre en place un système d’héritage à vos briques.  Certaines briques seront compatibles ensemble (par exemple certaines briques de gestion de bordure ne pourront pas forcément être appliquées à n’importe quel brique d’arrière plan ou même de mise en forme du contenu).

Ces relations entre vos briques peuvent donner lieu à un schéma plus ou moins UML pour faciliter la compréhension des briques existantes.

Un exemple d’approche UML conçue par Nicole :

Approche UML pour la couche CSS d'un projet

Bref, plein de bonnes suggestions à tenter de mettre en pratique…

Sur Ajaxian, on peut trouver une petite liste des 10 choses les plus cool que nous serons capables d’appliquer lorsque IE6 ne sera plus.

Essayons de notre côté d’aller un peu plus loin que cette liste. Lorsque IE6 aura disparu, la nouvelle barrière sera IE7 mais l’abandon d’IE6 débloquera un tas de fonctionnalités CSS actuellement délaissées car incompatibles.

En vrac :

• l’utilisation du sélecteur CSS fils (>) afin de sélectionner les noeuds immédiatement en-dessous d’un noeud et non toute sa descendance.
• j’aurais bien dit le sélecteur de noeuds adjacents (+) mais il est un poil buggé sur IE7
• le sélecteur par attribut ([attr]) pour sélectionner des noeuds en fonction de la présence d’un attribut et de sa valeur, idéal pour différencier les éléments INPUT d’un formulaire (bouton, champs texte, bouton radio, case à cocher, bouton d’envoi, etc).
• la bonne gestion des classes multiples, actuellement un tantinet foireuse sur IE6
• le :hover sur n’importe quoi et pas uniquement sur les liens
• :first-child, pour sélectionner le premier fils d’un noeud
• le display:inline-block pour les éléments initialement avec un display:inline
• display:list-item
• min-width, max-width, min-height, max-height
• utilisation correcte du overflow:visible
• position:fixed
• le sélecteur de précédence (~) permettant de sélectionner un noeud en fonction d’un noeud qui le précéde. Le sélecteur d’adjacence (+) implique que le noeud adjacent précéde immédiatement le noeud ciblé alors que le sélecteur de précédence (~) permet d’avoir des noeuds entre le noeud ciblé et le noeud qui précéde.

Bref, plein de nouvelles choses qui nous permettront de nous arracher un peu moins les cheveux. Mais bon, en attendant, vous allez continuer à vous les arracher par poignées, IE6 est encore coriace…

Il existe une quantité considérable de règles de bon usage, de trucs, de bidouilles voir même d’outils professionnels pour optimiser la couche CSS d’un site.

Néanmoins, une branche de ce domaine qui a été assez peu analysée est l’impact de l’utilisation des sélecteurs CSS et surtout la nécessité, ou pas, d’avoir des règles avec un grand nombre de sélecteurs.

En fait tout a démarré lorsque Dave Hyatt (le Lead Developer de l’équipe WebKit) a fait remarquer dans un commentaire du blog de Shaun Inman que les sélecteurs CSS enfant (comme le caractère espace) étaient à utiliser à la légère car s’appliquent de droite à gauche et non de gauche à droite.

The sad truth about CSS3 selectors is that they really shouldn’t be used at all if you care about page performance. Decorating your markup with classes and ids and matching purely on those while avoiding all uses of sibling, descendant and child selectors will actually make a page perform significantly better in all browsers. - Dave Hyatt

Ce qui fait que, comme le résume Jon Sykes, la règle suivante :

body table tr td.myTestClass{
  background-color: red;
}

…est moins efficace que sa version courte :

.myTestClass{
  background-color: red;
}

Pourquoi ? Tout simplement parce qu’avec la première règle, si vous modifiez le DOM cette règle devra probablement être ré-appliquée sur tout le document afin de l’appliquer à de nouveaux noeuds ou au contraire à ne plus l’appliquer sur certains noeuds. Alors qu’avec la seconde règle, la modification du DOM n’aura un impact que si cette modification consiste à ajouter ou à retirer la classe “myTestClass”.

Bref, vouloir faire des règles avec une longue série d’accesseurs enfant pour cibler exactement l’élément qui nous intéresse peut s’avérer couteux sur les performances, il est préférable de donner une classe précise à notre ou nos éléments et de créer une règle qui se base sur cette classe et sur rien d’autre.

Pour montrer ce coût en performances, Jon Sykes a réalisé plusieurs tests. Son dernier test consiste à créer une page contenant trois niveaux de DIV imbriqués, le niveau le plus profond contient un paragraphe contenant lui-même un lien. Le lien a un ID et une classe générée. Au total, il y a 20.000 liens dans la page.
Il a ensuite cherché à comparer le temps mis pour afficher la page avec les conditions suivantes :

• aucun style appliqué
• un fond rouge pour chaque cellule avec une unique règle qui s’applique sur la balise A
• un fond rouge pour chaque cellule avec des règles ayant uniquement le nom de la classe du lien (20.000 règles)
• un fond rouge pour chaque cellule avec des règles utilisant le sélecteur fils (20.000 règles)
• un fond rouge pour chaque cellule avec des règles utilisant le sélecteur descendant (20.000 règles)

Il obtient les résultats suivants (les pourcentages affichés sont par rapport à l’affichage sans aucun style) :

Bref, privilégiez les règles avec des sélecteurs courts. Ca risque d’alourdir votre code HTML avec plus de classes ou d’ID mais les performances d’affichage de votre page s’en sortiront mieux.

Pour lire les articles de Jon Sykes :

1. Testing CSS Performance
2. Testing CSS Performance (pt 2)
3. More CSS Performance Testing (pt 3)

Steve Sounders creuse le sujet un peu plus loin

Les tests de Jon Sykes datent du printemps 2008.

Récemment (début Mars), Steve Sounders (de l’équipe Performances de Yahoo!) a creusé le sujet. Il considérait que bien que justes, les tests de Jon Sykes s’appliquaient à des pages bien trop volumineuses pour représenter la réalité : peu de pages peuvent se vanter d’aligner un DOM de 60.000 noeuds et de 20.000 règles CSS. Les 10 sites les plus fréquentés ont une moyenne de 923 noeuds sur leur homepage pour 1033 règles.

Les tests de Steve Sounders sont dont légèrement différents de ceux de Jon Sykes : il se limite à 2.000 liens et 2.000 règles CSS (et non plus 20.000) ce qui donne une page avec un DOM de 6.000 noeuds.
Il s’est également demandé si les résultats pour la page ne contenant aucun style et celle ne contenant qu’une seule règle sur la balise A n’avaient pas un gain en performance simplement parce que leur code contient 20.000 lignes de code en moins. Il a donc décidé de rajouter, pour ces deux cas, 2.000 règles CSS (qui ne s’appliquent sur rien du tout) afin que la taille des codes HTML soit pratiquement la même pour tous les cas de test.

Bref des tests sur un DOM plus réduit et plus proche de la réalité et des cas de tests de même volume.

Ses tests montrent des résultats assez différents de ceux de Jon Sykes, comme le montre son graphique :

On constate que la plupart des navigateurs conservent des courbes relativement “planes”. Comme le dit Steve, sur les principaux navigateurs (IE6&7 + FF3), la différence entre le test sans style et le test avec les sélecteurs fils ou descendants est en moyenne de 20ms et sur la totalité des navigateurs ça monte à une moyenne de 50ms. Donc un résultat difficile à percevoir à l’oeil nu.

Les résultats de Jon Sykes n’était donc pas vraiment applicable. Mais pourquoi une telle différence de résultats ?

Pour comprendre ce changement, Steve Sounders (qui est décidément très curieux) a décidé de refaire passer son test sur IE6&7 (ce sont les navigateurs pour lesquels il avait la différence la plus flagrante avec les tests de Jon) en les faisant tourner sur des pages ayant de plus en plus de balise A (et par conséquent de noeuds DOM et de règles CSS). Il a donc commencé avec 1.000 liens et a augmenté jusqu’à atteindre les 20.000 du test de Jon.

C’est avec ce test qu’il a constaté un palier autour de 18.000 noeuds, comme le montre son second graph :

En définitive, que devons-nous tirer de ces deux analyses ?
Simplement que la recherche d’optimisation n’est finalement pas dans l’utilisation parcimonieuse des sélecteurs CSS. Dans la plupart des cas le gain sera négligeable et risquerait d’entraîner une baisse de lisibilité du code pour les développeurs.

Vous ne connaissez peut-être pas le terme de “CSS Jitter” même si vous avez probablement déjà croisé ce bug.

Ce phénomène se présente lors d’une mauvaise utilisation des styles sur les événements de type onMouseOver, par exemple lorsque vous réduisez la taille d’un élément au moment ou vous le survolez avec la souris : au moment où la souris passe au-dessus de l’objet, sa taille va réduire si bien que la souris peut potentiellement ne plus être au-dessus de l’élément donc celui-ci va reprendre sa taille initiale. Mais au moment où il reprend sa taille initiale, la souris se retrouve de nouveau au-dessus donc il va de nouveau être réduit. Bref on va assister à un effet de clignotement très désagréable.

Un exemple concret réalisé par CSS-Tricks : Jitter-Man ! Pour constater le phénomène, il suffit de vous rapprocher du bord du cadre rouge de Jitter-Man…

Quelques effets qui peuvent provoquer ce phénomène :

• l’ajout ou le retrait de gras
• les modifications sur les margin ou le padding
• les modifications sur la taille des bordures
• les modifications sur la hauteur ou la largeur
• les modifications sur la hauteur de ligne

Bref, l’essentiel est de faire attention et de placer l’événement onMouseOver sur quelque chose qui ne va pas voir ses dimensions être modifiées à cause de l’effet appliqué.

Source de l’article : CSS-Tricks.

Cet article de CSS Globe aborde un sujet très pertinent : doit-on s’efforcer d’avoir d’avoir une compatibilité totale entre tous les navigateurs (du moins les majeurs) ou bien au contraire devons-nous utiliser au maximum le potentiel des navigateurs récents tout en s’assurant que l’interface des plus anciens s’affiche correctement, même si son design est moins riche ?

L’exemple le plus parlant pour illustrer cette opposition est la mise en place de coins arrondis sur un bloc.
Pour avoir une compatibilité entre les navigateurs, il faut mettre en place une méthode parmi la multitude des solutions qui s’offrent à nous mais quelque soit la méthode appliquée, cela reste une méthode lourde et illogique à partir du moment où une notion de design (les coins arrondis) a un impact sur le markup de la page (et encore plus si les balises html nécessaires pour les coins arrondis sont générées par du JavaScript) ainsi que sur la maintenance de la page.

D’un autre côté, la méthode dégradée élégante consiste à utiliser le potentiel des CSS 3 en appliquant les coins arrondis via les propriétés border-radius ou box-shadow. Sur les navigateurs ne gérant pas ces propriétés, notre bloc reste carré donc potentiellement moins joli. Cela dit, peut-être qu’avoir un site moins joli que chez les autres incitera les utilisateurs à se tourner vers les dernières versions de leur navigateur…

Oui, oui, je vous l’accorde, les propriétés CSS 3 ont elles aussi leurs limitations pour faire des coins arrondis : ça reste des quarts de cercle de couleur unie alors qu’avec des images placées dans les angles, on a plus de potentiel mais il ne faut pas oublier qu’il existe d’autres propriétés CSS 3 nous permettant de placer plusieurs images de fond sur un bloc donc cet argument ne tient pas.

Les navigateurs évoluent mais les web designers restent bloqués sur les mêmes techniques. Ca pour maîtriser les failles d’IE6, on peut dire qu’elles sont maîtrisées mais ce nivellement par le bas a un impact sur les performances des sites et bride leur design…

Une excellente méthode proposée par Le Potlatch pour éviter les problèmes de cache chez les utilisateurs lorsque les JS ou les CSS sont modifiés : plutôt que de versionner les fichiers et de devoir mettre à jour la version à chaque fois qu’on modifie le fichier (et modifier les appels aux fichiers), le Potlatch propose plutôt de mettre un paramêtre GET dans l’url du fichier, par exemple monfichier.css?param=valeur.

Et à votre avis, quelle est la valeur la plus adaptée ? La date de dernière modification bien sûr ! On peut la récupérer en php via la méthode filemtime().

Autrement dit, lorsqu’on inclus un CSS ou un JS dans une page, on ne met plus monFichier.css comme nom de fichier mais monFichier.css<?php echo filemtime("monFichier.css"); ?>

Le site Six Revisions a publié 8 techniques afin de réaliser des graphiques en utilisant uniquement des CSS.

1. CSS for Bar Graphs

   Le blog Apples to Oranges propose trois examples de graph. Le premier, Basic CSS Bar Graph, utilise un <div> pour contenir le graph et un élément <strong> remplir un certain pourcentage de la barre du graph. Six Revisions suggère d’utiliser un <p> plutôt que le <strong> afin d’avoir une valeur plus correcte d’un point de vue sémantique.

   Voir la démo.

2. Accessible Data Visualization with Web Standards

   Cette seconde technique est proposée par Wilson Miner sur A List Apart. L’objectif est d’obtenir des graph accessibles et respectueux des standards à partir d’une structure relativement simple. L’article propose trois affichages différents : sous forme de graph horizontal classique, sous forme de timeline ou encore en format réduit pour faire plus ou moins office d’icone.

   Voir la démo du graphe horizontal.
   Voir la démo de la timeline.
   Voir la démo de la version réduite.

3. CSS Vertical Bar Graphs

   
   Cette troisième technique, qui ressemble fortement à celle proposée par Apples To Oranges, est proposée par Eric Meyer qui présente ici un graphique vertical basé sur une liste non-ordonnée.
   

4. Creating a graph using percentage background images

   Cette solution est proposée par maxdesign et a la particularité d’utiliser des images de fond pré-créées. Chaque image est associée à une valeur précise pour le graph, par exemple 20% ou 40%. Cette technique est très limitée car elle limite le nombre de valeur affichables à moins d’augmenter le nombre d’images de fond. Par ailleurs, la multiplication des images entraîne également une multiplication des requêtes HTTP pour les charger par le navigateur.

5. Pure CSS Data Chart

   
   Ce graph vertical se base sur une liste de définitions et a l’avantage de proposer l’affichage de la valeur au centre de chaque barre.
   Voir la démo.

6. CSS Scatter Plot

   
   Parmi tous ces exemples de graph, en voici un sous forme de nuage de points. Cette technique proposée par John Graham-Cumming permet d’avoir des points clickables, idéal si on veut faire pointer chaque point vers des informations additionnelles.

7. Definition List Bar Chart

   
   Comme son nom l’indique, ce graph horizontal se base sur une liste de définitions. Cette technique utilise une classe par valeur et utilise un pourcentage de la largeur pour gérer l’affichage.

8. Accessible Bar Chart


Cette dernière technique repose sur une table et une image dont on fait varier la largeur pour gérer l’affichage des barres horizontales du graph.

Chris Coyier donne son analyse sur l’utilité des frameworks CSS dans un billet sur CSS-Tricks.

D’après lui, les frameworks CSS apportent plusieurs avantages :

• ils peuvent vous aider à apprendre les CSS, par exemple en vous mettant directement sous le nez la bonne méthode pour faire un layout en plusieurs colonnes ou un footer qui tienne la route,
• ils vous fournissent du code “basique” afin de vous éviter de devoir le récrire pour chaque site, par exemple le reset des styles,
• ils se chargent de gérer les problèmes de compatibilité,
• ils vous aident à prendre de bonnes habitudes, par exemple en intégrant systématiquement une feuille de style pour l’impression,
• ils vous encouragent à faire un design en grille et pas avec d’horribles tableaux,
• ils sont livrés avec de la documentation, ce qui peut être pratique lorsqu’on livre un site à un client,
• ils sont parfois profondément intégrés à un framework plus complet, par exemple dans le framework YUI et facilitent son utilisation.

Cependant, il pointe aussi quelques défauts majeurs qui l’encouragent à se passer des frameworks CSS autant que possible :

• Pour qu’un framework fasse gagner du temps, il faut s’en servir plusieurs fois afin d’en maîtriser toutes les particularités,
• les frameworks vous forcent la main, par exemple dans le choix des classes ou des ID, et vous obligent à changer vos habitudes (et à les changer différemment selon les frameworks),
• ils peuvent être surchargés inutilement quand on n’utilise qu’une petite partie du framework sans en tirer tout son potentiel,
• ils peuvent parfois faire perdre du temps lorsqu’ils sont imposés car il est parfois plus long de prendre en main le framework et arriver à en tirer le résultat voulu que de tout refaire soi-même à la main.

Pour ma part, je n’ai jamais eut l’occasion d’utiliser un framework CSS, je me contente généralement d’un reset tout fait. Je dois dire que je préfère tout réaliser à la main afin de parfaitement maîtriser les caractéristiques de l’interface que je suis en train de réaliser plutôt que d’utiliser une structure toute faite…

Dans mon précédent billet dédié aux moteurs de sélecteurs CSS en JavaScript, je signale que certaines personnes estiment qu’on en voit la fin : les moteurs ont des performances optimales, il est inutile de chercher à les améliorer de ce côté.

C’est un peu ce que s’est dit Eric Meyer dans un billet publié mercredi dernier où il donne de bonnes idées pour les moteurs à venir.

D’un côté, nous avons les CSS 3 dont les fonctionnalités visent à remplacer des particularités que nous réalisons à l’heure actuelle avec des méthodes de Sioux mélangeant allégrement HTML, CSS, JavaScript et images (coin arrondis, effets d’ombre, animation, dégradés, etc). Le point noir, c’est que les navigateurs évoluent lentement et IE6 nous tire vers le bas, bridant nos possibilités et l’utilisation de tout ce potentiel qui commence à être géré par les nouvelles versions des navigateurs, ce qui nous oblige à continuer avec nos méthodes de Sioux qui sont rôdées, certes, mais qui obligent à déporter une partie de la couche design (les CSS) dans les autres, par exemple en ajoutant les div et les span qui vont bien pour réaliser un joli rendu (div et span qui sont parfois injectés dans le DOM par du JavaScript).

De l’autre côté, on a des moteurs de sélecteurs en JavaScript dont le rôle est de permettre l’utilisation des sélecteurs CSS 3 dans du code JavaScript afin de faciliter l’accès aux données dans la page.

Et si ces moteurs JavaScript faisaient un peu plus que ça ? Ils pourraient par exemple se charger de parcourir la feuille de style, repérer les règles CSS contenant des sélecteurs non-gérés par le navigateur et appliquer les propriétés des règles en question sur les bons éléments. Le développeur pourrait ainsi se mettre à utiliser les sélecteurs CSS 3 dans ses feuilles de style, le moteur JS se chargerait d’appliquer les règles non-gérées par le navigateur.

Il est même possible d’aller encore plus loin : pourquoi ces moteurs javascript ne pourraient-ils pas également gérer des propriétés CSS 3 ? Eric mentionne par exemple la possibilité d’appliquer plusieurs images de fond à un objet en CSS 3 :

#monID {
   background:url(top.png) no-repeat top left,
      url(bottom.png) no-repeat bottom left,
      url(middle.png) no-repeat 50% 50%;
}

Le moteur javascript se chargerait de détecter ce genre de règle et de modifier la structure de l’élément (en lui rajoutant des div et des span) pour lui appliquer les fonds multiple.

La même chose pourrait se faire avec d’inombrables propriétés actuellement inutilisables à moins de cibler des navigateurs de dernière génération. La couche présentation se composerait alors d’une sous-couche de style (les feuilles de style) et d’un moteur javascript pour gérer les problèmes de mauvaise gestion de ces feuilles de style par les navigateurs.

Le Javascript non plus pour aider le développeur à faire son interface mais pour aider le navigateur à afficher ce que lui demande le développeur.

Fin août dernier, John Resig a annoncé la création de son tout nouveau moteur de sélecteurs CSS en JavaScript, Sizzle, supposé être intégré dans l’une des prochaines versions de jQuery.

Il y a quelques jours, un autre moteur de sélecteurs a fait son apparition, il s’agit de Peppy, réalisé par James Donaghue.

Côté perf, les deux moteurs sont ce qui se fait de mieux, vous pouvez le constater en lançant le SlickSpeed sur le blog de James Donaghue. Ils sont loin devant les frameworks classiques et ont l’avantage de la légéreté : Sizzle fait 4 ko, Peppy fait 10 ko. Bref idéal pour être intégré n’importe et pour, pourquoi pas, surcharger le moteur de sélecteur de votre framework favori.

A noter toutefois que Peppy a encore quelques soucis avec une mauvaise gestion du cache sous IE : le moteur marche parfaitement à condition que le DOM ne soit jamais modifié, dans le cas contraite peuvent survenir des résultats erronés (c’est d’ailleurs cette mauvaise gestion du cache qui lui permet d’afficher des résultats bien meilleurs que ceux de Sizzle sous IE). Ce problème devrait être réglé au cours du weekend car James Donaghue a annoncé une nouvelle release dans les jours à venir.

En tout cas, ces deux moteurs annoncent le début de la fin de la guerre des perf sur les moteurs de sélecteurs : de nombreuses personnes s’accordent à dire qu’il n’est plus nécessaire d’optimiser la vitesse  et qu’il faut se tourner vers d’autres directions.