560 votes

Pourquoi les navigateurs match CSS sélecteurs de droite à gauche?

Les Sélecteurs CSS sont appariés par les moteurs de navigateur de droite à gauche. Afin qu'ils trouvent d'abord les enfants, puis vérifier leurs parents pour voir s'ils correspondent au reste des pièces de la règle.

  1. Pourquoi est-ce?
  2. Est-ce juste parce que la spec dit?
  3. T-il sur l'éventuelle mise en page si elle a été évaluée à partir de la gauche vers la droite?

Pour moi, la façon la plus simple serait d'utiliser les sélecteurs avec le moins d'éléments. Si Id de en premier (comme ils devraient le retour 1 élément). Alors peut-être que les classes ou un élément qui a le plus petit nombre de nœuds (par exemple, il peut y avoir seulement une travée sur la page pour aller directement à ce nœud avec une règle qui fait référence à une durée.

Voici quelques liens de sauvegarder mes revendications

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

Il semble qu'il est fait de cette façon pour éviter d'avoir à regarder tous les enfants de parent (qui pourrait être beaucoup) plutôt que tous les parents d'un enfant qui doit l'être. Même si le DOM est profond, il ne porterait que sur un nœud par niveau plutôt que de multiples dans la RTL de correspondance. Est-il plus facile/rapide à évaluer les sélecteurs CSS LTR ou RTL?

824voto

Boris Zbarsky Points 22158

Gardez à l'esprit que lorsqu'un navigateur est en train de faire le sélecteur de correspondance, il a un élément (l'un c'est d'essayer de déterminer le style) et de toutes vos règles et de leur sélecteurs et il a besoin de connaître les règles qui correspondent à l'élément. C'est différent de l'habituel jQuery chose, disons, où vous avez seulement un sélecteur et vous devez trouver tous les éléments qui correspondent au sélecteur.

Si vous n'aviez qu'un sélecteur et un seul élément à comparer à qui sélecteur, puis de gauche à droite fait plus de sens dans certains cas. Mais c'est décidément pas le navigateur de la situation. Le navigateur tente de rendre compte Gmail ou quoi que ce soit et a la une <span> il essaie de style et les 10 000+ règles Gmail met dans sa feuille de style (je ne fais pas ce numéro).

En particulier, dans la situation que le navigateur est à la recherche à la plupart des sélecteurs il s'agit de ne pas correspondre à l'élément en question. Donc, le problème devient celui de décider que l'un sélecteur ne correspond pas aussi rapide que possible; si cela nécessite un peu de travail supplémentaire dans les cas qui ne correspondent-vous encore gagner à cause de tout le travail que vous enregistrez dans les cas qui ne correspondent pas.

Si vous commencez par juste correspondant à la partie droite du sélecteur à l'encontre de votre élément, alors les chances sont qu'il ne correspond pas et vous avez terminé. Si elle correspond, vous avez à faire plus de travail, mais seulement proportionnelle à votre profondeur de l'arbre, ce qui n'est pas très grande dans la plupart des cas.

D'autre part, si vous commencez par la correspondance de la partie gauche du sélecteur de... de quoi avez-vous le match contre? Vous devez commencer à marcher dans les DOM, à la recherche pour les nœuds qui pourraient correspondre. Juste de découvrir qu'il n'y a rien qui corresponde le plus à gauche de la partie peut prendre un certain temps.

Afin que les navigateurs match à partir de la droite; il donne un point de départ évident et vous permet de vous débarrasser de la plupart des candidats sélecteurs très rapidement. Vous pouvez voir quelques données au http://groups.google.com/group/mozilla.dev.tech.layout/browse_thread/thread/b185e455a0b3562a/7db34de545c17665 (bien que la notation est source de confusion), mais le résultat est que, pour Gmail, en particulier, il y a deux ans, pour 70% de la (règle, élément) paires vous pouvez décider que la règle ne correspond pas après l'examen de la tag/id/classe de parties de celui le plus à droite du sélecteur de la règle. Le nombre correspondant de Mozilla pageload les performances de la suite de tests a été de 72%. Il est donc vraiment la peine d'essayer de se débarrasser de ces 2/3 de l'ensemble des règles aussi vite que vous pouvez et ensuite seulement s'inquiéter de correspondance pour le 1/3 restant.

Notez également qu'il existe d'autres optimisations navigateurs le font déjà pour éviter de même essayer de faire correspondre les règles qui certainement ne correspond pas. Par exemple, si la plus à droite du sélecteur a un id et id ne correspond pas à l'identification de l'élément, alors il n'y aura pas de tentative pour correspondre à ce que le sélecteur à l'encontre de cet élément dans Gecko: l'ensemble des "sélecteurs avec les Identifiants qui sont tenté vient d'une table de hachage de recherche sur l'identification de l'élément. Donc, c'est 70% des règles qui ont une assez bonne chance de correspondance qui encore ne correspondent pas juste après avoir tenu compte de la balise/classe/id de la plus à droite du sélecteur.

33voto

aWebDeveloper Points 5546

De gauche à Droite analyse, aussi appelée "bottom-up d'analyse est en fait efficace pour le navigateur.

Considérez les points suivants:

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

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

C'est parce que le navigateur est la numérisation de la page il y a juste à regarder l'élément courant/nœud et tous les précédents noeuds/éléments qu'il a analysé.

La chose à noter est que le navigateur commence à traiter moment où il obtient une balise complète/node et n'ont pas à attendre pour l'ensemble de la page, sauf lorsqu'il trouve un script, dans ce cas, il suspend temporairement et termine l'exécution du script, puis va de l'avant.

Si ce n'est l'inverse, il sera inefficace car le navigateur trouvé l'élément il a été la numérisation sur la première case, mais a ensuite été forcé de continuer la recherche dans le document pour toutes les autres sélecteurs. Pour cela, le navigateur a besoin d'avoir tout le code html et peut-être besoin de numériser l'ensemble de la page avant qu'il ne commence css peinture.

C'est contraire à la façon dont la plupart des libs analyser les dom. Il y a le dom est construit et il n'a pas besoin de scanner l'intégralité de la page il suffit de trouver le premier élément, puis aller sur la correspondance d'autres à l'intérieur .

20voto

Gregory A Beamer Points 10975

Il permet en cascade à partir de la plus spécifique pour les moins spécifiques. Il permet également à un court-circuit dans l'application. Si la règle plus spécifique s'applique dans tous les aspects que le parent règle s'applique à tous les parents de règles sont ignorées. Si il y a d'autres éléments dans le parent, ils sont appliqués.

Si vous êtes allé dans l'autre sens, vous format en fonction de parent et puis écraser à chaque fois que l'enfant a quelque chose de différent. Dans le long terme, c'est beaucoup plus de travail que d'ignorer les éléments dans les règles qui sont déjà pris en charge.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X