Nel precedente articolo eravamo rimasti al punto di avere il nostro documento html caricato e la sua struttura DOM istanziata ed in attesa delle varie fasi di trasformazione che tratteremo in quest’ultimo episodio.

Le trasformazioni del DOM

Come abbiamo visto il documento HTML viene caricato ed interpretato in un oggetto che poi vi esegue delle operazioni, allo stesso modo il browser è programmato per caricare altri file in maniera concorrenziale (contemporanea) quando incontra delle specifiche tag di istanziamento che li richiamano. Per capirci meglio stiamo parlando di tutti quei documenti come i file javascript, css, xsl, immagini, ecc… che vengono caricati contemporaneamente con l’HTML.

Nota: il caricamento di questi file non è inteso solo come esterno, ma può essere anche interno. Per caricamento si intende la trasposizione di quei dati all’interno di un altra classe che li “carica”.

Tra questi file alcuni sono detti di trasformazione o di formattazione, ed in pratica sono file scritti con una sintassi conosciuta dal browser che gli permette di modificare la struttura DOM del suo HTML in memoria.

In pratica quando una tag di richiamo CSS viene trasformata nel corrispettivo oggetto DOM viene richiamato un secondo oggetto specifico che carica il documento CSS ed attiva una speciale procedura di trasformazione.

Questa procedura è composta da una serie di funzioni divise tra diversi oggetti che secondo una metodica SAX si memorizzano tutti i pattern presenti nel CSS (i pattern nel css sono i selettori)ed in seguito si passano in maniera ricorsiva l’intera struttura DOM presente alla ricerca di sequenze DOM che corrispondano al pattern.

Se un pattern trova coincidenza nella struttura gli attributi definiti al suo interno vengono copiati tramite i metodi del DOM all’interno dell’oggetto DOM selezionato.
Supponiamo di avere un documento HTML come il seguente:

<html>
<head>
<style type="text/css">
body span { color: red; }
</style>
</head>
<body>
<span>Ciao</span>
</body>
<html>

Il browser avrà in memoria l’oggetto DOM che rappresenta lo span con l’attributo di stile di default settato a inherit, che per ereditarietà prende #000000, e rappresentato in programmazione come:

HTMLSpanElement.style.color = "inherit";
// e puntabile in js e DOM tramite:
document.getElementsByTagName("span")[0].style.color;

Quando interverrà l’oggetto che si occupa delle trasformazioni css il pattern body > span verrà identificato e con lui l’oggetto DOM in questione. A questo punto trattandosi di una trasformazione di stile tutti gli attributi settati all’interno del pattern (il color: red;) verranno copiati secondo una logica di sovrascrittura sopra l’attributo style dell’oggetto DOM che rappresenta lo span.

Questo tipo di trasformazioni secondo logica SAX avviene per tutti quei tipi di documenti di trasformazione che intervengono ricorsivamente e all’infinito sulla struttura DOM, come i fogli di stile CSS o per i linguaggi della famiglia dei linguaggi di stile estendibili XSL.

Nota: nei browser di ultima generazione anche i fogli di stile CSS o gli XSL sono rappresentati nella struttura come oggetti DOM e quindi sono modificabili nella loro azione perpetua come vuole dimostrare lo script pixeltrasformer.

Il dinamicismo del DOM

Esattamente come per i file di trasformazione del DOM via SAX vi è un altra famiglia di linguaggi che sono richiamati esattamente con la stessa procedura, ma poi vengono eseguiti in maniera completamente diversa.

Questi sono i linguaggi di scripting rappresentati in primis ed in maniera universale da Javascript. La differenza con i linguaggi di trasformazione è che i linguaggi di scripting sono veri è propri linguaggi di programmazione complessi che permettono la creazione di proprie procedure, tipi ed oggetti permettendo al programmatore di realizzare veri e propri software online. Inoltre i linguaggi di scripting sono persistenti e non ricorsivi, quindi le operazioni non vengono eseguite se non richiamate e quindi si basano su un approccio DOM verso la struttura.

Javascript come rappresentante di questa categoria implementa nei vari browser una serie di metodi che permettono di accedere interamente alla struttura DOM della pagina aggiungendo azioni a determinate condizioni fisiche sulla pagina chiamate eventi.

Gli eventi sono delle funzioni di default previste negli oggetti DOM che rappresentano l’HTML che si attivano al verificarsi di determinate azioni fisiche o virtuali come il click del mouse sull’oggetto rappresentato visivamente dal renderer o il caricamento dell’oggetto stesso.

I metodi e gli eventi DOM per interfacciarsi con la struttura DOM dell’HTML sono un infinità e sono definiti in 3 livelli DOM definiti dal W3C ve ne lascio solo uno per esempio che vi ritorna in una finestra tutti gli attributi di stile di un elemento puntato via ID e che potete eseguire direttamente copiandolo nell’url della pagina e premendo return.

javascript: var info; var elem = document.getElementById('idelemento'); for(var i in elem.style){ info+=(i+" : "+ elem.style[i]+"\n") } alert(info);

Attenzione alle priorità!

Abbiamo scoperto che l’albero DOM viene creato, settato e modificato da diversi oggetti con metodologie e tempistiche differenti, ma tra queste modifiche qualè quella che ha la dominanza sulle altre?

In genere (anche se in alcuni browser cambia) la prima dominanza, cioè chi ha diritto a dettare l’ultima modifica, la detiene il linguaggio di scripting adottato ma anche qui tutto è in dubbio, per esempio in Internet Explorer, se si adotta Javascript e VBScript nella stessa pagina, la dominanza c’è l’ha VBScript mentre in altri browser con tecnologie di scripting proprietarie la cosa cambia ancora, quindi non resta che testare.

Comunque la sequenza di dominanza più o meno universale è:

  1. Linguaggi di scripting
  2. Fogli di stile a cascata CSS
  3. Fogli di stile estensibili XSL/XSL-FO
  4. Marcature HTML proprietarie
  5. Attributi default degli oggetti DOM

Navigare con il vento in poppa fino ad affondare

Siamo quasi giunti alla fine di questa triologia e finalmente abbiamo il nostro browser che ha effettuato tutte le procedure di istanziamento, parsing e rendering, anche tutte le trasformazioni sono effettuate e le strutture dinamiche di scripting con i loro eventi sono state agganciate alla struttura DOM, e ora che rimane da fare?

Abbastanza, infatti il browser una volta finite tutte queste procedure base procede ad istanziare tutta una serie di proprietà e strumenti proprietari che basandosi sulla informazioni della pagina forniscono ulteriori informazioni su di essa. Tra questi strumenti possiamo citare in Internet Explorer la copiatura dell’albero DOM renderizzato visivamente all’oggetto di sistema MSAA che poi verrà usato dagli screen reader, oppure Opera controlla se nei meta informazioni utili a proporre una serie di short link o di skin alternative ma qui si dilaga, per il momento, nel proprietario.

Ultima operazione che effettua un browser e che io definisco in questo articolo “l’affondamento” e la distruzione di tutto l’albero DOM e delle strutture di programmazione quando si chiuderà il browser o si andrà in un altra pagina in modo da liberare completamente la memoria e renderla pronta per ricevere nuove strutture dati.

Conclusioni

In questa serie di articoli alcuni avranno notato che ho tralasciato una serie di sottoargomentazioni come il caching, i cookye o altre procedure. Questo l’ho fatto perchè anche se si pensa che siano procedure complesse in realtà sono molto semplici e nella loro banalità fanno solo dei controlli sui file fisici per poi salvarli o caricarli quando dovuto.

Gli obbiettivi che mi ero prefissato quando ho iniziato a scrivere la “Triologia del browser”, e che spero di aver raggiunto, sono quelli di far capire a tutti voi sviluppatori “lato client” che il browser è uno strumento interamente basato su strutture dati ed oggetti quindi se c’è qualcosa che non va nelle vostre pagine raramente è colpa del browser ma quasi sempre vi è un errore nel configurare una di queste classi in rapporto hai suoi valori di default. Inoltre vi ricordo che, per ovvi motivi cronologici, è inutile disperarsi per cercare di far funzionare alcune strutture “table less” su Netscape 4 o Internet Explorer 5 quando a quei tempi molti attributi non erano neanche stati presi in considerazione dagli attributi.

i browser non sono eterni, i contenuti si.