Question Pourquoi les navigateurs correspondent 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 ID d'abord (comme ils devraient seulement retourner 1 élément). Ensuite, peut-être des classes ou un élément qui comporte le moins de nœuds - par ex. il ne peut y avoir qu'un seul intervalle sur la page, alors allez directement à ce nœud avec n'importe quelle règle faisant référence à un intervalle.

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

Il semble que cela soit fait de cette façon pour éviter d'avoir à regarder tous les enfants des parents (qui pourraient être nombreux) plutôt que tous les parents d'un enfant qui doit 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?


504
2018-04-26 22:03


origine


Réponses:


Gardez à l'esprit que lorsqu'un navigateur effectue une sélection de sélecteur, il a un élément (celui pour lequel il essaie de déterminer le style) et toutes vos règles et leurs sélecteurs et il doit trouver les règles qui 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 c'est décidément ne pas la situation du navigateur. Le navigateur tente de rendre Gmail ou autre et a celui <span> il essaie de styler et les 10 000+ règles que Gmail met dans sa feuille de style (je ne fais pas ce chiffre).

En particulier, dans la situation où le navigateur regarde la plupart des sélecteurs qu'il envisage ne pas correspondre à l'élément en question. Ainsi, le problème consiste à 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.

D'un autre côté, si vous commencez par faire correspondre la partie la plus à gauche du sélecteur ... à quoi correspond-il? Vous devez commencer à marcher le DOM, à la recherche de nœuds qui pourraient correspondre. Le simple fait de découvrir qu'il n'y a rien de correspondant à cette partie la plus à gauche peut prendre un certain temps.

Ainsi, les navigateurs correspondent à partir de la droite; cela donne un point de départ évident et vous permet de vous débarrasser très rapidement de la plupart des sélecteurs candidats. Vous pouvez voir des données à 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 correspond pas après avoir simplement examiné le tag / class / id parties du sélecteur le plus à droite pour la règle. Le nombre correspondant pour la suite de tests de performances pageload de Mozilla était de 72%. Il vaut donc la peine d'essayer de se débarrasser de ces 2/3 de toutes les règles aussi vite que possible et de ne s'inquiéter que du 1/3 restant.

Notez également qu'il existe déjà d'autres optimisations que les navigateurs font déjà pour éviter d'essayer de faire correspondre des règles qui ne correspondront certainement pas. Par exemple, si le sélecteur le plus à droite possède un identifiant et que celui-ci ne correspond pas à l'identifiant de l'élément, Gecko ne tentera pas de faire correspondre ce sélecteur à cet élément: l'ensemble des "sélecteurs avec ID" tentés provient d'une recherche de hashtable sur l'identifiant de l'élément. C'est donc 70% des règles qui ont de très bonnes chances de correspondre encore ne correspondent pas après avoir pris en compte uniquement l'étiquette / classe / id du sélecteur le plus à droite.


765
2018-04-28 04:36



Analyse de droite à gauche, également appelée analyse ascendante est réellement efficace pour le navigateur.

Considérer ce qui suit:

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

Le navigateur vérifie d'abord a, puis li, puis ul, et alors #menu.

En effet, comme le navigateur analyse 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 le navigateur commence à traiter le moment où il obtient un tag / noeud complet et n'a pas besoin d'attendre la totalité de la page, sauf lorsqu'il trouve un script, auquel cas il interrompt temporairement et termine l'exécution du script, puis avance.

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 le code html entier et peut avoir besoin de scanner toute la page avant de commencer la peinture CSS.

Ceci est contraire à la façon dont la plupart des librairies analysent dom. Là, le dom est construit et il n'a pas besoin de scanner toute la page, il suffit de trouver le premier élément et de continuer à faire correspondre les autres à l'intérieur.


20
2018-02-18 10:04



Il permet de cascader 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 s'applique la règle parente, toutes les règles parentes sont ignorées. S'il y a d'autres bits dans le parent, ils sont appliqués.

Si vous étiez dans l'autre sens, vous formeriez selon le parent, puis écraser chaque fois que l'enfant a quelque chose de différent. À long terme, c'est beaucoup plus de travail que d'ignorer les éléments des règles déjà prises en charge.


18
2018-04-26 22:13