Attenti all'XHTML (Beware of XHTML)

Questo articolo è una traduzione di Beware of XHTML, di David Hammond.

[Torna alla home | Torna all'indice degli articoli]

Se siete sviluppatori web, avete probabilmente sentito parlare dell'XHTML, il linguaggio di markup sviluppato nel 1999 per poter aggiungere l'HTML alla famiglia dei linguaggi derivati dall'XML. La maggior parte delle persone che usano e promuovono l'XHTML lo fanno perché pensano che, essendo l'ultima versione, sia anche la migliore e perché potrebbero aver sentito di alcuni vantaggi (di solito falsi) qua e là. Ma ci sono più problemi di quanti voi immaginiate e se lo state usando nel vostro sito, anche se il codice è validato, probabilmente non lo state facendo correttamente.

Vorrei chiarirvi che mi auguro un futuro radioso per l'XHTML, ed è esattamente per questo che ho scritto questo articolo. Oggi la situazione dell'XHTML nella rete è addirittura peggiore di quella dell'HTML e molte persone non se ne accorgono nemmeno, perché i principali browser non interpretano le loro pagine come vero XHTML. Se anche voi sperate nel successo dell'XHTML fareste bene a leggere attentamente questo articolo.

Alcuni dei problemi affrontati in questo articolo sono tecnici e complicati. Se avete difficoltà a capirli, vi consiglio almeno di dare un'occhiata a i miti dell'XHTML, esempi di problemi legati al content type e la lista di siti che trattano di standard web che non funzionano con l'XHTML.

Alcune citazioni da sviluppatori e personalità rilevanti:

Microsoft (Internet Explorer):
"Se avessimo provato a supportare realmente l'XHTML in IE 7 avremmo finito con l'usare il nostro parser HTML già esistente (che è incentrato sulla compatibilità) adattandolo ai costrutti XML. Sarebbe improbabile riuscire a supportare adeguatamente l'XHTML in questo modo"
Mozilla (Firefox):
"Se state usando le caratteristiche proprie dell'HTML [...] servire HTML 4.01 valido come text/html assicurerà il più vasto supporto dei browser e dei motori di ricerca."
Apple (Safari):
"Al giorno d'oggi, la cosa migliore da fare è usare sempre HTML4 per i vostri documenti. L'utilizzo corretto dell'XHTML non è facoltativo, quindi la cosa migliore da fare è continuare a usare HTML4."
Håkon Wium Lie (from Opera, W3C):
"Non penso che l'XHTML sia un'alternativa realistica per le masse. HTML5 lo sarà."
Anne van Kesteren (from Opera):
"Sono a favore dell'utilizzo dell'XHTML solo nella maniera corretta, il che significa che dovete usare HTML. Punto."
Ian Hickson (from Opera, Google, W3C):
"Gli autori che vogliono divulgare pubblicamente il loro lavoro dovrebbero continuare ad usare HTML 4.01"

Indice

  1. Cos'è l'XHTML
  2. Miti dell'XHTML
  3. Vantaggi dell'XML
  4. Il Content type è tutto
  5. Linee guida di compatibilità con l'HTML
  6. L'incompatibilità di Internet Explorer
  7. Content negotiation
  8. Null End Tags (NET)
  9. Firefox e altri problemi
  10. Conclusioni
  11. Lista di siti che trattano di standard web che non funzionano con l'XHTML
  12. Lista di siti che trattano di standard web e continuano a usare HTML
  13. Siti correlati
  14. Vedi anche
  15. Glossario

Cos'è l'XHTML?

^

L'XHTML è il linguaggio di markup che, si spera, dovrebbe sostituire l'HTML (in un futuro distante). Un documento XHTML 1.0 differisce da uno HTML 4.01 principalmente per le regole sintattiche e lessicali: HTML è basato su un sottoinsieme a sé stante dell'SGML, mentre l'XHTML deriva da un altro sottoinsieme dell'SGML chiamato XML. I sottoinsiemi dell'SGML si differenziano tra loro per gli insiemi di caratteri che delimitano tag e altri costrutti, per la presenza o meno di certi tipi di "scorciatoie" nel markup (come gli attributi minimizzati, tag di inizio/fine tralasciabili, ecc.), per essere case sensitive o no e così via.

La Definizione del Tipo di Documento (DTD o Doctype) definisce quali elementi, attributi ed entità esistono nel linguaggio e dove gli elementi possono trovarsi all'interno del documento. I Doctype dell'XHTML 1.0 e dell'HTML 4.01 sono praticamente identici e, a parte piccole differenze tra elementi e attributi, l'HTML 4.01 e l'XHTML 1.0 sono essenzialmente lo stesso linguaggio. L'unico beneficio aggiunto all'XHTML è che, utilizzando il sottoinsieme XML dell'SGML, ne condivide tutti i vantaggi che ha rispetto all'HTML.

Miti dell'XHTML

^

Ci sono molti falsi benefici dell'XHTML promossi nel Web. Chiariamo brevemente alcuni di essi (approfondendoli più avanti):

Vantaggi dell'XML

^

L'XML ha diversi miglioramenti rispetto all'HTML:

Il Content type è tutto

^

Quando il vostro sito web invia un documento alla pagina del visitatore, aggiunge uno speciale header che indica il tipo di contenuto e fa sapere al browser con che tipo di documento ha a che fare. Per esempio, un'immagine PNG ha il content type[6] image/png e un file CSS ha text/css. I documenti HTML hanno il content type text/html. Di solito i Web server usano questo content type quando l'estensione del file è .html e i linguaggi di scripting lato-server come PHP fanno lo stesso, inviando i documenti come text/html di default.

L'XHTML non ha lo stesso content type dell'HTML. Il content type corretto per l'XHTML è application/xhtml+xml. Attualmente, molti web server non hanno associato questo content type con nessuna estensione, quindi si dovrebbe modificare il file di configurazione del server o usare un linguaggio di scripting lato-server per inviare l'header manualmente. Specificare semplicemente il content type in un elemento meta non funziona con l'HTTP.

Quando un browser vede il content type text/html, indipendentemente da quello che dice il doctype, dà per scontato che si tratti di normale HTML. Di conseguenza, invece che usare il parser XML, tratterà il documento come una "tag soup"[7], aspettandosi del contenuto HTML. L'HTML 4.01 e il semplice XHTML 1.0 sono molto simili, quindi il browser riesce lo stesso a capire la pagina abbastanza bene. La maggior parte dei browser considerano cose come la fine dei self-closing tag[8] (come in <br />) come un semplice errore HTML e quindi lo eliminano, di solito terminandolo con l'equivalente HTML che l'autore intendeva.

Tuttavia, quando il documento è trattato come HTML, non sarà possibile avere nessuno dei vantaggi che XHTML offre. I browser non saranno in grado di interpretare gli altri formati XML come MathML e SVG inclusi nel documento e non faranno la validazione automatica che i parser XML fanno. Per essere trattato correttamente, il documento deve essere inviato con il content type application/xhtml+xml.

E non è finita qui. I tag dei commenti a volte sono interpretati differentemente a seconda del content type e quando includete il contenuto di un elemento script o style in un commento SGML, verrà completamente ignorato quando il documento è trattato come XML. Inoltre ogni speciale carattere di markup (N.d.T. come, per esempio, il carattere < di inizio tag) usato all'interno degli elementi style o script sarà interpretato come markup invece che essere trattato come un normale carattere, cosa che invece non accade nell'HTML. Per risolvere questo problema bisogna usare una elaborata sequenza di escape descritta nell'articolo Escaping Style and Script Data e, nonostante questo, ci sono situazioni in cui non funziona.

Oltretutto, le specifiche DOM e CSS hanno regole speciali per l'HTML che non sono applicate all'XHTML quando è trattato come XML, quindi la vostra pagina potrebbe apparire o comportarsi in modo inaspettato. Il problema più comune è uno spazio bianco intorno alla vostra pagina quando avete impostato uno sfondo al body ma non all'html ed è presente qualsiasi tipo di spazio tra questi elementi, come margin, padding o un'altezza del body inferiore al 100% (e di solito i browser hanno, di default, qualche combinazione di questi). Per quanto riguarda lo scripting, i nomi dei tag sono riportati diversamente e document.write() non funziona con l'XHTML trattato come XML e anche la struttura delle tabelle nel DOM è interpretata diversamente. E queste sono solo alcune delle molte differenze.

Nella tabella seguente ci sono alcuni esempi che mostrano la differenza tra l'XHTML trattato come HTML e l'XHTML trattato com XML. I risultati previsti si basano sul modo in cui Internet Explorer, Firefox, e Opera trattano XHTML servito come HTML (altri browser invece si comportano diversamente). Bisogna anche notare che Internet Explorer non riconosce il content type application/xhtml+xml (vedi sotto per una spiegazione dettagliata), quindi non sarà in grado di visualizzare gli esempi della seconda colonna.

Differenze nell'interpretazione dell'XHTML
text/html application/xhtml+xml
Esempio 1 Esempio 1
Esempio 2 Esempio 2
Esempio 3 Esempio 3
Esempio 4 Esempio 4
Esempio 5 Esempio 5
Esempio 6 Esempio 6
Esempio 7 Esempio 7
Esempio 8 Esempio 8
Esempio 9 Esempio 9
Esempio 10 Esempio 10

Linee guida di compatibilità con l'HTML

^

Quando le specifiche dell'XHTML 1.0 furono scritte per prima volta, si pensò di consentire l'invio di documenti XHTML come text/html a condizione che venissero rispettate certe linee guida. L'idea era di facilitare il passaggio al nuovo formato mantenendo la compatibilità con i vecchi user agent. Tuttavia queste disposizioni sono viste da molti come un errore. Lo scopo principale dell'XHTML è di essere un'alternativa XML all'HTML nonostante sia possibile inviare questi documenti come text/html. La maggior parte dei cosiddetti documenti XHTML non funzionerebbero se venissero interpretati come XML (vedi alcuni esempi reali). Consapevole del problema, il W3C ha rimosso queste disposizioni nella prima revisione delle specifiche XHTML. Ora il W3C dice chiaramente che nell'XHTML 1.1 e nelle versioni successive, le pagine non dovrebbero più essere inviate come text/html. L'XHTML dovrebbe essere inviato come application/xhtml+xml o usando uno dei content type XHTML più elaborati.

L'incompatibilità di Internet Explorer

^

Internet Explorer non supporta XHTML. Come accade con altri browser, i documenti inviati come text/html vengono trattati come documenti HTML scritti male. Quando i documenti sono inviati come application/xhtml+xml, Internet Explorer non li riconosce come una pagina web e quindi mostra all'utente la finestra di download. Questo problema esiste ancora su Internet Explorer 7.

Anche se tutti gli altri browser principali, inclusi Firefox, Opera, Safari e Konqueror, supportano l'XHTML, la mancanza di supporto di Internet Explorer, dei maggiori motori di ricerca e di altre applicazioni web ne scoraggiano fortemente l'uso.

Content negotiation

^

L'idea dietro al "content negotiation" (negoziazione di contenuto) è di inviare contenuti diversi a seconda di quello che gli user agents supportano. Molti siti inviano XHTML come application/xhtml+xml a chi lo supporta e XHTML come text/html oppure vero HTML agli altri.

Ci sono due metodi usati di solito per determinare i contenuti supportati dagli user agent usando l'header HTTP Accept[1]: il primo, quello più usato ma non corretto, consiste nel cercare la stringa "application/xhtml+xml" nell'header; il secondo quello corretto ma usato da pochi, consiste nel controllare l'header usando wildcard e ordinando in base al valore q.

Sfortunatamente nessuno dei due metodi è molto attendibile.

Il primo non funziona perché non tutti gli user agent che supportano XHTML hanno il testo "application/xhtml+xml" nell'header Accept. Safari e Konqueror sono due di questi perché lo includono implicitamente in un valore wildcard. D'altra parte non tutti gli user agent che supportano l'HTML hanno "text/html" nell'header; Internet Explorer, per esempio, non menziona questo content type che, così come accade con Safari e Konqueror, è incluso usando un valore wildcard[9]. Anche tra gli user agent che supportano XHTML e menzionano application/xhtml+xml nell'header, ci potrebbe essere un valore q[10] inferiore rispetto a quello di text/html (o di un altro wildcard adatto) e quindi significa che l'user agent attualmente preferisce text/html (in altre parole il supporto ad XHTML potrebbe essere sperimentale o incompleto).

Il secondo metodo (quello corretto e standard al 100%) non funziona perché la maggior parte dei browser hanno header Accept inesatti:

Sfortunatamente, il content negotiation non è una soluzione affidabile a questo problema.

Null End Tags (NET)

^

Nell'XHTML tutti gli elementi devono essere chiusi, sia da un tag di chiusura, sia aggiungendo uno slash (/) al tag di apertura per renderlo self-closing[8] ("auto-chiudente"). Siccome chiudere gli elementi come img o br con un tag di chiusura confonderebbe i browser che trattano la pagina come HTML, si preferisce usare i self-closing tag. Tuttavia i self-closing tag XML sono in diretto conflitto con una caratteristica HTML/SGML poco conosciuta e supportata: i Null End Tags.

Un Null End Tag è una particolare forma abbreviata per scrivere tag usata per risparmiare qualche carattere nel documento. Invece che scrivere <title>My page</title>, si può semplicemente scrivere <title/My page/ ottenendo lo stesso risultato. A causa delle regole dei Null End Tags, un singolo slash nel tag di apertura di un elemento vuoto ne indica la fine, quindi <br/ è un tag HTML valido e completo. Ciò significa che, se avete dei <br/> o <br />, i browser che supportano i Null End Tag vedranno un elemento br immediatamente seguito da un semplice carattere >. Quindi una pagina XHTML trattata come HTML potrebbe risultare piena di > non voluti.

Questo problema è spesso trascurato perché i principali browser non supportano i Null End Tag, come anche altre forme abbreviate dell'SGML. Tuttavia ci sono ancora alcuni user-agent minori che li supportano e uno dei più conosciuti è il W3C validator. Inviandogli una pagina che usa i tag self-closing dell'XHTML e forzandolo ad trattare la pagina come HTML/SGML (come fanno molti user agent per le pagine inviate con text/html) si può vedere il risultato nell'outline: immediatamente dopo ogni elemento self-closing c'è un > non voluto che viene visualizzato nella pagina stessa.

(Bisogna notare che il Validator del W3C è insolito perché generalmente sceglie il modo d'interpretare il documento dal doctype piuttosto che dal content type, come fanno molti user agent. Quindi, in questo esempio, è stato usato un doctype HTML in modo che il validator interpreti la pagina usando il sottoinsieme HTML dell'SGML, come accade nei browser principali quando ricevono text/html indipendentemente dal doctype. Le regole dei Null End Tag sono attualmente dichiarate nella definizione del sottoinsieme SGML, non nel DTD, quindi questo è esattamente quello che vi aspettereste in un user agent che supporta completamente SGML, anche se usate un doctype XHTML.)

Tecnicamente, nell'XML esiste una diversa e limitata forma dei Null End Tag usata frequentemente: la parte self-closing del tag di apertura. Mentre i Null End Tag sono definiti come / ... / nel sottoinsieme HTML dell'SGML, nell'XML sono definiti come / ... > con la limitazione aggiuntiva che deve essere chiuso subito dopo la sua apertura, cioè senza avere nessun contenuto. Questo è stato progettato per assomigliare a un normale tag di apertura per gli sviluppatori web che non hanno familiarità con i tipici Null End Tag. Tuttavia in questo processo si sono create incompatibilità con il sottoinsieme HTML dell'SGML per tutti gli elementi vuoti.

In breve, anche se questo problema non è visibile nei browser più popolari, un user agent con un supporto dell'SGML più completo vedrebbe > in tutte le pagine XHTML inviate con il content type text/html. Se l'obiettivo di usare l'XHTML è di aiutare a promuovere gli standard, è abbastanza controproducente causare problemi non necessari per gli user agent che aderiscono più correttamente allo standard SGML.

Firefox e altri problemi

^

Anche se Firefox supporta l'interpretazione dei documenti XHTML come XML quando sono inviati con il content type application/xhtml+xml, le sue prestazioni nelle versioni 2.0 e inferiori sono attualmente peggiori rispetto all'interpretazione di pagine HTML. Quando interpreta una pagina come HTML, Firefox comincia a visualizzarla mentre viene scaricata. Questo è chiamato rendering incrementale (incremental rendering). Quando invece interpreta pagine XML deve aspettare che l'intera pagina sia scaricata e controllare che sia "well-formed" prima di visualizzarla. Questo significa che, anche se in teoria l'XML dovrebbe essere più veloce da interpretare rispetto all'HTML, in realtà in queste versioni di Firefox il contenuto delle pagine HTML è visualizzato molto più velocemente del contenuto XHTML/XML. Fortunatamente questo problema dovrebbe essere risolto con Firefox 3.0.

Tuttavia, ci sono altri problemi in altri browser, come certe disposizioni specifiche dell'HTML negli standard DOM e CSS che vengono applicate erroneamente alle pagine con contenuto XHTML interpretato come XML. Per esempio, se c'è uno sfondo impostato sull'elemento body e non sull'elemento html, Opera applicherà lo sfondo all'elemento html come accade nell'HTML. Anche utilizzando solo XHTML interpretato come XML ci sono lo stesso diversi problemi, così come quando è inviato in altri modi.

In molti browser però, il vero supporto dell'XHTML è ancora molto limitato. A causa di un user agent chiave, chiamato Internet Explorer, che non ha fatto nessuno sforzo visibile per supportare l'XHTML, tutti gli altri user agent principali hanno continuato a vederlo con una priorità relativamente bassa rimandando la correzione di questi bug. L'HTML è più raccomandato rispetto all'XHTML sia da Mozilla che da Safari e, generalmente, è supportato meglio dell'XHTML da tutti i browser principali.

Conclusioni

^

L'XHTML è una cosa molto buona e spero veramente che venga accettato diffusamente nel futuro. Tuttavia, non è supportato ampiamente nella sua forma reale. XHTML è un formato XML e forzare i browser a trattarlo come HTML va contro lo scopo dell'XHTML causando inevitabilmente altre complicazioni. A meno che non vogliate limitare drasticamente l'accesso alle vostre informazioni, l'XHTML può essere usato solo scorretamente, venendo interpretato come markup invalido da molti user agent, causando risultati non voluti in altri e senza offrire vantaggi aggiuntivi rispetto all'HTML. HTML 4.01 Strict è ancora ciò che la maggior parte degli user agent e dei motori di ricerca sono abituati a ricevere e non c'è assolutamente nulla di male a usarlo se non avete bisogno dei vantaggi aggiuntivi dell'XML. HTML 4.01 è ancora una Raccomandazione del W3C che ha anche annunciato piani per un ulteriore sviluppo dell'HTML accanto all'XHTML, in futuro.

Lista di siti che trattano di standard web che non funzionano con l'XHTML

^

I siti seguenti sono solo alcuni tra gli innumerevoli siti che usano un doctype XHTML ma, mentre scrivo, non si caricano del tutto oppure hanno problemi quando sono interpretati come XML, venendo meno all'obiettivo dell'XHTML. Gli autori di molti di questi siti sono abbastanza conosciuti nella comunità degli standard web, molti di essi sono impegnati nel Web Standards Project (WaSP), tuttavia sono cascati nella "trappola" dell'XHTML. Infatti ho scoperto che quasi tutti i siti XHTML dei membri del WaSP hanno problemi quando sono interpretati come XML.

Accessify - WaSP Steering Committee, Accessibility Task Force
Visualizzato come XML generico, non interpretato come XHTML. Manca il namespace XML.
all in the <head> - WaSP Steering Committee
La pagina non viene caricata. Non well-formed. (Nota: questa pagina è valida rispetto al DTD XHTML e al sottoinsieme XML dell'SGML, ma l'XML ha regole aggiuntive per definire le pagine "well-formed" che questa pagina non rispetta, come osservato nel post Textpattern and the Technorati Link Count Widget. Un caso di prova simile è disponibile.)
And all that Malarkey - WaSP Accessibility Task Force
La pagina non viene caricata . Non well-formed.
CSS Zen Garden - WaSP
Il background superiore non viene visualizzato. La pagina fa affidamento su un comportamento dello sfondo specifico dell'HTML. Diversi design hanno errori dovuti allo stesso problema.
dean.edwards.name/weblog/ - WaSP DOM Scripting Task Force, Microsoft Task Force
Nei browser che supportano il "behavior" per evidenziare dinamicamente la sintassi delle parti di codice (Firefox incluso), la maggior parte dei box di codice non vengono caricati, lasciando diversi "buchi" nella pagina. (N.d.T.Il "behavior" è una proprietà non standard dei CSS, proposta per i CSS3, che permette di associare del codice JavaScript all'elemento. In questo sito il codice associato comprende dei document.write() che, come abbiamo già detto nel paragrafo Il Content type è tutto, non funzionano con l'XHTML.)
dog or higher
La pagina non viene caricata . Non well-formed.
Elly Thompson's Weblog
La pagina non viene caricata . Non well-formed.
g9g.org - WaSP Steering Committee
C'è uno spesso spazio bianco attorno alla pagina. La pagina fa affidamento su un comportamento dello sfondo specifico dell'HTML.
holly marie - WaSP Steering Committee
La pagina non viene caricata . Non well-formed.
Jeffrey Veen - WaSP emeritus
La pagina non viene caricata . Non well-formed.
KuraFire - WaSP
La pagina non viene caricata . Non well-formed.
Meriblog
Lo sfondo appare bianco invece che viola. La pagina fa affidamento su un comportamento dello sfondo specifico dell'HTML.
mezzoblue - WaSP
Visualizzato come XML generico, non interpretato come XHTML. Manca il namespace XML. Inoltre, le pagine per inviare messaggi individuali non funzionano. Non well-formed.
microformats
La pagina non viene caricata . Non well-formed.
molly.com - WaSP Group Lead
Lo script Flickr non viene inizializzato perché il contenuto dello script è commentato.
Off the Top - WaSP Steering Committee
La pagina non viene caricata . Non well-formed.
unadorned.org - WaSP Steering Committee
Il foglio di stile non viene caricaro perché la regola import è commentata.
WordPress - WaSP
La pagina non viene caricata . Non well-formed.

Potete testare come una pagina XHTML viene realmente renderizzata in Firefox usando l'estensione Force Content-type e impostando il nuovo content type come application/xhtml+xml.

Lista di siti che trattano di standard web e continuano a usare HTML

^

Questi sono alcuni siti significativi che trattano di standard web e continuano a usare HTML invece che XHTML.

Vedi anche

^

Glossario

^
Header HTTP:
Gli Header sono indicazioni situate all'inizio di un documento. Forniscono informazioni aggiuntive sul documento.
User Agent:
Gli user agent sono programmi, come i browser, che accedono a documenti web.
Well-formed:
Un documento è well-formed quando segue un particolare insieme di regole sintattiche specifiche dell'XML.
Parser:
Il parser è un programma in grado di determinare la struttura e gli attributi di un documento SGML.
Marked Section:
Speciali costrutti presenti nell'SGML/XML. La struttura di una marked section è <![ KEYWORD [ Contenuto ]]>. KEYWORD può assumere diversi valori, come CDATA, INCLUDE e IGNORE e serve a indicare al parser come comportarsi.
Content type:
Il Content type è un Header HTTP che indica il tipo di documento inviato.
Tag soup:
"Minestrone di tag", indica un documento HTML scritto senza seguire le regole strutturali e semantiche dell'HTML.
Self-closing tag:
Tag "auto-chiudenti" che non hanno contenuto, come <br /> o <img ... />.
Wildcard:
Un particolare simbolo (come ad esempio l'asterisco) che rappresenta uno o più caratteri. Ad esempio, text/* comprende sia text/html che text/plain.
Valore q :
È un valore contenuto nell'header Accept che indica il livello di preferenza dell'user agent per un determinato content type.