Comment fonctionnent les navigateurs

L'analyse est basée sur les règles de syntaxe auxquelles le document obéit - la langue ou le format dans lequel il a été écrit. Chaque format que vous analysez doit avoir une grammaire déterministe constituée d'un vocabulaire et de règles de syntaxe. C'est ce que l'on appelle une grammaire sans contexte. Les langues humaines n'en sont pas et ne peuvent donc pas être analysées avec des techniques d'analyse classiques.

L'analyse peut être séparée en deux processus - l'analyse lexicale et l'analyse syntaxique.

L'analyse lexicale est le processus de séparation de l'entrée en mots-clés. Les mots-clés sont le vocabulaire de la langue - la collection de blocs de construction valides. Pour un langage humain, il se compose de tous les mots qui apparaissent dans le dictionnaire de cette langue.

L'analyse syntaxique est l'application des règles de la syntaxe du langage.

Les analyseurs, généralement, divisent le travail entre les deux éléments - l'analyseur lexical (appelé lexer ou tokenizer en langue anglaise) qui est responsable de l'extraction des mots-clés depuis l'entrée et l'analyseur syntaxique qui est responsable de la construction de l'arbre syntaxique par l'analyse de la structure du document selon les règles de syntaxe du langage. L'analyseur lexical sait comment supprimer des caractères non pertinents tels que les espaces et des sauts de ligne.

Le processus d'analyse est itératif. L'analyseur syntaxique demande généralement à l'analyseur lexical le prochain mot-clé et essaye de faire correspondre ce mot-clé avec l'une des règles de syntaxe. Si une règle est trouvée, un nœud correspondant au mot-clé sera ajouté à l'arbre d'analyse et l'analyseur syntaxique demandera un autre mot-clé.

Si aucune règle ne correspond, l'analyseur va stocker le mot-clé en interne et continuer à demander des mots-clés jusqu'à ce qu'une règle de correspondance avec les mots-clés stockés en interne soit trouvée. Si aucune règle n'est trouvée, alors l'analyseur déclenche une exception. Cela signifie que le document n'est pas valide et qu'il contient des erreurs de syntaxe.

Souvent, l'arbre d'analyse syntaxique n'est pas le produit final. L'analyse est souvent employée en traduction - la transformation du document d'entrée en un autre format. Un exemple est la compilation. Le compilateur qui compile un code source en code machine analyse d'abord le code avec un arbre d'analyse et traduit ensuite cet arbre dans un document code machine.

Dans la figure 5, nous avons construit un arbre d'analyse à partir d'une expression mathématique. Essayons de définir un langage mathématique simple et de voir le processus d'analyse.

Vocabulaire : notre langage peut inclure des nombres entiers ainsi que les signes plus et moins.

Syntaxe :

1. Les blocs de construction sont des expressions, des termes et des opérations ;
2. Notre langage peut comporter un nombre quelconque d'expressions ;
3. Une expression est définie comme un « terme » suivi d'une « opération » suivie par un autre terme ;
4. Une opération est un signe plus ou un signe moins ;
5. Un terme est un entier ou une expression.

Analysons l'entrée 2 + 3 - 1.

La première chaîne qui correspond à une règle est 2 et conformément à la règle N° 5, c'est un terme. La deuxième correspondance est 2 + 3 cela correspond à la troisième règle - un terme suivi d'une opération suivie par un autre terme. La prochaine correspondance ne sera atteinte qu'à la fin de l'entrée. 2 + 3 - 1 est une expression parce que nous savons déjà que 2 +3 est un terme et que nous avons un terme suivi par une opération suivie par un autre terme. 2 + + ne correspond à aucune règle et n'est donc pas une entrée valide.

Le vocabulaire est en général exprimé par des expressions régulières.

Par exemple, notre langage sera défini comme :

INTEGER :0|[1-9][0-9]*
PLUS : +
MINUS: -

Comme vous le voyez, les nombres sont définis par une expression régulière.

La syntaxe est généralement définie dans un format nommé BNF. Notre langage sera défini comme cela :

expression := term operation term
operation := PLUS | MINUS
term := INTEGER | expression

Nous avons dit qu'un langage peut être analysé par un analyseur normal si sa grammaire est une grammaire sans contexte. La définition intuitive d'une grammaire sans contexte est une grammaire qui peut entièrement être exprimée en format BNF. Pour une définition plus formelle voir l'article Wikipédiasur les grammaires sans contexte.

Il y a deux types d'analyseurs - les analyseurs de haut en bas (top down) et les analyseurs de bas en haut (bottom up). Une explication intuitive est que les analyseurs de haut en bas voient la structure de la syntaxe de haut niveau et tentent de faire correspondre l'entrée à l'une des règles. Les analyseurs de bas en haut commencent avec l'entrée et la transforment peu à peu en règles de syntaxe, à partir des règles de bas niveau jusqu'à ce que les règles de haut niveau soient remplies.

Voyons comment ces deux types d'analyseurs vont analyser notre exemple.

Un analyseur de haut en bas commencera à partir de la règle de niveau supérieur - il identifiera 2 + 3 comme une expression. Il identifiera alors 2 + 3 - 1 comme une expression (le processus d'identification de l'expression change pour correspondre avec les autres règles, mais le point de départ est la règle de plus haut niveau).

Un analyseur de bas en haut va lire l'entrée jusqu'à ce qu'une règle corresponde et il remplacera alors l'entrée correspondant à la règle. Et ainsi de suite jusqu'à la fin de l'entrée. L'expression partiellement identifiée est placée sur la pile analyseurs.

Ce type d'analyseur de bas en haut est appelé analyseur à décalage-réduction, parce que l'entrée est décalée vers la droite (imaginez un pointeur pointant d'abord sur le début de l'entrée puis se déplaçant vers la droite) et est progressivement réduite à des règles de syntaxe.

Il existe des outils qui permettent de générer un analyseur syntaxique pour vous. Ils sont appelés générateurs d'analyseurs. Vous leur fournissez la grammaire de la langue, son vocabulaire et la syntaxe de ses règles, et ils génèrent un analyseur. La création d'un analyseur nécessite une connaissance approfondie de l'analyse et comme il n'est pas facile de créer à la main un analyseur optimisé, ces générateurs d'analyseurs sont donc très utiles.

Webkit utilise deux générateurs d'analyseur bien connus - Flex pour créer l'analyseur lexical et Bison pour la création de l'analyseur syntaxique (vous pourrez aussi les rencontrer avec les termes Lex et Yacc). L'entrée de Flex est un fichier contenant la définition des expressions régulières des mots-clés. L'entrée de Bison est constituée par les règles de syntaxe du langage au format BNF.

Le vocabulaire et la syntaxe du langage HTML sont définis dans des spécifications créées par l'organisation W3C. La version actuelle est HTML4 et le travail sur le HTML5 est en cours.

Comme nous l'avons vu dans l'introduction sur l'analyse, la syntaxe grammaticale peut être définie de manière formelle en utilisant des formats tels que la BNF.

Malheureusement, la notion d'analyseur conventionnel ne s'applique pas au format HTML (je n'en ai pas parlé juste pour le plaisir, ils seront utilisés lors de l'analyse CSS et JavaScript). HTML ne peut pas être défini facilement avec la grammaire sans contexte dont ont besoin les analyseurs.

Il existe un document officiel pour définir HTML, une DTD (Document Type Definition), mais ce n'est pas une grammaire sans contexte.

Cela semble étrange à première vue ; HTML étant assez proche de XML. Il existe beaucoup d'analyseurs XML disponibles. Il y a une différence entre XML et HTML - XHTML, alors quelle est cette différence ?

La différence est que l'approche HTML est plus « clémente », elle vous permet d'omettre certaines balises qui sont ajoutées implicitement, ou encore le début ou la fin de la balise, etc. Dans l'ensemble c'est une syntaxe « souple », par opposition à la syntaxe « stricte » et « exigeante » de XML.

Apparemment, cette petite différence fait un monde de différence. D'une part, c'est la raison principale pour laquelle HTML est si populaire, il pardonne vos erreurs et facilite la vie aux auteurs Web. D'autre part, il est difficile d'écrire une grammaire formelle. Donc, pour résumer, HTML ne peut pas être analysé facilement, en tout cas pas par des analyseurs conventionnels, puisque sa grammaire n'est pas une grammaire sans contexte, ni par des analyseurs XML.

La définition HTML est dans un format DTD. Ce format est utilisé pour définir les langues de la famille SGML. Le format contient les définitions de tous les éléments autorisés, leurs attributs et leur hiérarchie. Comme nous l'avons vu précédemment, la DTD HTML ne constitue pas une grammaire sans contexte.

Il existe quelques variantes de DTD. Le mode strict se conforme uniquement à la norme, mais d'autres modes supportent les formes utilisées par les navigateurs dans le passé. Le but est la rétrocompatibilité avec les anciens contenus. La DTD stricte actuelle se trouve ici : www.w3.org/TR/html4/strict.dtd.

L'arbre de sortie, « l'arbre syntaxique », est constitué de nœuds éléments et attributs DOM. DOM est l'acronyme de « Document Object Model ». Il s'agit de la représentation « objet » du document HTML ainsi que l'interface des éléments HTML avec le monde extérieur comme JavaScript.

La racine de l'arbre est l'objet « document ».

Le DOM possède une relation quasiment un-à-un avec le balisage. Par exemple, ce code :

<html>
   <body>
      <p>
         Hello World
      </p>
   <div> <img src="example.png"/></div>
   </body>
</html>

Se traduirait par l'arbre DOM suivant :

Comme pour HTML, DOM est spécifié par l'organisation W3C , voir www.w3.org/DOM/DOMTR. C'est une spécification générique pour la manipulation de documents. Un document spécifique décrit les éléments propres à HTML. La définition HTML peut être trouvée ici : www.w3.org/TR/2003/REC-DOM-Level-2-HTML-20030109/idl-definitions.html.

Quand je dis que l'arbre contient des nœuds DOM, je veux dire que l'arbre est constitué d'éléments qui mettent en œuvre l'une des interfaces DOM. Les navigateurs utilisent des implémentations concrètes qui ont d'autres attributs utilisés par le navigateur en interne.

Comme nous l'avons vu auparavant, le langage HTML ne peut pas être analysé en utilisant des analyseurs de bas en haut ou de haut en bas.

Les raisons sont :

1. La nature indulgente du langage ;
2. Le fait que les navigateurs ont une tolérance traditionnelle aux erreurs pour supporter les cas bien connus de HTML non valide ;
3. Le processus d'analyse est réentrant. Habituellement, la source ne change pas pendant l'analyse, mais en HTML, des balises de script contenant document.write peuvent ajouter des entrées supplémentaires, de sorte que le processus d'analyse modifie en fait l'entrée.

Incapables d'utiliser les techniques traditionnelles d'analyse, les navigateurs doivent utiliser des analyseurs personnalisés pour lire le HTML.

L'algorithme d'analyse est décrit en détail par la spécification HTML5. L'algorithme se compose de deux étapes - la séparation des mots-clés et la construction de l'arbre.

La séparation est l'analyse lexicale, transformer l'entrée en mots-clés. Parmi les mots-clés HTML, on trouve les balises de début, de fin, les noms d'attributs et les valeurs d'attributs.

L'analyse lexicale reconnaît le mot-clé, le donne au constructeur de l'arbre et consomme le caractère suivant pour reconnaître le mot-clé suivant. Et ainsi de suite jusqu'à la fin de l'entrée.

La sortie de l'algorithme est un mot-clé HTML. L'algorithme est exprimé comme une machine à états. Chaque état consomme un ou plusieurs caractères du flux d'entrée et met à jour l'état suivant en fonction de ces caractères. La décision est influencée par l'état courant et par l'état de la construction de l'arbre. Cela signifie que le même caractère consommé donnera des états de sortie différents en fonction de l'état courant. L'algorithme est trop complexe pour être décrit entièrement, alors voyons un exemple simple qui nous aidera à comprendre le principe.

Exemple simple, lire le code HTML suivant :

<html>
   <body>
      Hello world
   </body>
</html>

L'état initial est « données ». Lorsque le caractère < est lu, l'état est changé en « ouvert ». Consommer un caractère provoque la création d'un « début de nom », l'état est changé en « nom ». L'état ne change pas jusqu'à ce que le caractère > soit lu, chaque caractère étant ajouté au nom. Dans notre cas, le mot-clé créé est html.

Lorsque le caractère > est atteint, le mot-clé courant est émis et l'état redevient « données ». La balise <body> sera traitée par le même processus. Pour l'instant, les balises html et body ont été émises. Nous sommes maintenant de retour à l'état « données ». Consommer le caractère H de Hello world va provoquer la création et l'émission d'un mot-clé caractère, cela continue jusqu'à ce que le < de </body> soit atteint. Il y aura émission d'un mot-clé caractère pour chaque caractère de Hello world.

Nous sommes maintenant de retour à l'état « ouvert ». Consommer le caractère suivant / provoquera la création d'un mot-clé balise de fin et le passage à l'état « nom ». Encore une fois nous restons dans cet état jusqu'à ce que nous atteignons >. Ensuite le mot-clé est émis et nous revenons à l'état « données ». L'entrée </html> sera traitée comme précédemment.

Lorsque l'analyseur est créé, l'objet Document est créé. Pendant la phase de construction de l'arbre, l'arbre DOM avec le Document dans sa racine est modifié et les éléments sont ajoutés. Chaque nœud émis par l'analyseur lexical est traité par le constructeur d'arbre. Pour chacun des mots-clés définis par la spécification DOM, un élément DOM sera créé. Sauf s'il est ajouté à l'arbre DOM, il est ajouté à une pile d'éléments ouverts. Cette pile est utilisée pour corriger les déséquilibres d'imbrication et les balises non fermées. L'algorithme est aussi décrit comme une machine à états. Les états sont appelés « modes d'insertion ».

Voyons le processus de construction de l'arbre pour cet exemple :

<html>
   <body>
      Hello world
   </body>
</html>

L'entrée à l'étape de la construction de l'arbre est une séquence de mots-clés issus de l'analyse lexicale. Le premier état est l'état « initial ». La réception du mot-clé html provoquera le passage à l'état « avant html » et un nouveau traitement de ce mot-clé pour ce mode. Cela entraînera la création de l'élément HTMLHtmlElement qui sera ajouté à la racine de l'objet Document.

L'état sera alors changé en « avant head ». Nous recevons ensuite le mot-clé body. Un HTMLHeadElement est créé implicitement, bien que nous n'avons pas de mot-clé head et il est ajouté à l'arbre.

Nous passons maintenant de l'état « dans entête » à « après entête ». Le mot-clé body est traité à nouveau, un HTMLBodyElement est créé et inséré et l'état est ensuite modifié en « dans corps ».

Les mots-clés caractère de la chaîne « Hello world » sont maintenant reçus. Le premier va causer la création et l'insertion d'un nœud text et les autres caractères seront ajoutés à ce nœud.

La réception du mot-clé fin de corps va provoquer le changement d'état « après corps ». Nous allons maintenant recevoir la balise de fin html qui va changer l'état en « après après corps ». La réception du mot-clé fin de fichier termine l'analyse.

À ce stade, le navigateur va marquer le document comme interactif et lancer l'analyse des scripts marqués comme « différés » - ceux qui doivent être exécutés après que le document a été analysé. L'état document sera alors réglé sur « terminé » et un événement « chargement » est déclenché.

Vous pouvez voir les algorithmes complets pour l'analyse et la construction des arbres dans la spécification HTML5.

Vous n'aurez jamais une erreur « syntaxe invalide » avec une page HTML. Les navigateurs corrigent les contenus invalides et continuent.

Prenez ce code HTML par exemple :

<html>
   <mytag>
   </mytag>
   <div>
      <p>
   </div>
      Really lousy HTML
   </p>
</html>

Je dois avoir violé environ un million de règles (mytag n'est pas une balise standard, mauvaise imbrication des balises p et div et plus encore), mais le navigateur le montre quand même correctement et ne se plaint pas. Ainsi, beaucoup de code de l'analyseur sert à corriger les erreurs des codeurs HTML.

La gestion des erreurs est tout à fait compatible avec les navigateurs, mais étonnamment, elle ne fait pas partie de la spécification HTML actuelle. Comme les boutons « Favoris », « Précédent » et « Suivant », c'est juste quelque chose qui s'est développé dans les navigateurs au fil des années. On connaît des constructions HTML invalides qui se répètent sur de nombreux sites et les navigateurs essayent de les résoudre d'une manière conforme avec les autres navigateurs.

La spécification HTML5 définit certaines de ces exigences. Webkit résume cela très bien dans les commentaires du début de la classe de l'analyseur HTML.

L'analyseur analyse l'entrée sous forme de mot-clé dans le document, en construisant l'arbre du document. Si le document est bien formé, son analyse est simple.

Malheureusement, nous avons à gérer de nombreux documents HTML qui ne sont pas bien formés de sorte que l'analyseur doit être tolérant avec les erreurs.

Nous devons faire attention au moins aux conditions d'erreur suivantes :

1. 1. L'élément ajouté est explicitement interdit à l'intérieur de certaines balises extérieures. Dans ce cas, nous devrions fermer toutes les balises jusqu'à celle qui interdit l'élément et l'ajouter à la suite ;
   2. Nous ne sommes pas autorisés à ajouter l'élément directement. Il se pourrait que la personne qui écrit le document ait oublié quelques balises entre les deux (ou que la balise entre les deux est en option). Ce pourrait être le cas avec les balises HTML suivantes : HEAD BODY TBODY TR TD LI (en ai-je oublié une ?) ;
   3. Nous voulons ajouter un élément de bloc à l'intérieur d'un élément en ligne. Fermer tous les éléments en ligne jusqu'au bloc supérieur suivant ;
   4. Si cela ne fonctionne pas, fermer les éléments jusqu'à être autorisé à ajouter l'élément ou ignorer la balise.

Voyons quelques exemples de tolérance aux erreurs de Webkit.

3-2-9-1. </br> à la place de <br>▲

if (t->isCloseTag(brTag) && m_document->inCompatMode()) {
   reportError(MalformedBRError);
   t->beginTag = true;
}

3-2-9-2. Une table parasite▲

<table>
   <table>
      <tr><td>inner table</td></tr>
   </table>
   <tr><td>outer table</td></tr>
</table>

<table>
   <tr><td>outer table</td></tr>
</table>
<table>
   <tr><td>inner table</td></tr>
</table>

if (m_inStrayTableContent && localName == tableTag)
   popBlock(tableTag);

3-2-9-3. Imbrication de formulaires▲

if (!m_currentFormElement) {
   m_currentFormElement = new HTMLFormElement(formTag, m_document);
}

3-2-9-4. Une hiérarchie trop profonde▲

bool HTMLParser::allowNestedRedundantTag(const AtomicString& tagName)
{
unsigned i = 0;
for (HTMLStackElem* curr = m_blockStack;
      i < cMaxRedundantTagDepth && curr && curr->tagName == tagName;
   curr = curr->next, i++) { }
return i != cMaxRedundantTagDepth;
}

3-2-9-5. Balises HTML ou body fermantes mal placées▲

if (t->tagName == htmlTag || t->tagName == bodyTag )
   return;

Webkit utilise les générateurs d'analyseur Flex et Bison pour créer des analyseurs de grammaire CSS. Si vous vous souvenez de l'introduction aux analyseurs, Bison créé un analyseur de bas en haut décalage-réduction. Firefox utilise un analyseur de haut en bas écrit manuellement. Dans les deux cas, chaque fichier CSS est analysé dans une feuille de style, chaque objet contient des règles CSS. Les objets de la règle CSS contiennent des objets de sélection et de déclaration ainsi que d'autres objets de la grammaire CSS.

Le modèle du Web est synchrone. Les auteurs s'attendent à ce que les scripts soient analysés et exécutés immédiatement lorsque l'analyseur atteint une balise <script>. L'analyse du document s'arrête jusqu'à ce que le script ait été exécuté. Si le script est externe, alors la ressource doit être d'abord récupérée sur le réseau, ceci est fait aussi de manière synchrone, l'analyse s'arrête jusqu'à ce que la ressource soit récupérée. C'était le modèle durant de nombreuses années et c'est également spécifié dans le HTML 4 et 5. Les auteurs pouvaient marquer le script comme « reporté » et donc il n'interrompait pas l'analyse du document, mais était exécuté après avoir été analysé. HTML5 ajoute une option pour marquer le script comme asynchrone de sorte qu'il soit analysé et exécuté par un thread différent.

Aussi bien Webkit que Firefox font cette optimisation. Pendant l'exécution de scripts, un autre thread analyse le reste du document et découvre les autres ressources qui doivent être chargées depuis le réseau et les charge. De cette façon, les ressources peuvent être chargées sur des connexions parallèles et la vitesse globale est meilleure. Remarquez que l'analyse spéculative ne modifie pas l'arborescence DOM, ceci est laissé à la charge de l'analyseur principal, elle ne fait qu'analyser les références à des ressources externes, comme les scripts externes, les feuilles de style et les images.

D'autre part, les feuilles de style ont un modèle différent. Sur le plan conceptuel, il semble que puisque les feuilles de style ne changent pas l'arborescence DOM, il n'y a aucune raison d'attendre leur chargement et d'arrêter l'analyse syntaxique du document. Il y a tout de même un problème, pour les scripts demandant des informations de style durant l'analyse du document. Si le style n'est pas encore chargé et analysé, le script va obtenir des réponses fausses et apparemment, cela a causé beaucoup de problèmes. Cela semble être un cas limite, mais c'est tout à fait commun. Firefox bloque tous les scripts tant qu'une feuille de style est en cours de chargement et d'analyse. Webkit bloque les scripts seulement quand ils tentent d'accéder à certaines propriétés de style qui peuvent être affectées par des feuilles de style non encore chargées.

Les nœuds de Webkit référencent des objets style (RenderStyle) Ces objets peuvent être partagés par les nœuds sous certaines conditions. Les nœuds sont frères ou cousins et :

1. Les éléments doivent être dans le même état en ce qui concerne la souris (par exemple, on ne peut être en mode :hover si l'autre ne l'est pas) ;
2. Aucun élément ne doit avoir un identifiant ;
3. Les noms de balises doivent correspondre ;
4. Les attributs de classe doivent correspondre ;
5. L'ensemble des attributs associés doivent être identiques ;
6. L'état du lien doit correspondre ;
7. L'état du focus doit correspondre ;
8. Aucun élément ne doit être affecté par un sélecteur d'attribut ; affecté est défini comme ayant une correspondance avec un sélecteur contenant un sélecteur d'attribut quelle que soit sa position dans le sélecteur global ;
9. Il ne doit pas y avoir d'attribut de style sur les éléments ;
10. Il ne doit y avoir aucun sélecteur d'enfants. WebCore utilise simplement un commutateur global lorsqu'un sélecteur d'enfant est rencontré et désactive le partage de style pour le document entier quand ils sont présents. Cela comprend le sélecteur + et les sélecteurs comme :first-child et :last-child.

Firefox dispose de deux arbres supplémentaires pour un calcul plus facile du style, l'arbre des règles et l'arbre de contexte de style. Webkit a aussi des objets de style, mais ils ne sont pas stockés dans un arbre, comme l'arbre de contexte de style, seul le nœud DOM pointe sur son style.

Les contextes de style contiennent des valeurs finales. Les valeurs sont calculées en appliquant toutes les règles d'appariement dans le bon ordre et en effectuant les manipulations qui les transforment de valeurs logiques à valeurs concrètes. Par exemple, si la valeur logique est le pourcentage par rapport à l'écran, il sera calculé et transformé en unités absolues. L'idée derrière l'arbre des règles est très intelligente. Elle permet de partager ces valeurs entre les nœuds pour éviter de les calculer à nouveau. Cela économise aussi de l'espace.

L'ensemble des règles adaptées sont stockées dans un arbre. Les nœuds du bas d'un chemin sont prioritaires. L'arbre contient tous les chemins pour la correspondance de règles qui ont été trouvées. Le stockage des règles se fait paresseusement. L'arbre n'est pas calculé au début de chaque nœud, mais à chaque fois qu'un style de nœud doit être calculé, le chemin calculé est ajouté à l'arbre.

L'idée est de voir l'arbre des chemins comme des mots dans un dictionnaire. Disons que nous avons déjà calculé cet arbre règle :

Supposons que nous devions faire correspondre des règles pour un autre élément dans l'arborescence de contenu et que nous trouvons que les règles appariées (dans le bon ordre) sont B - E - I. Nous avons déjà ce chemin dans l'arbre, car nous avons déjà calculé le trajet A - B - E - I - L. Nous avons maintenant moins de travail à faire.

Voyons comment cet arbre nous permet d'économiser du travail.

4-3-2-1. La division par structure▲

4-3-2-2. Calculer les contextes de style en utilisant l'arbre des règles▲

Lors du calcul du contexte de style pour un élément donné, on calcule d'abord un chemin dans l'arbre des règles ou on en utilise un existant. Nous commençons alors par appliquer les règles dans le chemin pour combler les structures dans notre nouveau contexte style. Nous commençons à la partie basse du chemin, celui avec la plus haute priorité (généralement le sélecteur le plus spécifique) et parcourir l'arborescence jusqu'à ce que notre structure soit pleine. S'il n'y a pas de spécification pour la structure dans ce nœud règle, alors nous pouvons grandement optimiser, on remonte l'arborescence jusqu'à ce qu'on trouve un nœud qui satisfait pleinement et nous pointons tout simplement dessus, c'est la meilleure optimisation, la structure entière est partagée. Cela permet d'économiser le calcul des valeurs finales et la mémoire.

Si nous trouvons des définitions partielles, nous remontons l'arbre jusqu'à ce que la structure soit complète.

Si nous n'avons pas trouvé de définitions de notre structure, alors, dans le cas où la structure est de type « hérité », nous pointons vers la structure du parent dans l'arborescence des contextes, dans ce cas, nous avons également réussi à partager la structure. Si c'est une structure « remise à zéro », alors les valeurs par défaut sont utilisées.

Si le nœud le plus spécifique ajoute des valeurs, alors nous devons faire quelques calculs supplémentaires pour la transformer en valeurs réelles. Ensuite nous mettons en cache le résultat dans le nœud de l'arbre de sorte qu'il puisse être utilisé par des enfants.

Dans le cas où un élément a un frère qui pointe vers le nœud de l'arbre, alors le contexte de style complet peut être partagé entre eux.

Voyons un exemple, supposons que nous ayons ce HTML :

 

Sélectionnez

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.

<html>
   <body>
      <div class="err" id="div1">
         <p>
            this is a <span class="big"> big error </span>
            this is also a
            <span class="big"> very big error</span> error
         </p>
      </div>
      <div class="err" id="div2">another error</div>
   </body>
</html>

Et les règles suivantes :

 

Sélectionnez

1.
2.
3.
4.
5.
6.

div {margin:5px;color:black}
.err {color:red}
.big {margin-top:3px}
div span {margin-bottom:4px}
#div1 {color:blue}
#div2 {color:green}

Pour simplifier les choses, disons que nous devons remplir seulement deux structures, la structure couleur et la structure marge. La structure couleur contient un seul membre, la couleur. La structure marge contient les quatre côtés.

L'arbre de règles résultant ressemblera à ceci (les nœuds sont identifiés par le nom du nœud et le numéro de la règle sur laquelle ils pointent) :

L'arbre des contextes ressemblera à ceci (le nom de nœud est le nom de règle générale vers laquelle il pointe) :

Supposons que nous analysions le code HTML et que nous arrivions à la deuxième balise <div>. Nous devons créer un cadre de style pour ce nœud et remplir ses structures style.

Nous allons faire correspondre les règles et découvrir que les règles correspondantes pour le <div> sont 1, 2 et 6. Cela signifie qu'il y a déjà un chemin d'accès existant dans l'arborescence que notre élément peut utiliser, nous avons juste besoin d'ajouter un autre nœud pour la règle 6 (le nœud F dans l'arbre de règles).

Nous allons créer un contexte de style et le mettre dans l'arbre des contextes. Le nouveau contexte de style va pointer vers le nœud F dans l'arbre de règles.

Nous avons maintenant besoin de remplir les structures du style. Nous allons commencer par remplir la structure de marge. Puisque la règle du nœud F ne modifie pas la structure de marge, nous pouvons remonter dans l'arbre jusqu'à ce qu'on trouve une structure en cache calculée dans un nœud d'insertion précédent et l'utiliser. Nous allons la trouver avec le nœud B, qui est le nœud le plus élevé avec les règles de marge spécifiées.

Nous avons une définition de la structure couleur, donc on ne peut pas utiliser une structure en cache. Puisque la couleur n'a qu'un attribut, nous n'avons pas besoin d'aller dans l'arbre pour en remplir d'autres. Nous allons calculer la valeur finale (convertir la chaîne en RVB, etc.) et mettre en cache la structure calculée sur ce nœud.

Le travail sur le deuxième élément <span> est encore plus facile. Nous faisons correspondre les règles et arrivons à la conclusion qu'il pointe sur la règle G, comme le <span> précédent. Puisque ce sont des frères qui pointent vers le même nœud, nous pouvons partager le contexte de style tout simplement en pointant dans le contexte du <span> précédent.

Pour les structures qui contiennent des règles qui sont héritées du parent, la mise en cache se fait sur l'arbre de contexte (la propriété de couleur est en fait héritée, mais Firefox la traite comme « remise à zéro » et la met en cache sur l'arbre de règles).

Par exemple, si nous ajoutons des règles de polices dans un paragraphe :

 

Sélectionnez

1.

p {font-family:Verdana;font size:10px;font-weight:bold}

Alors, l'élément de paragraphe, qui est un enfant de <div> dans l'arbre de contexte, aurait pu partager la structure de police de son parent. Cela serait le cas si aucune règle de police n'avait été spécifiée pour le paragraphe.

Avec Webkit, qui ne dispose pas d'un arbre de règles, les déclarations correspondantes sont traversées quatre fois. En premier, les propriétés non importantes (propriétés qui doivent être appliquées d'abord parce que d'autres dépendent d'elles, comme l'affichage) sont appliquées, ensuite, les propriétés importantes, puis les propriétés normales et enfin les propriétés normales pour les règles importantes. Cela signifie que les propriétés qui apparaissent plusieurs fois seront résolues selon l'ordre de cascade correct. C'est le dernier qui l'emporte.

Donc, pour résumer, le partage des objets style (tout ou partie des structures à l'intérieur) résout les problèmes 1 et 3. L'arbre de règles Firefox contribue également à l'application des propriétés dans le bon ordre.

Il existe plusieurs sources pour les règles de style :

• les règles CSS, soit dans des feuilles de style externes, soit dans des balises style :
   

  Sélectionnez

  1.
  

  p {color:blue}
  

• des attributs de style en ligne comme :
   

  Sélectionnez

  1.
  

  <p style="color:blue" />
  

• des attributs HTML visuels (qui sont mappés aux règles de style correspondantes) :

<p bgcolor="blue" />

Les deux derniers sont facilement adaptés à l'élément, car ils possèdent les attributs de style et attributs HTML qui peuvent être indexés en utilisant l'élément comme clé.

Comme indiqué précédemment dans le problème 2, la recherche de la règle CSS peut être plus compliquée. Pour résoudre cette difficulté, les règles sont manipulées pour en faciliter l'accès.

Après l'analyse de la feuille de style, les règles sont ajoutées à une des tables de hachage, en fonction de la sélection. Il y a des tables dont l'index est l'identifiant, le nom de classe, le nom de balise et une table générale pour tout ce qui ne rentre pas dans ces catégories. Si le sélecteur est un identifiant, la règle sera ajoutée à la table des identifiants, s'il s'agit d'une classe, elle sera ajoutée à la table des classes, etc.

Cette manipulation rend beaucoup plus facile la recherche des règles. Il n'est pas nécessaire de regarder dans chaque déclaration, nous pouvons extraire les règles applicables à un élément à partir des tables. Cette optimisation élimine 95 % et plus des règles, de sorte qu'elles ne devraient même pas être prises en compte lors du processus d'appariement ().

Voyons par exemple les règles de style suivantes :

p.error {color:red}
#messageDiv {height:50px}
div {margin:5px}

La première règle est insérée dans la table des classes. La seconde dans la table des identifiants et la troisième dans la table des balises.

Pour le morceau HTML suivant :

<p class="error">an error occurred </p>
<div id=" messageDiv">this is a message</div>

Nous allons d'abord essayer de trouver des règles pour l'élément p. La table des classes contiendra une clé error en vertu de laquelle la règle de p.error est trouvée. La balise div aura une règle qui correspond dans la table des identifiants (la clé est l'identifiant) et la table des balises. Ainsi, le travail qui reste à faire est de savoir quelles sont les règles qui ont été extraites par les index qui correspondent vraiment.

Par exemple, si la règle de la div est :

table div {margin:5px}

elle sera toujours extraite de la table des balises, parce que la clé est le sélecteur de droite, mais elle ne correspondrait pas à notre élément div, qui n'a pas de parent de type table.

À la fois Webkit et Firefox font cette manipulation.

L'objet style a des propriétés correspondant à chaque attribut visuel (tous les attributs CSS, mais plus génériques). Si la propriété n'est définie par aucune des règles adaptées, alors certaines propriétés peuvent être héritées du style de l'élément parent. D'autres propriétés ont des valeurs par défaut.

Le problème commence lorsqu'il y a plus d'une définition, voici l'ordre pour résoudre ce problème.

4-3-4-1. L'ordre des feuilles de style▲

4-3-4-2. La spécificité▲

* {} /* a=0 b=0 c=0 d=0 -> specificity = 0,0,0,0 */
li {} /* a=0 b=0 c=0 d=1 -> specificity = 0,0,0,1 */
li:first-line {} /* a=0 b=0 c=0 d=2 -> specificity = 0,0,0,2 */
ul li {} /* a=0 b=0 c=0 d=2 -> specificity = 0,0,0,2 */
ul ol+li {} /* a=0 b=0 c=0 d=3 -> specificity = 0,0,0,3 */
h1 + *[rel=up]{} /* a=0 b=0 c=1 d=1 -> specificity = 0,0,1,1 */
ul ol li.red {} /* a=0 b=0 c=1 d=3 -> specificity = 0,0,1,3 */
li.red.level {} /* a=0 b=0 c=2 d=1 -> specificity = 0,0,2,1 */
#x34y {} /* a=0 b=1 c=0 d=0 -> specificity = 0,1,0,0 */
style="" /* a=1 b=0 c=0 d=0 -> specificity = 1,0,0,0 */

4-3-4-3. Trier les règles▲

static bool operator >(CSSRuleData& r1, CSSRuleData& r2)
{
   int spec1 = r1.selector()->specificity();
   int spec2 = r2.selector()->specificity();
   return (spec1 == spec2) : r1.position() > r2.position() : spec1 > spec2;
}

Le positionnement relatif : il est positionné comme d'habitude puis déplacé de la valeur requise.

Une boite flottante est déplacée vers la gauche ou vers la droite d'une ligne. La caractéristique à noter est que les autres boites vont s'agencer autour d'elle. Le code HTML :

<p>
   <img style="float:right" src="images/image.gif" width="100" height="100">
   Lorem ipsum dolor sit amet, consectetuer...
</p>

Ressemblerait à :

La mise en page est définie exactement, quel que soit le flux normal. L'élément ne participe pas au flux normal. Les dimensions sont par rapport au conteneur. Avec fixe, le conteneur est la vue du navigateur.

Notez, une boite fixe ne bougera pas, même quand on fait défiler le document !