Episodio 2 – la preparazione del browser

Nel precedente articolo abbiamo visto alcune tecniche base di programmazione e sopprattutto la sequenza di operazioni che il browser effettua quando carica un documento, ora analizziamo in dettaglio la prima parte di queste operazioni che corrisponde alle operazioni base che un browser deve effettuare per poter mostrare correttamente i contenuti.

Nota: in questa parte e in seguito parlerò di oggetto di reading, parsing, ecc… ma in realtà questi ultimi sono mini sistemi molto complessi e composti da decine di classi e oggetti che interagiscono tra loro.

Il caricamento dei dati (reading)

I documenti HTML come ben sappiamo sono normalissime sequenze di caratteri appartenenti ad un preciso encoding (l’encoding determina la codifica dei caratteri/glifi speciali appartenenti ad un area geografica: per esempio la “c” del copyright in ISO-8859-1 si scrive ©) e quindi sono editabili con qualunque editor di testo. Questi caratteri sono suddivisi in due tipologie, quelli che fungono da contenuti (i testi) e quelli che fungono da marcature determinando la struttura del documento.

Il browser quando carica il documento non sa riconoscere automaticamente queste marcature e quindi considera il testo una lunga stringa, quindi nella fase detta di reading (lettura) carica semplicemente questo testo tramite un oggetto che permette il caricamento di file fisici che salva i contenuti in un attributo di tipo stringa. Man mano che il contenuto viene caricato viene in tempo reale passato ad un altro oggetto in memoria che procede alla fase di parsing della stringa.

Controllo, correzione e trasformazione dei dati (validation, interpretation, parsing)

Il nuovo oggetto di parsing man mano che riceve la stringa dei contenuti effettua su di essa 3 operazioni principali che variano in sequenza da browser a browser. Di solito la stringa viene prima trasformata in una collezzione di caratteri (array) e poi tramite alcuni metodi vengono ricercate al suo interno le singole tag, al momento che se ne identifica una la collezzione viene splittata e annidiata in modo da avere una serie di collezzioni annidiate (detti array multidimensionali).

Una volta ottenuta la collezzione di stringhe il browser procede ad un secondo parsing più raffinato che va ad identificare il linguaggio dichiarato nella dtd in modo da conoscere il linguaggio che dovrà trattare (nota: se non è dichiarata la dtd cerca di intuirlo tramite dei pattern), in base al linguaggio si carica una libreria di riferimento e mappa le lingole marcature trasformando le collezzioni annidiate (e i loro attributi) in quegli oggetti che rappresentano gli oggetti html di cui abbiamo parlato nell’episodio 1 formando così l’albero DOM in memoria. Durante questa fase il browser effettua anche una scansione del codice cercando al suo interno eventuali errori, e se ne trova effettua un operazione di interpretazione cercando di capire cosa voleva fare il programmatore (interpretation).

Nel nuovo albero DOM oltre ad essere stati inseriti tutti i contenuti sono anche stati rimappati gli attributi definiti a livello di html, ma quelli non settati? In realtà tutti gli attributi vengono settati e, secondo il modello dato alla classe originale che rappresenta i singoli nodi, questi ultimi possiedono dei valori di dafault sia per le proprietà, sia per gli eventi sia per gli stili (che vengono inseriti sotto il nodo elemento.style.nomestile).

A questo punto vi è l’ultima fase chiamata validation che testa il neoformato albero DOM, in pratica il browser effettua un ultima verifica sull’integrità dell’albero controllando se l’insieme dei nodi risulta ben formato (well formed), cioè che le tag siano annidiate in maniera corretta e sequenziale.

Visualizzazione dei dati (renderer)

Quando l’albero DOM è pronto entra in gioco un nuovo insieme di oggetti che si occupa di rendere visivamente lo stesso. Questo sistema chiamato renderer lavora in due possibili modi che variano da browser a browser, il cosidetto quirks mode (dovrebbe rappresentare strutture non propriamente valide) e lo standard mode (dovrebbe rappresentare ottimamente le strutture valide). Lui scansiona nodo per nodo gli oggetti DOM che rappresentano le singole marcatura e li rappresenta sullo schermo come normale testo, in seguito ne analizza gli attributi di stile e li applica formandone tutte le regole di rappresentazione e di occupazione sullo schermo. In questo modo oggetto per oggetto HTML si va a formare tutta la rappresentazione grafica del sito impostata a livello di HTML.

Il renderer ha anche la peculiarità che funziona in maniera autonoma e ricorsiva continuando a ripassarsi tutta la struttura in cerca di modifiche da rappresentare.

E finalmente la struttura è pronta

A questo punto la nostra struttura di programmazione e di interfaccia DOM è correttamente formata e rappresentata con tutti gli attributi settati o di default. Da qui in avanti il browser tratterà solo una serie di trasformazioni che potrebbero essere definibili funzionali di cui parleremo nell’ultimo episodio.

Potrebbero interessarti anche i seguenti articoli

Condividi:

Informazioni sull'autore

Luca Mascaro
Luca Mascaro
Luca Mascaro è uno User Experience Architect che si occupa da anni della progettazione di interfacce utente e dell'esperienza utente su piattaforme software web e multimediali. Dirige la SketchIn, un azienda che si occupa di progettazione e consulenza strategica sulla user experience ed è CTO di una software house, la Phiware Engineering. Attualmente fa parte di diversi associazioni internazionali tra cui l'IWA/HWG, l'ACM, l'UPA e l'IOSHI di cui è presidente. Partecipa a gruppi di lavoro del W3C (HTML, WCAG, Web Application e Device Indipendence) e dell'ISO (Software Ergonomics) in ambito di interazione e interfacce.

Commenti

Nessun commento

    Rispondi

    Link e informazioni