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:
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.
Ci sono molti falsi benefici dell'XHTML promossi nel Web. Chiariamo brevemente alcuni di essi (approfondendoli più avanti):
L'XHTML non invita a separare il contenuto dalla presentazione più di quanto l'HTML già non faccia. L'XHTML ha tutti gli elementi e gli attributi (inclusi quelli di presentazione) che ha l'HTML e non offre nessuna caratteristica aggiuntiva nei CSS. Scrivere markup semantico e separare il contenuto dalla presentazione è altrettanto possibile nell'HTML senza nessuna difficoltà aggiuntiva.
La maggior parte delle pagine XHTML non sono trattate come XML dai browser odierni e non potrebbero neanche esserlo. Addirittura molte pagine XHTML valide non possono essere trattate come XML. Vedere l'articolo Validity and Well-Formedness per maggiori dettagli e esempi .
L'HTML non è deprecato e non sarà rimpiazzato. Infatti, il World Wide Web Consortium ha recentemente rinnovato il gruppo di lavoro dell'HTML che sta lavorando allo sviluppo dell'HTML 5.
L'XHTML non è molto supportato dai browser. La maggior parte di essi interpretano le pagine XHTML come semplice HTML. Alcuni dei principali browser come Firefox, Opera e Safari possono essere in grado di interpretare le pagine XHTML, ma solo se sono inviate con uno speciale header HTTP[1]. Tuttavia, quando si usa l'header HTTP, Internet Explorer e altri user agent[2] non sanno cosa fare e non visualizzano nemmeno la pagina. Anche i browser che sono in grado di interpretare l'XHTML lo fanno con diversi problemi aggiuntivi.
Quando i browser interpretano correttamente XHTML valido, non lo fanno molto più velocemente di quanto non succeda con l'HTML. Anche se i browser non devono usare algoritmi complessi per adattarsi alla flessibilità dell'HTML, devono usare algoritmi extra per confermare che il documento sia "well-formed"[3]. L'XHTML interpretato con un parser[4] XML può essere leggermente più veloce rispetto all'HTML, ma la differenza non è molto significativa. Ad ogni modo, il tempo dedicato all'interpretazione delle pagine è praticamente irrilevante in confronto a quello impiegato per il download, quindi gli utenti non noteranno nessun miglioramento sostanziale.
L'XHTML non potrà essere esteso se avete intenzione di supportare Internet Explorer e gli altri user agent che, non riuscendo a interpretare l'XHTML come XML, lo trattano come HTML perdendo così tutti i vantaggi legati all'estensibilità.
Il sorgente XHTML non deve necessariamente apparire molto diverso da quello HTML. Se preferite essere sicuri che tutti gli elementi non vuoti abbiano un tag di chiusura, potete usarli anche in HTML. Le uniche vere differenze di markup tra i documenti HTML e quelli XHTML che seguono le linee guida di compatibilità sono il doctype, l'elemento html
e la fine del tag />
(che sono solo molti dei costrutti abbreviati che molta gente dice di non apprezzare dell'HTML).
L'XML ha diversi miglioramenti rispetto all'HTML:
Anche se l'HTML consente diversi markup abbreviati e altre flessibilità, è dimostrato che è troppo difficile scrivere un parser[4] completo e corretto per esso. Come risultato, molti user agent, inclusi tutti i principali browser, interpretano a modo loro le forme lessicali dell'HTML (facendo molte ipotesi tecnicamente sbagliate sulla forma lessicale dei documenti HTML) e non supportano diverse caratteristiche come i Null End Tags (<tag/Contenuto/
), tag di inizio/fine non chiusi (<tag<tag>
) e tag vuoti (<>
). L'XML è stato progettato per eliminare queste caratteristiche extra e limitare i documenti a un ristretto gruppo di regole più semplici da implementare per gli user agent. In effetti, l'XML definisce le ipotesi che gli user agent possono fare, ottenendo un file che, teoricamente, può essere interpretato dagli user agent che supportano completamente l'SGML, una volta che sono stati indirizzati alla dichiarazione XML dell'SGML.
Un parser XML non è molto più semplice da scrivere rispetto al livello di supporto dell'HTML offerto da molti parser HTML. La maggior parte delle caratteristiche che rendono un parser HTML più difficile da scrivere, come le dichiarazioni SGML personalizzate, "marked section"[5] aggiuntive e la maggior parte dei costrutti abbreviati, hanno tuttavia una funzione trascurabile e di solito hanno un supporto scarso o del tutto assente nei browser principali. La differenza più significativa è la mancanza di supporto per i tag di apertura e chiusura mancanti che contribuiscono a complicare la logica del parser HTML per gli elementi che non sono definiti come vuoti. Oltretutto, molti browser seguono delle loro regole invece che usare quelle derivate dal DTD semplificando ulteriormente il lavoro del parser.
Per evitare brutte sorprese durante l'interpretazione dei documenti, gli user agent XML sono programmati per non accettare nessun errore: se l'user agent incontra un problema nel documento XML semplicemente smette di interpretarlo e mostra un messaggio d'errore al posto della pagina. Costringendo i documenti a essere "well-formed" si evitano i problemi di compatibilità nell'interpretazione di codice scritto non correttamente e nei metodi usati dai vari browser per trattare gli errori, indicando inoltre all'autore della pagina l'errore. Tuttavia questo vuol dire che anche un piccolo problema come un ampersand (&
) in un URL non convertito nell'entità corrispondente (&
) compromette l'intera pagina e quindi, molte delle applicazioni web odierne non possono essere incorporate in una vera pagina XHTML con sicurezza.
Gli user agents dovrebbero interrompere il caricamento in tutte le pagine che non sono "well-formed" (cioè quelle che non seguono le regole grammaticali dell'XML), ma in realtà non dovrebbero farlo nelle pagine che sono "well-formed" ma invalide. Per esempio, anche se non è valido avere uno span
direttamente sotto al body
, la maggior parte dei browser che supportano XML non segnalano l'errore perché la pagina è comunque "well-formed", anche se il DTD è violato, non lo sono le regole fondamentali dell'XML. Alcuni user agent potrebbero scegliere di fare anche da "validatori" interrompendo il caricamento quando incontrano codice non valido, ma non sono molti.
Al contrario di quello che si pensa, anche se una pagina XML è perfettamente valida, potrebbe non essere "well-formed".
Mentre il sottoinsieme dell'HTML è stato creato appositamente per l'HTML, quello dell'XML è usato in molti linguaggi differenti. Questo significa che scrivendo un unico semplice parser si possono supportare diversi linguaggi. I Namespaces dello standard XML consentono di avere più documenti in diversi formati XML nello stesso documento XML, quindi potreste avere, per esempio, una pagina XHTML che contiene una o più immagini SVG che usano MathML al loro interno.
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.
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 |
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.
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.
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:
application/xhtml+xml
con un valore q più alto di text/html
, anche se Mozilla ha pubblicato una raccommandazione ufficiale sul loro sito dicendo che i siti web dovrebbero, se possibile, usare text/html
per queste versioni per le ragioni descritte di seguito.text/html
né application/xhtml+xml
nell'header Accept
. Entrambi i content type sono inclusi in un unico valore wildcard (ciò significa che tutti i content type compresi sono supportati ugualmente bene, il che è ovviamente falso). Internet Explorer dice che è in grado di supportare ugualmente sia text/html
sia application/xhtml+xml
, anche se attualmente non offre nessun supporto ad application/xhtml+xml
. Nel caso che l'user agent dica di supportarli entrambi allo stesso livello, il sito può usare il content type che preferisce. Un possibile metodo per aggirare questo problema è inviare preferibilmente text/html
o, in una situazione di parità, inviare application/xhtml+xml
solo se è menzionato esplicitamente nell'header. Tuttavia...text/html
e application/xhtml+xml
lo stesso valore q (infatti, come anche Internet Explorer, entrambi dicono di supportarli ugualmente bene). Ma essi non menzionano esplicitamente application/xhtml+xml
ma lo includono con una wildcard. Quindi se aggirate il problema come descritto sopra, Safari e Konqueror riceveranno text/html
anche se supportano realmente application/xhtml+xml
.Sfortunatamente, il content negotiation non è una soluzione affidabile a questo problema.
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.
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.
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.
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.
document.write()
che, come abbiamo già detto nel paragrafo Il Content type è tutto, non funzionano con l'XHTML.)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
.
Questi sono alcuni siti significativi che trattano di standard web e continuano a usare HTML invece che XHTML.
<![ KEYWORD [ Contenuto ]]>
. KEYWORD
può assumere diversi valori, come CDATA
, INCLUDE
e IGNORE
e serve a indicare al parser come comportarsi.
<br />
o <img ... />
.text/*
comprende sia text/html
che text/plain
.Accept
che indica il livello di preferenza dell'user agent per un determinato content type.