Pourquoi les navigateurs correspondent-ils aux sélecteurs CSS de droite à gauche?

Les sélecteurs CSS sont appariés par les moteurs de navigation de droite à gauche. Ils trouvent donc d’abord les enfants puis vérifient si leurs parents correspondent aux autres parties de la règle.

  1. Pourquoi est-ce?
  2. Est-ce juste parce que la spécification dit?
  3. Est-ce que cela affecte la mise en page éventuelle si elle a été évaluée de gauche à droite?

Pour moi, le moyen le plus simple serait d’utiliser les sélecteurs avec le moins d’éléments possible. Donc, les identifiants d’abord (car ils ne devraient renvoyer qu’un élément). Ensuite, peut-être des classes ou un élément qui comporte le moins de nœuds – par exemple, il ne peut y avoir qu’un seul intervalle sur la page, alors rendez-vous directement sur ce nœud avec toute règle faisant référence à un span.

Voici quelques liens sauvegardant mes réclamations

  1. http://code.google.com/speed/page-speed/docs/rendering.html
  2. https://developer.mozilla.org/fr/Writing_Efficient_CSS

On dirait que cela est fait de cette façon pour éviter d’avoir à regarder tous les enfants de parent (qui pourraient être nombreux) plutôt que tous les parents d’un enfant qui doivent en être un. Même si le DOM est profond, il ne regarderait qu’un nœud par niveau plutôt que plusieurs dans la correspondance RTL. Est-il plus facile / plus rapide d’évaluer les sélecteurs CSS LTR ou RTL?

Gardez à l’esprit que lorsqu’un navigateur effectue une sélection de sélecteurs, il comporte un élément (celui pour lequel il tente de déterminer le style) et toutes vos règles et leurs sélecteurs. Il doit également trouver quelles règles correspondent à l’élément. Ceci est différent de la chose jQuery habituelle, par exemple, où vous n’avez qu’un seul sélecteur et que vous devez trouver tous les éléments correspondant à ce sélecteur.

Si vous n’aviez qu’un seul sélecteur et un seul élément à comparer à ce sélecteur, de gauche à droite est plus logique dans certains cas. Mais ce n’est décidément pas la situation du navigateur. Le navigateur essaie de rendre Gmail ou autre et celui-ci essaie de styliser et les plus de 10 000 règles que Gmail place dans sa feuille de style (je ne fais pas ce numéro).

En particulier, dans la situation où le navigateur recherche la plupart des sélecteurs, il ne prend pas en compte l’élément en question. Le problème consiste donc à décider qu’un sélecteur ne correspond pas aussi vite que possible; Si cela nécessite un peu de travail supplémentaire dans les cas qui correspondent, vous gagnez toujours grâce à tout le travail que vous économisez dans les cas qui ne correspondent pas.

Si vous commencez simplement à faire correspondre la partie la plus à droite du sélecteur avec votre élément, il y a des chances que cela ne corresponde pas et que vous ayez terminé. Si cela correspond, vous devez faire plus de travail, mais seulement proportionnellement à la profondeur de votre arbre, ce qui n’est pas très important dans la plupart des cas.

Par contre, si vous commencez par associer la partie la plus à gauche du sélecteur, à quoi vous correspondez-vous? Vous devez commencer à parcourir le DOM, à la recherche de nœuds qui pourraient correspondre. Il suffit de découvrir que rien ne correspond à la partie la plus à gauche.

Les navigateurs correspondent donc à partir de la droite. cela donne un sharepoint départ évident et vous permet de vous débarrasser très rapidement de la plupart des sélecteurs candidats. Vous pouvez voir certaines données à l’ adresse http://groups.google.com/group/mozilla.dev.tech.layout/browse_thread/thread/b185e455a0b3562a/7db34de545c17665 (bien que la notation soit déroutante), mais le résultat est que pour Gmail en particulier Il y a deux ans, pour 70% des paires (règle, élément), vous pouviez décider que la règle ne correspondait pas après avoir simplement examiné les parties tag / class / id du sélecteur le plus à droite de la règle. Le nombre correspondant pour la suite de tests de performances pageload de Mozilla était de 72%. Donc, il vaut vraiment la peine d’essayer de se débarrasser des 2/3 de toutes les règles aussi rapidement que possible et de ne plus vous soucier que de faire correspondre les 1/3 restants.

Notez également qu’il existe d’autres optimisations que les navigateurs font déjà pour éviter même d’essayer de faire correspondre des règles qui ne correspondent absolument pas. Par exemple, si le sélecteur le plus à droite a un identifiant et que celui-ci ne correspond pas à l’identifiant de l’élément, il n’y aura aucune tentative de faire correspondre ce sélecteur avec cet élément dans Gecko: l’ensemble des “sélecteurs avec identifiants” vient d’une recherche de hashtable sur l’ID de l’élément. Il s’agit donc de 70% des règles qui ont de fortes chances de s’appliquer et qui ne correspondent toujours pas après avoir uniquement considéré le tag / class / id du sélecteur le plus à droite.

L’parsing du droit à la gauche, également appelée parsing ascendante, est en fait efficace pour le navigateur.

Considérer ce qui suit:

 #menu ul li a { color: #00f; } 

Le navigateur commence par rechercher a , puis li , puis ul , puis #menu .

En effet, comme le navigateur parsing la page, il suffit de regarder l’élément / le nœud actuel et tous les nœuds / éléments précédents qu’il a analysés.

La chose à noter est que le navigateur commence à traiter le moment où il obtient un tag / nœud complet et n’a pas besoin d’attendre la page entière sauf quand il trouve un script, auquel cas il met temporairement en pause et termine l’exécution du script. va de l’avant.

Si c’est l’inverse, cela sera inefficace car le navigateur a trouvé l’élément qu’il analysait lors de la première vérification, mais il a ensuite été forcé de continuer à parcourir le document pour trouver tous les sélecteurs supplémentaires. Pour cela, le navigateur doit avoir l’intégralité du code HTML et peut avoir besoin d’parsingr toute la page avant de lancer la peinture CSS.

Ceci est contraire à la façon dont la plupart des librairies parsingnt dom. Là, le dom est construit et il n’est pas nécessaire de scanner la page entière, il suffit de trouver le premier élément et de continuer à faire correspondre les autres à l’intérieur.

Il permet une cascade du plus spécifique au moins spécifique. Il permet également un court-circuit dans l’application. Si la règle plus spécifique s’applique à tous les aspects auxquels la règle parente s’applique, toutes les règles parentes sont ignorées. S’il y a d’autres bits dans le parent, ils sont appliqués.

Si vous faites l’inverse, vous formatez en fonction du parent et remplacez chaque fois que l’enfant a quelque chose de différent. À long terme, cela représente beaucoup plus de travail que d’ignorer des éléments dans des règles déjà sockets en compte.