--- url: 'https://simonerescio.it/2014/05/come-funzionano-i-browser-dietro-le-quinte-dei-web-browser-moderni' title: 'Come funzionano i Browser : dietro le quinte dei web browser moderni' author: name: Simone Rescio url: 'https://simonerescio.it/chi-sono/' date: '2014-05-18T14:17:09+02:00' modified: '2026-04-20T22:16:12+02:00' type: post summary: 'Traduzione italiana dell''articolo di Tali Garsiel su come funzionano i browser moderni: motori WebKit e Gecko, parsing, DOM e rendering.' categories: - WebTech tags: - Albero di Render - Chrome - CSS - css3 - display - Disposizione - DOM - Firefox - Gecko - inline-block - interfaccia utente - javascript - Parser - WebKit image: 'https://simonerescio.it/wp-content/uploads/2014/05/cross-browser.jpg' published: true --- # Come funzionano i Browser : dietro le quinte dei web browser moderni Questa esaustiva introduzione sul funzionamento interno dei motori WebKit e Gecko è il frutto del duro lavoro di ricerca svolto dalla sviluppatrice israeliana **Tali Garsiel**. Nel corso di alcuni anni ha studiato i dati pubblici sul funzionamento dei browser, investendo molto tempo ad indagare direttamente nel loro codice sorgente, la sua premessa : > Negli anni del dominio di IE al 90% di diffusione non c’era altra scelta se non pensare al browser come una “scatola nera”, ma adesso, con i browser open source che posseggono [più della metà dello share di utilizzo](http://techcrunch.com/2011/08/01/open-web-browsers/), è il momento buono per sbirciare sotto il cofano del motore e vedere cosa c’è dentro un web browser. Ebbene, ciò che si trova all’interno sono milioni di righe di C++ … La presente traduzione italiana curata da [me](https://simonerescio.it/chi-sono/) si basa sulla versione pubblicata su [HTML5rocks.com](http://www.html5rocks.com/en/tutorials/internals/howbrowserswork/), adattata da **[Paul Irish](http://www.html5rocks.com/en/profiles/#paulirish)**, il quale aggiunge a sua volta : > In qualità di sviluppatore web, **apprendere le operazioni interne del browser ti aiuterà a compiere decisioni migliori e comprendere le ragioni alla base di molte buone prassi di sviluppo**. Nonostante la copiosa lunghezza del documento, vale la pena investire del tempo per scavarvi affondo; è garantito che sarai felice di averlo fatto. La versione *originale* è disponibile sul sito dell’autrice, al seguente indirizzo : [http://taligarsiel.com/Projects/howbrowserswork1.htm](http://taligarsiel.com/Projects/howbrowserswork1.htm) . - [1. Introduzione](#introduzione) [1.1. I browser di cui parleremo](#i-browser-di-cui-parleremo) - [1.2. Le funzionalità principali dei browser](#le-funzionalita-principali-dei-browser) - [1.3. La struttura di alto livello del browser](#la-struttura-di-alto-livello-del-browser) - [2. Il motore di rendering](#il-motore-di-rendering) [2.1. Motori di rendering](#motori-di-rendering) - [2.2. Il flusso principale](#il-flusso-principale) - [2.3. Esempi del flusso principale](#esempi-del-flusso-principale) - [3. Analisi e costruzione dell’albero del DOM](#analisi-e-costruzione-dell8217albero-del-dom) [3.1. Nozioni sui parser](#nozioni-sui-parser) [3.1.1. Grammatica](#grammatica) - [3.1.2. Combinazione Parser-Lexer](#combinazione-parser-lexer) - [3.1.3. Traduzione](#traduzione) - [3.1.4. Esempio di parsing](#esempio-di-parsing) - [3.1.5. Definizioni formali di vocabolario e sintassi](#definizioni-formali-di-vocabolario-e-sintassi) - [3.1.6. Tipologie di parser](#tipologie-di-parser) - [3.1.7. Generazione automatica dei parser](#generazione-automatica-dei-parser) - [3.2. Parser HTML](#parser-html) [3.2.1. La definizione della grammatica HTML](#la-definizione-della-grammatica-html) - [3.2.2. Non è una grammatica libera dal contesto](#non-e-una-grammatica-libera-dal-contesto) - [3.2.3. HTML DTD](#html-dtd) - [3.2.4. DOM](#dom) - [3.2.5. L’algoritmo di parsing](#l8217algoritmo-di-parsing) - [3.2.6. L’algoritmo di frammentazione](#l8217algoritmo-di-frammentazione) - [3.2.7. Algoritmo di costruzione dell’alberatura](#algoritmo-di-costruzione-dell8217alberatura) - [3.2.8. Azioni al termine dell’analisi](#azioni-al-termine-dell8217analisi) - [3.2.9. La tolleranza agli errori del browser](#la-tolleranza-agli-errori-del-browser) - [3.3. Parser CSS](#parser-css) [3.3.1. Parser CSS di WebKit](#parser-css-di-webkit) - [3.4. L’ordine di processamento degli script e dei fogli di stile](#l8217ordine-di-processamento-degli-script-e-dei-fogli-di-stile) [3.4.1. Scripts](#scripts) - [3.4.2. Analisi speculativa](#analisi-speculativa) - [3.4.3. Fogli di stile](#fogli-di-stile) - [4. Costruzione dell’albero di render](#costruzione-dell8217albero-di-render) [4.1. La relazione tra Albero di Render e Albero del DOM](#la-relazione-tra-albero-di-render-e-albero-del-dom) - [4.2. Il flusso di costruzione dell’albero](#il-flusso-di-costruzione-dell8217albero) - [4.3. Computazione degli stili](#computazione-degli-stili) [4.3.1. Condivisione dei dati degli stili](#condivisione-dei-dati-degli-stili) - [4.3.2. L’alberatura di regole di Firefox](#l8217alberatura-di-regole-di-firefox) [4.3.2.1. Divisione in struct](#divisione-in-struct) - [4.3.2.2. Computazione del contesto di stile usando l’albero di regole](#computazione-del-contesto-di-stile-usando-l8217albero-di-regole) - [4.3.3. Manipolazione delle regole per una corrispondenza semplice](#manipolazione-delle-regole-per-una-corrispondenza-semplice) - [4.3.4. Applicazione delle regole nell’ordine di cascata corretto](#applicazione-delle-regole-nell8217ordine-di-cascata-corretto) [4.3.4.1. Ordine di cascata dei fogli di stile](#ordine-di-cascata-dei-fogli-di-stile) - [4.3.4.2. Specificità](#specificita) - [4.3.4.3. Filtraggio delle regole](#filtraggio-delle-regole) - [4.4. Processo graduale](#processo-graduale) - [5. Disposizione](#disposizione) [5.1. Sistema dei bit sporchi](#sistema-dei-bit-sporchi) - [5.2. Layout globale e incrementale](#layout-globale-e-incrementale) - [5.3. Layout asincrono e sincrono](#layout-asincrono-e-sincrono) - [5.4. Ottimizzazioni](#ottimizzazioni) - [5.5. Il processo di layout](#il-processo-di-layout) - [5.6. Calcolo della larghezza](#calcolo-della-larghezza) - [5.7. Line breaking](#line-breaking) - [6. Pittura](#pittura) [6.1. Globale e incrementale](#globale-e-incrementale) - [6.2. L’ordine di Pittura](#l8217ordine-di-pittura) - [6.3. Lista di visualizzazione di Firefox](#lista-di-visualizzazione-di-firefox) - [6.4. Memorizzazione dei rettangoli in WebKit](#memorizzazione-dei-rettangoli-in-webkit) - [7. Cambiamenti dinamici](#cambiamenti-dinamici) - [8. I threads del motore di rendering](#i-threads-del-motore-di-rendering) [8.1. Event loop](#event-loop) - [9. Modello visuale CSS2](#modello-visuale-css2) [9.1. Il canvas](#il-canvas) - [9.2. CSS Box model](#css-box-model) - [9.3. Schema di posizionamento](#schema-di-posizionamento) - [9.4. Tipi di blocchi](#tipi-di-blocchi) - [9.5. Posizionamento](#posizionamento) [9.5.1. Relativo](#relativo) - [9.5.2. Float](#float) - [9.5.3. Assoluto e fixed](#assoluto-e-fixed) - [9.6. Rappresentazione a livelli](#rappresentazione-a-livelli) - [10. Risorse](#risorse) # Introduzione I web browser sono i software più utilizzati. In questa introduzione, spiegherò come funzionano dietro le quinte. Vedremo cosa accade quando digiti `google.com` nella barra degli indirizzi finché non appare la pagina di Google nella schermata del browser. ## I browser di cui parleremo Ci sono cinque browser principali usati oggigiorno su desktop : Chrome, Internet Explorer, Firefox, Safari e Opera. Sul mobile, i browser principali sono Android Browser, iPhone, Opera Mini ed Opera Mobile, UC Browser, il browser di Nokia S40/S60 e Chrome, i quali sono tutti, fatta eccezione per Opera, basati su WebKit. Proporrò degli esempi tratti dai browser open source Firefox e Chrome, e Safari (che è parzialmente open source). Stando alle [statistiche di StatCounter](http://gs.statcounter.com/) (aggiornate a Giugno 2013) Chrome, Firefox e Safari costituiscono circa il 71% degli utenti globali per l’uso di browser su desktop. Su mobile, Android Browser, iPhone e Chrome costituiscono circa il 54% di utilizzatori. ## Le funzionalità principali dei browser La funzione principale di un browser è di presentare la risorsa web prescelta, richiedendola da un server e mostrandola nella finestra del browser. La risorsa è solitamente un documento HTML, ma può essere anche un PDF, un’immagine, o un altro tipo di contenuto. L’ubicazione della risorsa viene specificata dall’utente tramite URI (Uniform Resource Identifier). Il modo in cui la maggior parte dei browser interpreta e mostra i file HTML è dichiarato nelle specifiche HTML e CSS. Queste specifiche sono manutenute dall’organizzazione del [W3C](http://www.w3.org/) (World Wide Web Consortium), che è una organizzazione per gli standard del web. Per anni i browser si sono conformati in parte alle specifiche sviluppando le proprie estensioni. Questo ha causato gravi problemi di compatibilità per gli sviluppatori web. Oggi la maggior parte dei browser più o meno si conforma alle specifiche. Le interfacce utente del browser hanno molto in comune tra loro. Tra gli elementi dell’interfaccia condivisi figurano : - La *barra degli indirizzi* per inserire una URI - Tasti *Avanti* e *Indietro* - Opzioni per i *preferiti* - Tasti *Ricarica* e *Stop* per controllare il caricamento del documento corrente. - Tasto *Home* che riporta la pagina alla propria pagina iniziale. Stranamente, l’interfaccia utente del browser non è definita in nessuna specifica formale, deriva semplicemente dalla buona prassi che si è formata tramite anni di esperienza con i browser che si imitavano a vicenda. Le specifiche HTML5 non definiscono gli elementi di UI che un browser deve avere, ma elenca alcuni elementi comuni. Tra questi la barra degli indirizzi, la barra di stato e degli strumenti. Ci sono, ovviamente, caratteristiche uniche e specifiche a ciascun browser come il download manager di Firefox. ## La struttura di alto livello del browser I componenti principali del browser sono : - **L’interfaccia utente** : include la barra degli indirizzi, tasti indietro/avanti, menu bookmark etc. Ogni parte visibile del browser eccetto la finestra dove viene visualizzata la pagina richiesta. - **Il motore del browser** : ordina le azioni tra la UI e il motore di rendering. - **Il motore di rendering** : responsabile per la visualizzazione dei contenuti richiesti. Ad esempio se il contenuto richiesto è HTML, il motore di rendering analizza l’HTML e il CSS e mostra il contenuto analizzato sullo schermo. - **Networking** : per le chiamate di rete come le richieste HTTP, usando diverse implementazioni per diverse piattaforme dietro un interfaccia agnostica alla piattaforma usata. - **UI backend** : usata per disegnare widgets basilari come le combo box e le finestre. Questo backend espone un interfaccia generica che non è specifica di una piattaforma. In profondità utilizza metodi della UI del sistema operativo. - **Interprete JavaScript** : usato per analizzare ed eseguire il codice JavaScript. - **Memorizzazione Dati** : è un livello di persistenza. Il browser può avere necessità di salvare diverse tipologie di dati localmente, come i cookie. I browser inoltre supportano meccanismi di memorizzazione come localStorage, IndexedDB, WebSQL e FileSystem. [![browser-components](https://simonerescio.it/wp-content/uploads/2014/05/browser-components.png)](https://simonerescio.it/?attachment_id=514)*Componenti del Browser* È importante notare che i browser come Chrome eseguono *istanze multiple del motore di rendering* : uno per ciascuna tab. Ogni tab è eseguita in un processo separato. # Il motore di rendering La responsabilità del motore di rendering è … renderizzare, ovvero mostrare il contenuto richiesto nella finestra del browser. Il motore di rendering può mostrare nativamente documenti HTML ed XML ed immagini. Può mostrare anche altri tipi di dati tramite plugin ed estensioni; per esempio, mostrare documenti PDF tramite un plugin PDF viewer. Tuttavia, in questo capitolo ci concentreremo sul caso d’uso principale : mostrare HTML ed immagini formattate usando il CSS. ## Motori di rendering Diversi browser usano diversi motori di rendering : Internet Explorer usa Trident, Firefox usa Gecko, Safari usa WebKit. Chrome ed Opera (rispettivamente dalla versione 28 e 15) usano Blink, un fork di WebKit. WebKit è un motore di rendering open source che è nato come motore per la piattaforma Linux ed è stato modificato da Apple per supportare il Mac e Windows. Consulta [webkit.org](http://www.webkit.org/) per maggiori dettagli. ## Il flusso principale Il *motore di rendering* inizierà ad ottenere i contenuti del documento richiesto dal layer *Networking*. Il trasferimento avviene solitamente in pacchetti di 8kB. Successivamente, il flusso base del motore di rendering procede in questo modo : [![rendering-engine-basic-flow](https://simonerescio.it/wp-content/uploads/2014/05/rendering-engine-basic-flow.png)](https://simonerescio.it/?attachment_id=519) Il motore di rendering inizierà **l’analisi (*parsing*)** del documento HTML per convertirne gli elementi in [nodi del DOM](#dom) da inserire in un **[albero](http://it.wikipedia.org/wiki/Albero_(informatica)) di contenuti** (***content tree***). Il motore procede quindi all’analisi dei dati sugli stili, sia nei CSS esterni che degli stili inline del documento. Le informazioni sugli stili insieme alle istruzioni visuali dell’HTML vengono usate per costruire un’altro albero : [**l’albero di render** (***render tree***)](#costruzione-dell8217albero-di-render). L’albero di render contiene rettangoli con attributi visuali quali colori e dimensioni. I rettangoli sono disposti nel giusto ordine per essere mostrati sullo schermo. Dopo la costruzione dell’*albero di render* segue il processo di [**disposizione** (***layout***)](#disposizione). Consiste nell’attribuire ad ogni nodo le coordinate precise del punto dello schermo in cui deve apparire. Il passaggio successivo è il processo di [**pittura** (***painting***)](#pittura) : l’albero di render viene percorso ed ogni nodo viene pitturato sullo schermo usando il livello di *UI backend*. È importante comprendere che questo processo è ***graduale***. Per una migliore esperienza utente, il motore di rendering cercherà di mostrare i contenuti sullo schermo il prima possibile. Non aspetterà che tutto l’HTML sia stato analizzato prima di iniziare a costruire e disporre l’albero di render. Parti del contenuto verranno analizzate e visualizzate, mentre il processo avanza con il resto dei contenuti che continua ad arrivare dalla rete. ## Esempi del flusso principale [![browser-rendering-engine-webkitflow](https://simonerescio.it/wp-content/uploads/2014/05/browser-rendering-engine-webkitflow.png)](https://simonerescio.it/?attachment_id=521)*Flusso principale del motore di rendering WebKit*   [![browser-rendering-engine-gecko-flow](https://simonerescio.it/wp-content/uploads/2014/05/browser-rendering-engine-gecko-flow.jpg)](https://simonerescio.it/?attachment_id=522)*Flusso principale del motore di rendering Gecko* Le figure illustrano come nonostante WebKit e Gecko utilizzino terminologie leggermente diverse, il processo è basilarmente lo stesso. Gecko chiama l’albero degli elementi formattati visualmente “***Frame tree***“. Ogni elemento è un *frame*. WebKit usa il termine “*Render tree”* ed è costituito da “*Render objects*“. WebKit usa il termine “*Layout*” per la disposizione degli elementi, mentre Gecko lo chiama “*Reflow*“. “*Attachment*” è il termine che usa WebKit per indicare il collegamento dei nodi del DOM alle informazioni visuali per creare l’albero di rendering. Un’altra piccola differenza non semantica è che Gecko ha un livello ulteriore che si frappone tra l’HTML e l’albero del DOM, si chiama “*content sink*” ed è una fabbrica di creazione di elementi del DOM. Ora discuteremo di ciascuna parte del flusso. # Analisi e costruzione dell’albero del DOM Dato che l’analisi è un processo molto importante all’interno di un motore di rendering, approfondiremo l’argomento. Iniziamo con una piccola introduzione sul *parsing*. ## Nozioni sui parser Eseguire il *parsing*, ovvero *l’analisi*, di un documento significa tradurlo in una struttura che il codice possa utilizzare. Il risultato dell’analisi è generalmente un’alberatura di nodi che rappresentano la struttura del documento. Questo è chiamato *albero di analisi (parse tree)* oppure *albero sintattico (syntax tree)*. Per esempio, un’analisi dell’espressione `2 + 3 -1 ` potrebbe restituire il seguente albero : [![Albero di nodi di un espressione aritmetica](https://simonerescio.it/wp-content/uploads/2014/05/mathematical-expression-tree-node.png)](https://simonerescio.it/?attachment_id=525)*Albero di nodi di un’espressione aritmetica* ### Grammatica L’analisi è basata sulle regole sintattiche a cui obbedisce il documento : la lingua o il formato in cui è stato scritto. Ogni formato che deve essere analizzato deve avere una *grammatica deterministica* che consista di *vocabolario* e *regole sintattiche*. Queste caratteristiche identificano una [grammatica libera dal contesto](http://it.wikipedia.org/wiki/Grammatica_libera_dal_contesto). Le lingue umane non rientrano in questa categoria e per questo motivo non possono essere analizzate con le tecniche di analisi convenzionali. ### Combinazione Parser-Lexer L’analisi può essere separata in due sottoprocessi : analisi lessicale ed analisi sintattica. L’analisi ***lessicale*** è il processo di scomposizione dei dati iniziali in ***frammenti*** (***token***). I *frammenti* sono i vocaboli del linguaggio : la collezione di blocchi costruttori validi. Nei linguaggi umani consiste nell’insieme di parole che appaiono nel dizionario di una data lingua. L’analisi ***sintattica*** è l’applicazione delle regole sintattiche del linguaggio. I *parser* solitamente dividono il lavoro tra due componenti : il ***lessicatore*** (***lexer***), a volte chiamato ***frammentatore*** (***tokenizer***), che si occupa di spezzettare i dati di ingresso in *frammenti* validi, ed il ***parser*** che si occupa di costruire *l’alberatura di analisi* confrontando la struttura del documento con le regole sintattiche del suo linguaggio. Il *lessicatore* sa come rimuovere caratteri irrilevanti quali spazi vuoti e ritorni a capo. [![source-to-prase-tree](https://simonerescio.it/wp-content/uploads/2014/05/source-to-prase-tree.png)](https://simonerescio.it/?attachment_id=528)*Dal file iniziale del documento all’albero di analisi* Il processo di analisi è *iterativo*. Il *parser* solitamente chiederà al *lessicatore* un nuovo *frammento* e cercherà di farlo corrispondere con una delle regole sintattiche del linguaggio. Se una regola corrisponde, un nodo corrispondente al *frammento* verrà aggiunto all’albero di analisi ed il *parser* chiederà di nuovo un altro *frammento*. Se nessuna regola corrisponde, il *parser* memorizzerà il *frammento* internamente, e continuerà a chiedere nuovi *frammenti* finché non verrà trovata una regola che corrisponda a tutti i *frammenti* memorizzati internamente. Se nessuna regola viene trovata il *parser* lancerà un eccezione. Ciò significa che il documento non era valido e conteneva degli errori sintattici. ### Traduzione In molti casi l’albero di analisi non è il prodotto finale. L’analisi è usata nella *traduzione*, ovvero nella trasformazione del documento iniziale in un altro formato. Un esempio è la *compilazione*. Il compilatore che trasforma il codice sorgente in codice macchina prima analizza il codice in entrata creando un alberatura di analisi e successivamente lo traduce in un documento di codice macchina. [![compilation-flow](https://simonerescio.it/wp-content/uploads/2014/05/compilation-flow.png)](https://simonerescio.it/?attachment_id=529)*Flusso di compilazione* ### Esempio di parsing Prima abbiamo costruito l’albero d’analisi di un’espressione aritmetica. Proviamo a definire un semplice linguaggio matematico per capire il processo di analisi. *Vocabolario* : il nostro linguaggio può includere *interi*, *segno più* e *segno meno*. *Sintassi* : - I blocchi costruttori della sintassi del nostro linguaggio sono *espressioni*, *termini* ed *operazioni*. - Il nostro linguaggio può includere un numero infinito di espressioni. - Un’*espressione* è definita come un “termine” seguita da un “operazione” seguita da un altro termine. - Un *operazione* è un *frammento più* o un *frammento meno*. - Un *termine* è un *frammento intero* oppure un’*espressione* Analizziamo come sorgente `2 + 3 - 1`. La prima parte di stringa che corrisponde ad una regola è il `2` : stando alla regola n°5 è un *termine*. La seconda corrispondenza è `2 + 3`, ovvero è un’espressione perché corrisponde alla regola n°3, un termine seguito da un operazione seguito da un altro termine. La prossima corrispondenza viene trovata solo alla fine dell’elaborazione. `2 + 3 - 1` è un’espressione perché sappiamo che `2 + 3` è un termine, quindi abbiamo un termine seguito da un altro termine. `2 + +` non corrisponderà a nessuna regola perché non è un sorgente valido. ### Definizioni formali di vocabolario e sintassi Il vocabolario è generalmente definito tramite [espressioni regolari](http://www.regular-expressions.info/). Per esempio il nostro linguaggio sarà definito come segue : ``` INTEGER: 0|[1-9][0-9]* PLUS: + MINUS: - ``` Come si può constatare, gli interi sono definiti per mezzo di espressioni regolari. La sintassi è solitamente definita in un formato chiamato [BNF](http://it.wikipedia.org/wiki/Backus-Naur_Form). Il nostro linguaggio sarà definito come segue : ``` expression := term operation term operation := PLUS | MINUS term := INTEGER | expression ``` Avevamo accennato al fatto che un linguaggio può essere analizzato dai *parser* normali se la sua grammatica è libera dal contesto. Una definizione intuitiva di grammatica libera dal contesto è una grammatica che possa essere interamente espressa in linguaggio BNF. Per una definizione formale consulta [l’articolo di Wikipedia sulla grammatica libera dal contesto](http://it.wikipedia.org/wiki/Grammatica_libera_dal_contesto). ### Tipologie di parser Ci sono due tipi di *parser* : *parser* *top-down* e *parser* *bottom-up*. Una spiegazione intuitiva è che *top-down* consiste nell’esaminare la struttura di alto livello della sintassi per provare a cercare una regola che corrisponda. *Bottom-up* consiste nel cominciare dal sorgente in entrata e trasformarlo gradualmente in regole sintattiche, iniziando dalle regole di basso livello finché non vengono incontrate quelle di alto livello. Vediamo come i due diversi tipi di *parser* analizzano il nostro esempio. Il *parser* *top-down* inizierà dalle regole di alto livello : identificherà `2 + 3` come espressione, poi identificherà `2 + 3 - 1` come espressione (il processo di identificazione delle espressioni si evolve, trovando le altre regole, ma il punto di inizio sono le regole di alto livello). Il *parser* *bottom-up* analizzerà il codice in ingresso finché non viene a corrispondere con una regola. A quel punto rimpiazzerà l’elemento di input con la regola. Il processo andrà avanti fino alla fine del codice. Le espressioni individuate parzialmente verrano inserite nella coda di operazioni del *parser*. | Stack | Input | | --- | --- | | | 2 + 3 – 1 | | term | + 3 – 1 | | term operation | 3 – 1 | | expression | – 1 | | expression operation | 1 | | expression | – | La tipologia *bottom-up* è anche detta *shift-reducer*, perché il sorgente è spostato verso destra (immagina un puntatore che indica l’inizio della riga ed inizia a scorrere verso destra i singoli caratteri) e viene gradualmente ridotto a regole sintattiche. ### Generazione automatica dei parser Ci sono degli strumenti che possono generare dei *parser*. Gli si da in pasto la grammatica del proprio linguaggio, il suo vocabolario e la sua sintassi, e genera un *parser* funzionante. Creare un *parser* richiede una conoscenza approfondita del meccanismo di analisi e non è facile crearne uno ottimizzato manualmente, quindi i generatori di *parser* possono essere molto utili. WebKit utilizza due generatori di *parser* molto conosciuti : [Flex](http://it.wikipedia.org/wiki/Flex_(software)) per generare il *lessicatore* e [Bison](http://www.gnu.org/software/bison/) per il *parser* principale (potresti averli incontrati sotto i nomi di Lex e Yacc). ## Parser HTML Il compito del *parser* HTML è di trasformare il codice sorgente del documento in un alberatura d’analisi. ### La definizione della grammatica HTML Il vocabolario e la sintassi dell’HTML sono definite nelle [specifiche](#le-funzionalit-principali-dei-browser) create dall’organizzazione del W3C. ### Non è una grammatica libera dal contesto Come abbiamo visto nell’introduzione ai *parser*, la sintassi della grammatica può essere definita formalmente usando formati come il BNF. Sfortunatamente nessuno degli argomenti convenzionali relativi ai *parser* può essere applicato all’HTML (saranno invece discussi per il CSS e il JavaScript che li adottano). L’HTML non può essere facilmente definito in una grammatica libera dal contesto necessaria ad un parser. C’è una struttura formale per definire gli HTML-DTD (Document Type Definition), ma non è una grammatica libera dal contesto. All’inzio sembra strano : l’HTML è molto simile all’XML. Ci sono numerosi *parser* XML in circolazione. C’è anche una variante XML dell’HTML, ovvero l’XHTML, quindi dove stà la grande differenza? **La differenza è che l’approccio dell’HTML è molto “*clemente*“** : ti permette di omettere alcuni tag (che vengono però aggiunti implicitamente), o alcune volte permette di omettere l’inzio o la fine di alcuni tag e via discorrendo. Generalmente è una sintassi “leggera”, contrariamente alla sintassi rigida ed obbligatoria dell’XML. Questo apparentemente piccolo dettaglio costituisce una differenza abissale. Da una parte questa è la ragione principale che ha reso l’HTML così popolare : perdona i tuoi errori e rende la vita più facile agli sviluppatori web, dall’altra rende molto difficile il compito di scrivere una grammatica formale. Quindi recapitolando, l’HTML non può essere analizzato facilmente dai *parser* convenzionali, poichè la sua grammatica non è libera dal contesto. L’HTML non può essere analizzato dai *parser* XML. ### HTML DTD La definizione del linguaggio HTML avviene in formato DTD. Questo formato è usato per definire i linguaggi della famiglia [SGML](http://it.wikipedia.org/wiki/Standard_Generalized_Markup_Language). Il formato contiene definizioni degli elementi consentiti, i loro attributi e gerarchie. Come abbiamo visto, l’HTML DTD non forma una grammatica libera dal contesto. Ci sono alcune variazioni del DTD. La modalità *strict* è conforme solo alle specifiche ma altre modalità contengono il supporto per il markup usato dai browser nel passato. L’obbiettivo è la retro-compatibilità con i vecchi contenuti. La versione *strict* corrente è la seguente : [http://www.w3.org/TR/html4/strict.dtd](http://www.w3.org/TR/html4/strict.dtd) ### DOM Il risultato finale dell’analisi del *parser* (il “*parse tree*“) è un albero di elementi del DOM e nodi di attributi. DOM è un acronimo che sta per **Document Object Model**. È la rappresentazione come oggetto del documento HTML e l’interfaccia di accesso agli elementi HTML al mondo esterno come il *parser* JavaScript. La radice dell’albero è l’oggetto “[Document](http://www.w3.org/TR/1998/REC-DOM-Level-1-19981001/level-one-core.html#i-Document)“. Il DOM ha una relazione che corrisponde quasi 1:1 con il codice. Ad esempio il seguente HTML : ```

Hello World

``` Sarebbe tradotto nel seguente albero DOM : [![hello-world-html-dom-tree](https://simonerescio.it/wp-content/uploads/2014/05/hello-world-html-dom-tree.png)](https://simonerescio.it/?attachment_id=541)*Alberatura DOM dell’esempio HTML hello world* Come per l’HTML, il DOM è specificato dall’organizzazione del W3C. Consulta la pagina [www.w3.org/DOM/DOMTR](http://www.w3.org/DOM/DOMTR). È una specifica generica per la manipolazione dei documenti. Un modulo specifico descrive anche gli elementi HTML. Le definizione per l’HTML si trovano alla seguente pagina : [http://www.w3.org/TR/2003/REC-DOM-Level-2-HTML-20030109/idl-definitions.html](http://www.w3.org/TR/2003/REC-DOM-Level-2-HTML-20030109/idl-definitions.html). Quando affermo che l’albero è composto da nodi del DOM, intendo che l’albero è costituito da elementi che implementano una delle interfacce del DOM. I browser usano implementazioni concrete che hanno ulteriori attributi utilizzati dal browser internamente. ### L’algoritmo di parsing Come abbiamo visto nelle precedenti sezioni, l’HTML non può essere analizzato usando il regolare processo *top-down* o *bottom-up* dei *parser*. Le ragioni sono le seguenti : - La natura “*clemente*” del linguaggio. - Il fatto che i browser hanno tradizionalmente un supporto per la tolleranza di errori riguardanti casi noti di HTML invalido. - Il processo di analisi è [rientrante](http://it.wikipedia.org/wiki/Codice_rientrante). Per altri linguaggi, la sorgente non cambia durante la fase di analisi, ma per l’HTML, il codice dinamico (come elementi script inline contenenti chiamate `document.write()` ) può aggiungere nuovi *frammenti*, quindi *il processo di analisi modifica il sorgente stesso*. Nell’impossibilità di utilizzare tecniche di *parsing* tradizionali, ciascun browser usa un proprio *parser* per analizzare l’HTML. [L’algoritmo di analisi è descritto dettagliatamente nelle specifiche HTML5](http://www.whatwg.org/specs/web-apps/current-work/multipage/parsing.html). L’algoritmo consiste di due fasi : *frammentazione* e *costruzione dell’albero*. La ***frammentazione*** è l’analisi lessicale, trasformando il codice sorgente in entrata in frammenti. Tra i frammenti HTML ci sono i tag iniziali, i tag finali, i nomi degli attributi ed i valori degli attributi. Il *frammentatore* riconosce i *frammenti*, li passa al costruttore dell’albero, e passa ai caratteri successivi per riconoscere i prossimi *frammenti*, e cosi via fino alla fine del codice. [![html5-parsing-flow-spec](https://simonerescio.it/wp-content/uploads/2014/05/html5-parsing-flow-spec1.png)](https://simonerescio.it/?attachment_id=668)*Flusso di analisi del codice HTML (tratto dalle specifiche HTML5)* ### L’algoritmo di frammentazione Il risultato dell’algoritmo è un *frammento* HTML. L’algoritmo è espresso come una [macchina a stati finiti](http://it.wikipedia.org/wiki/Automa_a_stati_finiti). Ogni stato riceve uno o più caratteri del flusso di codice ed aggiorna lo stato successivo in base a quei caratteri. La decisione è influenzata dallo stato corrente di frammentazione e dallo stato della costruzione dell’albero. Ciò significa che uno stesso carattere analizzato restituirà un risultato diverso, corretto per lo stato successivo, in dipendenza dallo stato corrente. L’algoritmo è troppo complesso per essere spiegato completamente, quindi vediamo un esempio semplice per comprenderne il principio : Esempio base, frammentazione del seguente HTML : ``` Hello world ``` Lo stato iniziale è “Data state”. Quando il carattere “`<`” viene incontrato, lo stato cambia in “**Tag open state**“. La ricezione di una serie di caratteri compresi tra `a-z` causa la creazione di uno “Start tag token”, lo stato viene cambiato in “**Tag name state**“. Si rimane in questo stato finché non viene incontrato il carattere “`>`“. Ogni carattere viene appeso al nome del nuovo *frammento*. Nel nostro caso il *frammento* creato è un *frammento* `html`. Quando il carattere “`>`” viene raggiunto, il *frammento* attuale viene emesso e lo stato ritorna in “**Data state**“. Il tag `` sarà trattato con gli stessi passi. A questo punto sono stati emessi i tag `html` e `body`. Ora siamo di nuovo nello stato “**Data state**“. Arrivati al primo carattere `H` della parola `Hello world` avverrà l’emissione di un *frammento di carattere*, l’operazione si ripete finchè non viene raggiunto il carattere “`<`” del tag ``. Verrà emesso un *frammento di carattere* per ogni lettera che compone la stringa `Hello world`. Adesso siamo tornati allo stato “**Tag open state**“. La ricezione del prossimo carattere “`/`” causerà la creazione di un *frammento di fine tag* per poi spostarsi allo stato “**Tag name state**“. Di nuovo si resta in questo stato fino al raggiungimento del carattere “`>`“. Poi il nuovo *frammento di tag* verrà emesso per tornare allo stato “Data state”. I caratteri `` saranno trattati allo stesso modo. [![tokenizing-example](https://simonerescio.it/wp-content/uploads/2014/05/tokenizing-example.png)](https://simonerescio.it/2014/05/come-funzionano-i-browser-dietro-le-quinte-dei-web-browser-moderni/tokenizing-example/)*Esempio di frammentazione del codice (tokenizing)* ### Algoritmo di costruzione dell’alberatura Quando l’analisi viene generata anche il DOM viene creato. Durante la fase di costruzione dell’alberatura il DOM, con l’oggetto Document come radice, verrà modificato e gli elementi verrano progressivamente aggiunti. Ogni nodo emesso dal frammentatore sarà processato dal costruttore dell’alberatura. Per ogni *frammento* le specifiche definiscono quale elemento del DOM è correlato e viene inserito per quel *frammento*. L’elemento è quindi aggiunto all’alberatura del DOM e anche alla *lista degli elementi aperti*. Questa lista viene usata per correggere eventuali errori di annidamento causati da tag non chiusi correttamente. L’algoritmo è descritto anche come una macchina a stati, gli stati sono chiamati “modalità di inserimento”. Vediamo il processo di costruzione per il seguente codice di esempio : ``` Hello world ``` Gli elementi di base per la costruzione dell’albero provengono dalla sequenza di *frammenti* prodotti dalla fase di frammentazione. La prima modalità è “**initial mode**“. La ricezione del *frammento* “`html`” causerà lo spostamento verso la modalità “**before html**” ed il riprocessamento del *frammento* in tale modalità. Questo causerà la creazione dell’elemento `HTMLhtmlElement`, che sarà appessò alla radice dell’oggetto Document. Lo stato cambia quindi in “**before head**“. Poi viene ricevuto il *frammento* “`body`“. Un elemento `HTMLHeadElement` verrà creato inplicitamente anche se non è stato emanato il *frammento* e sarà aggiunto all’albero. Ora lo stato si sposta verso la modalità “**in head**” e successivamente “**after head**“. Il *frammento* `body` viene quindi riprocessato, viene creato l’elemento `HTMLBodyElement` e la modalità passa a “**in body**“. I *frammenti di carattere* della stringa `Hello world` vengono ricevuti. Il primo causerà la creazione e l’inserimento di un nodo `Text` e gli altri caratteri verrano appesi a quel nodo. La ricezione del *frammento di chiusura del body* causerà il cambiamento della modalità in “**after body**“. Viene quindi ricevuto il tag di chiusura `html` che cambia la modalità in “**after after body**“. La ricezione del *frammento di fine file* terminerà l’operazione di analisi del *parser*. [![DOM-tree-construction](https://simonerescio.it/wp-content/uploads/2014/05/DOM-tree-construction.gif)](https://simonerescio.it/2014/05/come-funzionano-i-browser-dietro-le-quinte-dei-web-browser-moderni/dom-tree-construction/)*Costruzione del DOM dell’esempio HTML* ### Azioni al termine dell’analisi A questo punto il browser marca il documento come *interattivo* ed inzia ad analizzare gli script che sono in modalità “differita” : quelli che devono essere eseguiti dopo l’analisi del documento. Lo stato del documento passerà quindi a *completo* ed un evento *load* viene emesso. Puoi consultare [l’algoritmo completo per la frammentazione e costruzione dell’alberatura nelle specifiche HTML5](http://www.w3.org/TR/html5/syntax.html#html-parser). ### La tolleranza agli errori del browser Non si ottiene mai l’errore “Invalid Syntax” con una pagina HTML. I browser aggiustano ogni contenuto invalido in tempo reale. Prendiamo questo HTML per esempio : ```

Really lousy HTML

``` Ci sono almeno un milione di regole violate tutte insieme (“mytag” non è un tag standard, errato annidamento di “p” e “div” e molto altro) ma il browser mostra ugualmente il documento in maniera corretta e non si lamenta. Una gran parte del codice del *parser* consiste nell’aggiustamento degli errori dell’autore dell’HTML. La gestione degli errori è molto consistente nei browser, ma sorprendentemente non è mai stata parte delle specifiche HTML. Come per i bookmarks ed i tasti di navigazione indietro/avanti è qualcosa che si è andata evolvendo nei browser nel corso degli anni. Ci sono costrutti HTML invalidi ben conosciuti ripetuti su diversi siti, ed i browser cercano di aggiustarli in modo coerente tra di loro. Le specifiche HTML5 definiscono alcuni di questi requisiti. (WebKit li riassume bene nel commento che si trova all’inizio della funzione della classe del *parser* HTML.) > Il parser analizza elementi frammentati nel documento, costruendo l’alberatura del documento. Se il documento è ben formato, l’operazione è diretta. Sfortunatamente, dobbiamo gestire diversi documenti HTML che non sono ben formati, quindi il parser deve essere tollerante verso gli errori. Dobbiamo preoccuparci almeno delle seguenti condizioni di errore: - > L’elemento che viene aggiunto è esplicitamente proibito all’interno di un tag che lo contiene. In questo caso dovremmo chiudere tutti i tag fino a quello che proibisce l’elemento, ed aggiungerlo successivamente. - > Non è consentito inserire l’elemento direttamente. È possibile che la persona che ha scritto il documento abbia dimenticato alcuni tag nel mezzo (o che il tag nel mezzo è opzionale). Questo può succedere con i seguenti tag : HTML HEAD BODY TBODY TR TD LI (ne ho dimenticato qualcuno?). - > Vogliamo aggiungere un elemento block dentro un elemento inline. Chiudere tutti gli elementi inline fino al prossimo elemento block. - > Se questo non aiuta, chiudere gli elementi fino a che non è consentito inserire l’elemento – oppure ignora il tag. Vediamo alcuni esempi di tolleranza agli errori di WebKit : **
invece di
** Alcuni siti usano
invece di
. Per rimanere compatibile con IE e Firefox, WebKit tratta l’elemento come un `
`. Il codice : ``` if (t->isCloseTag(brTag) && m_document->inCompatMode()) { reportError(MalformedBRError); t->beginTag = true; } ``` Notare che la gestione dell’errore è interna, non verrà presentata all’utente. **Una tabella vagante** Una tabella vagante è una tabella dentro un’altra tabella, ma non all’interno di una table-cell. Ad esempio : ```
inner table
outer table ``` WebKit cambierà la gerarchia in due tabelle sorelle : ```
outer table
inner table
``` Il codice : ``` if (m_inStrayTableContent && localName == tableTag) popBlock(tableTag); ``` WebKit usa un odine per i contenuti dell’elemento corrente: porterà all’esterno la tabella interna, in modo che le due diventino sorelle. **Elementi form annidati** Nel caso in cui lo sviluppatore inserisca un form dentro un altro form, il secondo form verrà ignorato. Il codice: ``` if (!m_currentFormElement) { m_currentFormElement = new HTMLFormElement(formTag, m_document); } ``` **Gerarchia di tag troppo profonda** Il commento parla da solo : > www.liceo.edu.mx è un esempio di sito che riesce ad ottenere un livello di annidamento di circa 1500 tags, tutti da una serie di . Consentiremo solo un massimo di 20 annidamenti dello stesso tipo prima di ignorarli tutti completamente. ``` 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; } ``` **Tag di chiusura html o body malposti** Nuovamente- il commento parla da solo. > Supporto per HTML veramente scassato. Non chiudiamo mai il tag body, dato che alcune stupide pagine web lo chiudono prima della reale fine del documento. Affidiamoci alla chiamata end() per chiudere tutto. ``` if (t->tagName == htmlTag || t->tagName == bodyTag ) return; ``` Quindi cari autori fate attenzione, a meno che non vogliate apparire come snippet di esempio della tolleranza agli errori di WebKit, scrivete del codice HTML ben formato. ## Parser CSS Ricordi i concetti relativi ai *parser* dell’introduzione? Ebbene, diversamente dall’HTML, il CSS è una grammatica libera dal contesto e può essere analizzata usando le tipologie di *parser* descritti nell’introduzione. Infatti [le specifiche CSS definiscono anche la grammattica lessicale e sintattica del linguaggio](http://www.w3.org/TR/CSS2/grammar.html). Vediamo alcuni esempi: La grammatica lessicale (vocabolario) è definita tramite espressioni regolari per ogni *frammento* : ``` comment /*[^*]**+([^/*][^*]**+)*/ num [0-9]+|[0-9]*"."[0-9]+ nonascii [200-377] nmstart [_a-z]|{nonascii}|{escape} nmchar [_a-z0-9-]|{nonascii}|{escape} name {nmchar}+ ident {nmstart}{nmchar}* ``` “ident” è un’abbreviazione di *identifier*, come il nome di una classe, “name” è l’identificatore di un elemento (che viene referenziato con il simbolo “#”) La sintassi della grammatica è descritta in linguaggio BNF. ``` ruleset : selector [ ',' S* selector ]* '{' S* declaration [ ';' S* declaration ]* '}' S* ; selector : simple_selector [ combinator selector | S+ [ combinator? selector ]? ]? ; simple_selector : element_name [ HASH | class | attrib | pseudo ]* | [ HASH | class | attrib | pseudo ]+ ; class : '.' IDENT ; element_name : IDENT | '*' ; attrib : '[' S* IDENT S* [ [ '=' | INCLUDES | DASHMATCH ] S* [ IDENT | STRING ] S* ] ']' ; pseudo : ':' [ IDENT | FUNCTION S* [IDENT S*] ')' ] ; ``` Esempio, un insieme di regole CSS ha questa struttura : ``` div.error, a.error { color:red; font-weight:bold; } ``` `div.error` e `a.error` sono selettori. La parte all’interno delle parentesi graffe contiene delle regole che sono applicate da questo insieme. Questa struttura è definita formalmente in questo modo : ``` ruleset : selector [ ',' S* selector ]* '{' S* declaration [ ';' S* declaration ]* '}' S* ; ``` Questo significa che un insieme di regole è costituito da uno o più selettori separati da una virgola e spazi (`S` sta per spazio vuoto). Un insieme di regole contiene delle parentesi graffe e al suo interno una o più dichiarazioni separate da punto e virgola ### Parser CSS di WebKit WebKit utilizza i generatori di *parser* [Flex e Bison](#generazione-automatica-dei-parser) per generare automaticamente i propri *parser* dai file della grammatica CSS. Come ricorderai dall’introduzione, Bison crea un *parser* *bottom-up shift reduce*. Firefox usa un *parser* *top-down* scritto a mano. In entrambi i casi ogni file CSS viene analizzato e tradotto in un oggetto `StyleSheet`. Ogni oggetto contiene regole CSS. Gli oggetti CSS `rule` contengono oggetti `selector` e `declaration` ed altri oggetti corrispondenti alla grammatica CSS. [![css-parsing](https://simonerescio.it/wp-content/uploads/2014/05/css-parsing.png)](https://simonerescio.it/2014/05/come-funzionano-i-browser-dietro-le-quinte-dei-web-browser-moderni/css-parsing/)*Analisi del CSS (parsing)* ## L’ordine di processamento degli script e dei fogli di stile ### Scripts Il modello del web è *sincrono*. Gli sviluppatori si aspettano che gli script vegano analizzati ed eseguiti immediatamente quando il *parser* raggiunge il tag `