CSS Zibaldone

[ Home ] - [ Articoli ] - [ Traduzioni ] - [ Altro ] - [ Appunti sui CSS ] - [ L'autore ]

Sei qui: Home > Traduzioni > Attivare la giusta modalità di layout usando una dichiarazione di Doctype

Attivare la giusta modalità di layout usando una dichiarazione di Doctype

Articolo originale: http://hsivonen.iki.fi/doctype/

Autore: Henri Sivonen

Traduzione: Gabriele Romanato (7 gennaio 2008)

Al fine di gestire sia la vecchia zuppa di tag data ai vecchi browser sia le nuove pagine conformi allo standard CSS, Firefox (ed altri browser Mozilla basati su Gecko), Safari, Opera (7 e seguenti), Internet Explorer 6 e 7, Internet Explorer 5 Mac e Konqueror (3.2 e seguenti) hanno due modalità di layout principali. In una modalità il motore di rendering cerca di rendere le pagine secondo le specifiche CSS, mentre nell'altra si limita ad imitare la resa dei vecchi browser. In Firefox queste modalità sono note rispettivamente come "modalità standard" e "modalità quirk". In questo documento vengono usati gli stessi nomi per riferirsi alle modalità degli altri browser.

Retroscena

I bug e i comportamenti non-standard dei vecchi browser come Netscape Navigator 4.x ed Internet Explorer 5 per Windows vengono detti "quirk". Per esempio, non ereditare gli stili nelle tabelle è un quirk. Alcune volte le pagine sono state realizzate in modo che il loro layout dipende dai quirk.

La maggior parte dei quirk sono in relazione al layout e quindi in conflitto con i CSS. Rappresentare le pagine quirk secondo i CSS le renderebbe diverse dalle intenzioni dei loro autori. D'altro canto essere in grado di usare i CSS secondo le specifiche rappresenta una grande vittoria se paragonata allo scrivere pagine sempre e solo per i vecchi browser.

Modalità di layout

Per venire incontro ai contrastanti obiettivi della compatibilità a ritroso e della conformità ai CSS, i browser attuali hanno dalle due alle tre modalità di layout.

Modalità quirk

Nella modalità quirk i browser violano le specifiche CSS per ottenere un layout compatibile a ritroso. Quindi questa modalità non ha un unico obiettivo. Per esempio, Mozilla all'inizio ha cercato di imitare Netscape 4.x. Internet Explorer 6 e 7 Windows, invece, hanno cercato di imitare Internet Explorer 5 Windows.

Lo scopo della modalità quirk è evitare di "distruggere" le vecchie pagine. Se state scrivendo ora nuove pagine, dovreste conformarvi alle specifiche in uso (CSS 2.1 in particolare) e usare la modalità standard.

Modalità standard

Nella modalità standard i browser cercano di dare ai documenti conformi un trattamento corretto dal punto di vista delle specifiche, nella misura in cui tali specifiche sono state implementate in ogni browser.

Modalità quasi standard

Firefox, Safari ed Opera 7.5 (e seguenti) hanno anche una terza modalità nota come "modalità quasi standard", la quale implementa il dimensionamento verticale delle celle di tabella in modo non conforme alle specifiche CSS2. Internet Explorer 5 Mac, Internet Explorer 6 e 7 Windows, Opera prima della versione 7.5 e Konqueror non hanno bisogno di tale modalità, in quanto anche nella loro rispettiva modalità standard essi non implementano il dimensionamento verticale delle celle di tabella in modo conforme alle specifiche CSS2. Difatti le loro modalità standard sono più simili alla modalità quasi standard di Mozilla che a quella pienamente standard. È importante ricordare che anche se i vari browser hanno concettualmente modalità simili, le corrispettive modalità non sono identiche.

Parsing

"Zuppa di tag" è un termine che viene usato per designare delle pagine che non usano HTML valido. Questo termine designa di solito l'HTML che viene erroneamente considerato un linguaggio di programmazione della pagina quando invece non lo è. I vecchi browser non rifiutavano la zuppa di tag. I nuovi browser non possono farne a meno a causa del contenuto obsoleto esistente e quindi leggono il contenuto servito come text/html usando un parser non rigoroso. Tuttavia l'uso di marcatura scorretta è scoraggiato. La zuppa di tag non interagisce bene con i fogli di stile e il DOM.

Creare un albero del documento coerente da una marcatura male annidata richiede degli espedienti che non sarebbero necessari se tutto il contenuto fosse servito come HTML valido. Di solito questi espedienti (i cui dettagli variano da parser a parser) non fanno in modo che le pagine conformi vengano male analizzate. Poiché la stragrande maggioranza dei documenti serviti come text/html sono sintatticamente scorretti, gli espedienti usati per gestire la zuppa di tag non vengono disattivati quando si usa la modalità standard.

Vi sono anche alcuni quirk che influenzano il parsing della marcatura e dei fogli di stile e che farebbero in modo che le pagine conformi vengano male analizzate. Tuttavia è importante capire che la modalità quirk contro quella standard avviene per lo più nel parsing.

Alcune persone fraintendono la modalità standard come "modalità di parsing rigoroso", intendendo con questo dire che i browser andrebbero a verificare le regole sintattiche della marcatura e che un browser potrebbe essere usato per vagliare la correttezza di quest'ultima. Questo non avviene. I browser usano i sopracitati espedienti anche quando si usa la modalità standard (nel 2000, prima del rilascio di Netscape 6, Mozilla aveva un parser che verificava le regole della marcatura, ma si rivelò incompatibile con il mondo reale e fu abbandonato).

Un'altro fraintendimento comune riguarda il parsing XHTML. Alcune persone credono che usare un doctype XHTML implichi un parsing diverso. Non è così. I documenti XHTML serviti come text/html vengono letti usando lo stesso parser non rigoroso usato per l'HTML. Per quello che riguarda i browser, l'XHTML servito come text/html è solo zuppa di tag con qualche slash in più. Solo i documenti serviti usando un tipo di contenuto XML (per esempio application/xhtml+xml o application/xml) hanno un trattamento XML.

Doctype Sniffing (o scambio di Doctype)

Firefox, Safari, Opera (7 e seguenti), Internet Explorer Windows 6 e 7, Internet Explorer 5 Mac e Konqueror (3.2 e seguenti) usano tutti il doctype sniffing per decidere la modalità di layout per i documenti text/html. Questo significa che la modalità viene scelta in base alla dichiarazione del tipo di documento (o alla sua mancanza) all'inizio di un documento HTML (i documenti serviti usando un tipo di contenuto XML sono sempre in modalità standard.

Una dichiarazione del tipo di documento (doctype) contiene il nome (identificatore generico) dell'elemento radice ed una DTD (Document Type Definition) di riferimento che a sua volta contiene informazioni sulle regole sintattiche per il documento (in teoria l'intera DTD potrebbe essere incollata all'interno della dichiarazione del tipo di documento, ma in pratica viene usato un riferimento alla DTD). Nelle specifiche HTML la dichiarazione del tipo di documento deve comunicare le informazioni sulla versione di HTML. Nonostante il nome "dichiarazione del tipo di documento" e nonostante quanto detto dalle specifiche sulla "informazione di versione", tale dichiarazione non è un mezzo appropriato per classificare documenti SGML o XML come documenti di un particolare tipo, anche se lo si suppone (si veda alla fine di questo documento).

Né le specifiche HTML 4.01 né ISO 8879 (SGML) dicono alcunché a proposito dell'uso della dichiarazione del tipo di documento come modo per scambiare la modalità di layout. Il doctype sniffing si basa sul fatto che al momento in cui fu realizzato la stragrande maggioranza dei documenti quirk non aveva neanche una dichiarazione del tipo di documento o usavano una DTD obsoleta.

Una tipica DTD contiene (separata da spazio) la stringa <!DOCTYPE, l'identificatore generico dell'elemento radice (HTML), la stringa PUBLIC, un identificatore pubblico di una DTD tra virgolette, possibilmente un identificatore di sistema (un URL) della stessa DTD e il carattere >. La dichiarazione del tipo di documento viene posta prima del tag iniziale dell'elemento radice.

Gestione di alcuni Doctype

Nella seguente tabella, modalità quirk, standard, e quasi standard vengono indicate rispettivamente da Q, S e A. Quando un browser ne ha solo due, la modalità standard viene marcata con "S" (se l'interlinea nelle celle di tabella funziona come nella modalità standard di Mozilla) e con "A" (se l'interlinea di tali celle funziona come nella modalità quasi standard di Mozilla).

Lo scopo della tabella non è quello di suggerire che tutti i doctype elencati sono scelte preferenziali per le nuove pagine, ma di mostrare su quali basi io fondi le mie raccomandazioni, elencate dopo la tabella.

Vengono usate le seguenti abbreviazioni per le intestazioni:

NS6

Mozilla 0.6…0.9.4 e Netscape 6.0...6.2.3

Old Moz

Mozilla 0.9.5 fino alla 1.1 alpha e Mozilla 1.0

Moz & Safari

Mozilla 1.0.1, Mozilla 1.1 beta e seguenti, Firefox e Netscape 7, Safari v73 o 0.9 fino a Safari v419.3 o 2.0.4, Konqueror 3.5

Opera 9

Opera 9.0...9.10

Opera 7.5

Opera 7.5…8.02

IE 7 & Opera 7.10

Windows IE 7 e Opera 7.10...7.23

IE 6 & Opera 7.0

Windows IE 6 e Opera 7.0...7.03

Mac IE 5

Mac IE 5.0...5.2.3

Konq 3.2

Konqueror 3.2.2…3.3 (possibilmente anche 3.1…3.2.1, ma non sono in grado di confermare)

XHTML Basic (con dichiarazione XML) and XHTML 1.1 (con dichiarazione XML) non sono elencati nella tabella, perché il doctype sniffing si applica solo ai documenti serviti come text/html e se questi ultimi vengono serviti come text/html non dovrebbero essere usati. Tuttavia, se questi documenti vengono serviti come text/html, la selezione della modalità di layout funziona come per XHTML 1.0 Strict. In altre parole, Internet Explorer 6 Windows usa la sua modalità quirk se è presente la dichiarazione XML.

Inoltre si noti che XHTML 1.0 Transitional servito usando un tipo di contenuto XML viene considerato in (piena) modalità standard anche nelle ultime release di Mozilla.

Note storiche

Il doctype sniffing di Mozilla è cambiato in modo sostanziale nell'ottobre 2000, nel settembre 2001 e nel giugno 2002. Questo documento descrive la situazione con le release di Mozilla disponibile all'indirizzo ftp.mozilla.org del 19 ottobre 2000 e successivi (e con Netscape 6.x). Questo documento non si occupa del funzionamento del doctype sniffing in Mozilla Ml8 (e Netscape 6.0 PR3). Il doctype sniffing di Safari è cambiato a sua volta dalla prima versione beta pubblica. Questo documento non copre il comportamento delle versioni precedenti alla v73 (o 0.9).

Il doctype sniffing di Konqueror sembra provenire da una vecchia versione di Safari. Almeno nelle prime versioni di Safari, lo strano comportamento non era intenzionale ma era un bug. Ci si attende che il comportamento di Konqueror cambi (l'attuale doctype sniffing di Safari deriva da Mozilla).

Come si può evincere dalla tabella, il doctype sniffing di Opera si è gradatamente evoluto dall'essere simile a quello di Internet Explorer fino a diventare simile a quello di Mozilla. Al contempo la modalità quirk di Opera è passata dall'imitazione della modalità quirk di Internet Explorer a quella di Mozilla.

Scegliere un Doctype

Che dire di HTML5?

Ho continuato a raccomandare i due doctype descritti sopra fin dal 2000. Si è rivelato un utile e stabile consiglio.

Quando almeno due browser tra Firefox, Opera, Safari ed Internet Explorer supporteranno HTML5, intendo consigliare di usare il doctype HTML5. Tuttavia non è questo il momento, a meno che non siate coinvolti attivamente nelle discussioni su HTML5. Anticipare i tempi porterebbe ad una situazione simile a quella di Atom 0.3.

Pagine correlate

• Eric Meyer ha scritto un articolo sulle modalità di Internet Explorer 5 Mac in Use the Right Doctype.
• Mozilla's DOCTYPE sniffing a cura di David Baron
• CSS Enhancements in Internet Explorer 6 di Lance Silver discute le modalità ed il doctype sniffing in Internet Explorer 6 Windows.
• The Opera 9 DOCTYPE Switches

Aggiunta: Un appello agli sviluppatori di specifiche e agli implementatori di XML

Per favore, non usate il doctype sniffing in XML.

Il doctype sniffing è una soluzione per la zuppa di tag. Il doctype sniffing fu elaborato dopo che le specifiche HTML 4 e CSS2 furono scritte, essenzialmente come un modo euristico per distinguere i documenti obsoleti dagli altri documenti conformi.

Si è suggerito di usare il doctype sniffing in XML per riconoscere il vocabolario in uso o per attivare delle caratteristiche del linguaggio. Questa è una cattiva idea. Tale riconoscimento dovrebbe essere basato sullo spazio dei nomi e l'attivazione delle caratteristiche su esplicite istruzioni di elaborazione.

L'intero concetto del corretto formato fu introdotto per consentire il parsing dell'XML senza DTD e, per traslato, di documenti senza doctype. Formalmente, se due documenti XML hanno la stessa forma canonica e un'applicazione li tratta in modo differente (e la differenza non sta nella diversa elaborazione di entità esterna), è probabile che l'applicazione abbia dei problemi. In pratica se due documenti fanno in modo che lo stesso contenuto venga riportato al ContentHandler SAX2 ed un'applicazione li tratta in modo diverso, è probabile che l'applicazione abbia dei problemi. Come autori web non potete fare affidamento sul fatto che chiunque legga le vostre pagine usi un processore XML che elabori le entità esterne (anche se alcuni browser sembrano farlo dato che operano una correlazione tra alcuni id pubblici ed una DTD di definizioni di entità), e quindi inserire un doctype in XML per la pubblicazione web è inutile (potete sempre validare una DTD usando la sovrascrittura della DTD del validatore W3C, o usare la validazione RELAX NG, che non sfrutta riferimenti di schema). Usare un doctype solo per lo sniffing sarebbe stupido, anche se nella pratica questo avviene con l'HTML.

Inoltre quando una specifica di livello inferiore definisce due cose che sono equivalenti, una specifica di livello superiore non dovrebbe cercare di dare un diverso significato alle due cose. Si consideri <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">. Se viene rimosso l'identificatore pubblico, la stessa DTD resta designata, e quindi il doctype <!DOCTYPE html SYSTEM "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> ha lo stesso significato del precedente. Dovrebbero essere trattati diversamente? L'idea può essere portata avanti. Supponiamo che la DTD venga copiata su example.com e nominata foobar.dtd: <!DOCTYPE html SYSTEM "http://example.com/foobar.dtd">. Come la si dovrebbe trattare? Il significato è lo stesso. La stessa DTD potrebbe anche essere incollata inline!

In altre parole, se avete #include "foo.h", non dovreste collegare nulla al nome foo.h, dato che dovrebbe essere possibile incollare il contenuto di foo.h inline o copiare il contenuto di foo.h in bar.h e asserire #include "bar.h".

Il motivo per cui non voglio usare le stesse argomentazioni con HTML e SGML sta nel fatto che i browser web non usano veri parser SGML per leggere l'HTML, così non penso sia utile far finta che c'entri qualcosa SGML. Tuttavia se non siete ancora convinti leggete il post di W. Eliot Kimber sulla questione.