Servire XHTML come text/html è ritenuto dannoso

Quella che segue è la traduzione dell'articolo originale pubblicato da Ian Hickson.

Riassunto

Vengono discussi alcuni problemi risultanti dall'uso del MIME type text/html in unione al contenuto XHTML. Viene suggerito che l'XHTML servito come text/html è debole e l'XHTML servito come text/xml è dannoso. Così gli autori che destinano il loro lavoro alla fruizione pubblica dovrebbero usare HTML 4.01, e gli autori che intendono usare XHTML dovrebbero servire la loro marcatura come application/xhtml+xml.

Altre versioni

Une traduction francaise est disponible: http://www.hixie.ch/advocacy/xhtml.fr

Il team di sviluppo di Safari ha inserito un post in merito all'argomento sul loro blog: http://webkit.org/blog/?p=68.

Contesto

Questo articolo è stato scritto originariamente nel contesto di questo post: http://ln.hixie.ch/?start=1031465247&count=1

Da allora è stato aggiornato regolarmente per correggere gli errori messi in evidenza su varie mailing list e altri forum di discussione. Come per la fine del 2004, esso ha la stessa rilevanza avuta all'epoca della sua pubblicazione.

Si noti che questo documento compara l'XHTML 1.0 conforme nell'Appendice C con l'HTML 4.01, poichè questa è l'unica variante di XHTML che può essere inviata come text/html.

Terminologia: l'Appendice C si riferisce alle cosiddette "Linee guida di compatibilità con l'HTML" della specifica XHTML che si trovano all'indirizzo http://www.w3.org/TR/xhtml1/#guidelines.

Sommario d'uso

Se usate XHTML, dovreste servirlo con il MIME type application/xhtml+xml . Se non lo fate, dovreste usare HTML4 invece di XHTML. L'alternativa, usare XHTML ma servirlo come text/html, causa numerosi problemi descritti di seguito.

Sfortunatamente, IE6 non supporta application/xhtml+xml (difatti, non supporta affatto XHTML ).

Perchè usare text/html per l'XHTML è un male

Quello che succede di solito agli autori che decidono di inviare XHTML come text/html è il seguente:

Gli autori scrivono XHTML ritenuto funzionante solo per la zuppa di tag [tag soup, N.d.T.] o per i browser HTML4, e non per i browser XHTML, e lo inviano come text/html. (Le supposizioni comuni sono elencate di seguito)
Gli autori vedono che tutto funziona bene.
Passa il tempo.
Gli autori decidono di inviare lo stesso contenuto come application/xhtml+xml, perchè, dopo tutto, è XHTML.
Gli autori si trovano di fronte ad un sito orribile. (Si veda più avanti l'elenco dei motivi)
Gli autori cominciano a detestare l' XHTML.

I punti da 1 a 5 sono stati riscontrati da ogni persona con cui ho parlato che è passata al MIME type XHTML. L'unico motivo per cui in questi casi non si è verificato il punto 6 è perchè si trattava di autori esperti che avevano appreso un modo per risolvere il problema col loro contenuto.

Problemi specifici

I seguenti sono problemi che affliggono i documenti quando questi passano da text/html a application/xhtml+xml:

Agli elementi <script> e <style> in XHTML inviati come text/html devono essere applicati gli escape usando stringhe ridicolmente complicate.

Questo avviene perchè in XHTML, gli elementi <script> e <style> sono blocchi #PCDATA, non blocchi #CDATA, e quindi  sono realmente tag di commento , e non sono ignorati dal parser XHTML. Per applicare gli escape agli script in un documento XHTML che può essere gestito come HTML4 o XHTML, si deve usare:
```
<script type="text/javascript">
<![CDATA[//><!]]></script>
```
Per inserire un CSS in un documento XHTML gestito sia come HTML4 che XHTML, si deve usare:
```
<style type="text/css">
<![CDATA[/*></style>
```
Si, è abbastanza ridicolo. Se ai documenti non vengono applicati gli escape come sopra, i contenuti degli elementi <script> e <style> cadono letteralmente a terra se analizzati come vero XHTML.

(Per far questo si presuppone che voi vogliate far funzionare le vostre pagine sia con i vecchi browser che con i browser XHTML. Se vi preoccupate solo dei browser XHTML e HTML4, potete semplificare la cosa.)
Un foglio di stile CSS scritto per un documento HTML4 viene interpretato in modo leggermente diverso in un contesto XHTML (per esempio, l'elemento <body> non è magico in XHTML, e i nomi dei tag devono essere scritti in minuscolo in XHTML). Così i documenti hanno una resa diversa se analizzati come XHTML.

Uno script basato su DOM scritto per un documento HTML4 ha una semantica leggermente diversa in un contesto XHTML (per esempio i nomi di elemento non sono sensibili alle maiuscole e alle minuscole e vengono restituiti in maiuscolo in HTML4, mentre in XHTML accade il contrario; dovete usare i metodi consapevoli del namespace in XHTML, ma non in HTML4). MA, se inviate i vostri documenti come text/html, allora essi useranno la semantica HTML4 NONOSTANTE siano XHTML! In questo modo è molto probabile che gli script non funzionino se analizzati come XHTML.
Gli script che usano document.write() non funzioneranno nei contesti XHTML. (Dovete usare metodi DOM Core.)
I browser attuali sono, per il contenuto text/html, programmi utente HTML4 (al massimo) e di sicuro non sono programmi utente XHTML. Quindi se voi gli inviate XHTML, gli state inviando del contenuto scritto in un linguaggio che non gli è nativo, e vi affidate alla loro gestione degli errori. Poichè quest'ultima non è definita in nessuna specifica, può variare da un programma utente all'altro.
I documenti XHTML che usano la notazione "/>", come in "<link />" hanno una semantica molto differente se analizzati come HTML4. Se ci fosse un programma utente perfettamente conforme ad HTML4, sarebbe quasi corretto che mostrasse i caratteri ">" sulla pagina.

Per ulteriori dettagli su questo punto si veda la sezione intitolata Il mito dei documenti XHTML 1.0 compatibili con l' HTML.

Copia e incolla

Ho il sospetto che il problema peggiore, e anche il motivo principale, per cui la maggior parte delle pagine XHTML DAVVERO non valide, stia nel fatto che gli autori, che non conoscono l'XHTML, hanno copiato e incollato il loro DOCTYPE da un altro documento. Così anche se voi scrivete XHTML valido, usando XHTML, è probabile che incoraggiate gli autori che non conoscono il modo per scrivere XHTML valido ad affermare invece che lo sanno fare.

Perchè cercare di usare XHTML e inviarlo come text/html è un male

Questi problemi non riguardano tanto gli autori che validano regolarmente le loro pagine, quanto piuttosto gli altri.

I documenti inviati come text/html sono gestiti come zuppa di tag [1] dalla maggior parte dei browser.

Ecco la chiave di tutto: se inviate XHTML come text/html, per quanto i browser se ne preoccupino, gli state solo dando una zuppa di tag. Non importa se il codice è valido, poichè essi lo tratteranno come se fosse vecchio HTML 3.2 o una caotica spazzatura HTML.

Poichè la maggior parte degli autori testano i loro documenti usando uno o due browser, piuttosto che usare un validatore, questo significa che gli autori non testano la validità, e in questo modo la maggior parte dei documenti che dicono di essere XHTML non sono validi.

Si veda, per esempio, questo studio: http://www.goer.org/Journal/2003/Apr/index.html#results ...ma se non ci credete, siate liberi di farne uno vostro. In ogni esempio casuale di documenti che dicono di essere XHTML,

Quindi il vantaggio maggiore di usare XHTML, ossia che gli errori vengono rilevati subito perchè deve essere valido, si perde se il documento viene inviato come text/html. (Si, ho detto la maggior parte degli autori. Se siete tra i pochi autori che comprendono il modo di evitare i problemi illustrati in questo articolo e che validano la loro marcatura, allora questo articolo probabilmente non si applica a voi -- si veda l'Appendice B.)
Se farete passare i vostri presunti documenti XHTML da text/html ad application/xhtml+xml, allora è probabile che troverete molti errori XML, il che vuol dire che il vostro contenuto non sarà leggibile dagli utenti. (Si veda sopra: la maggior parte di questi documenti non passa la validazione.)
Se un utente salva un tale documento text/html su disco e poi lo riapre in locale, causando lo sniffing del tipo di contenuto, dato che i filesystem di solito non includono informazioni sul tipo di file, il documento potrebbe essere riaperto come XML, avendo come risultato potenziale errori di validazione, differenze di parsing o di stile. (Le stesse differenze che avreste se inviaste il file con un MIME type XML.)
L'unico vero vantaggio nell'uso di XHTML piuttosto che di HTML4 è che si possono usare strumenti XML Tuttavia, se vengono usati tali strumenti, essi potrebbero a loro volta produrre HTML4. In alternativa, gli strumenti potrebbero prendere SGML come input invece di XML. (SGML è più vecchio di dieci anni rispetto ad XML, e tali strumenti esistono da anni.)
HTML 4.01 contiene le stesse cose di XHTML 1.0, così vi sono pochi motivi per usare XHTML nel mondo reale. Sembra che il motivo principale sia solo quello di "saltare sul vagone di testa" ed usare l'ultima novità in arrivo.

Il mito dei documenti XHTML 1.0 compatibili con l' HTML

La specifica RFC 2854 fa riferimento a "un profilo d'uso di XHTML compatibile con HTML 4.01". Non esiste una cosa simile. I documenti che seguono le linee guida nell'appendice C non sono documenti HTML 4.01 validi. Si avvicinano soltanto all'essere gestibili come zuppa di tag dai parser, proprio come molte altre pagine web.

Gli esempi più semplici sono:

La sintassi "/>" del tag vuoto ha, de facto, un significato totalmente diverso in HTML4. (È la cartteristica di minimizzazione SHORTTAG conosciuta come NET, se ricordo bene il nome.) Nello specifico, l'XHTML

<p> Hello <br /> World </p>

...è, se interpretato come HTML4, esattamente equivalente a:

<p> Hello <br>&gt World </p>

...e dovrebbe essere reso come:

Hello > World
Gli elementi di script e di stile non possono avere i contenuti nascosti dai vecchi browser. Il seguente XHTML:
```
<style type="text/css">

</style>
```
...è esattamente equivalente al seguente HTML4:
```
<style type="text/css">

     </style>
     
```
...perchè i commenti non sono ignorati nei blocchi <style> di XHTML.
L'attributo xmlns non è valido in HTML4.
I DOCTYPE XHTML non sono validi DOCTYPE HTML4.

Usare XHTML e inviarlo come text/html è lo stesso, da un punto di vista dell'HTML4, che scrivere una zuppa di tag (si veda Perchè i browser non possono trattare l'XHTML dato in text/html come XML below).

Nota: questo viene trattato dal problema HTMLWG XHTML-1.0/6232.

Perchè i browser non possono trattare l'XHTML dato in text/html come XML

I documenti dati come text/html sono trattati come zuppa di tag dalla maggior parte dei browser. Questo significa che gli autori non testano la loro validità, ed in questo modo la maggior parte dei documenti XHTML sul Web non sono validi. Un browser conforme all'XML non sarà in grado di visualizzare quei documenti che ora vengono visualizzati dai browser attuali, e quindi non vi sarà mai una condivisione rilevante del mercato tra di essi.
Non è possibile auto-individuare con sicurezza l'XHTML se dato come text/html. Ecco il motivo per cui i browser non potrebbero trattare i documenti in text/html come XML, anche se non si preoccupassero della lor usabilità (si veda il primo punto di questa sezione).
Non si può fare lo sniffing dei cinque caratteri "<?xml" poichè:
1. L'intestazione <?xml ... ?> è facoltativa secondo l'Appendix C, e si raccomanda di non usarla poichè manda IE6 in modalità quirks.
2. SGML può anche contenere delle PI (si veda l'esempio di seguito). (Un "PI" è un'" istruzione di elaborazione" [Processing Instruction, PI, N.d.T.] un costrutto sintattico che inizia con i due caratteri "<?".)
Non si inizia ad elaborare dal DOCTYPE, in quanto il W3C potrebbe introdurre nuovi DOCTYPE XHTML in futuro, e quindi non sapete quali DOCTYPE cercare. (Per non dire che i DOCTYPE sono facoltativi per i documenti XHTML ben formati, che analizzare un DOCTYPE è difficile, che i DOCTYPE possono essere nascosti nei commenti, e che il DOCTYPE sniffing è stato definito pericoloso da molte figure guida nel W3C e altrove.)

Non si può elaborare dalla stringa "<html xmlns" poichè questa potrebbe essere presente ma nascosta in un commento (ci sarebbe bisogno di un parser XML completo per analizzare i commenti, le PI, i sottoinsiemi interni, ecc).

per esempio, in che linguaggio è scritto questo documento text/html?:

<?xml this is not?>
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0//EN"
[ <!-- SYSTEM "not XHTML" --> ]>
<!-- -- -->
This is a comment. This document is not XHTML.
<html xmlns="http://www.w3.org/1999/xhtml"/>
Ok, I'm done now. -->
<html>
<title> Need a title in HTML4! </title>
<p> This is a valid HTML4 document.
</html>

Anche se riusciste ad individuare l'XHTML, cosa potreste fare con un documento non ben formato (come quello del precedente esempio)? Se ripiegate su HTML4, non vi è alcun vantaggio ad usare un processore XML, e potreste sempre trattarlo come HTML4.
Il Gruppo di Lavoro HTML ha detto che i browser non dovrebbero farlo: http://lists.w3.org/Archives/Public/www-html/2000Sep/0024.html

I vantaggi di XHTML

Se inviato come application/xhtml+xml, l'XHTML ha diversi vantaggi:

Il contenuto XHTML sarà in grado di essere unito e di trovare una corrispondenza con il contenuto di altri namespace conosciuti (in particolare, MathML). Questo è il vantaggio principale per gli autori.
I browsers individueranno subito gli errori nella corretta scrittura.
Gli strumenti che interagiscono con i documenti XHTML garantiscono un documento ben formato.
Il contenuto XHTML può essere analizzato con un parser più semplice di quello usato per una zuppa di tag, e molto più di uno SGML.

Tuttavia, nessuno di questi vantaggi si applica se un documento XHTML viene inviato come text/html, e poichè gli autori sanno che le loro pagine dovrebbero essere leggibili dal browser web più popolare, che non supporta application/xhtml+xml, non c'è alcun motivo per usare XHTML attualmente.

Conclusione

Ci sono pochi vantaggi nell'usare XHTML se lo inviate come text/html e molti svantaggi.

Inoltre, attualmente, la maggioranza (oltre il 90% secondo le statistiche più diffuse) del mercato dei browser non è in grado di rendere il vero contenuto XHTML inviato come text/xml (o altri MIME type XML). Per esempio, andate con IE su:

http://www.mozillaquestquest.com/

Solo Mozilla, i browser basati su Mozilla come Netscape 6 7, e le versioni recenti di Opera e Safari, sono in grado di rendere correttamente questo sito. (IE6 mostra un albero del DOM!)

Gli autori che non vogliono usare i MIME type XML dovrebbero continuare a scrivere HTML 4.01 valido. Quando i programmi utente che supportano XML e XHTML dati con uno dei MIME type XML si saranno diffusi, allora gli autori potranno riconsiderare l'apprendimento e l'uso di XHTML.

(Gli autori esperti dovrebbero vedere l'Appendice B.)

Ulteriori letture

Ho scritto un altro articolo sull'argomento: le persone vogliono che i browser trattino i documenti XHTML dati in text/html come XML e non come zuppa di tag.

http://www.damowmow.com/playground/xhtml-in-uas.xhtml

Henri Sivonen ha scritto un articolo simile domandandosi quale sia l'obiettivo di XHTML. XHTML:

http://www.hut.fi/u/hsivonen/xhtml-the-point

Ci sono molti altri post in merito sulle mailing list, per esempio su www-talk. Il seguente post riassume alcuni problemi sull'uso di text/html per il contenuto XHTML con estensioni XML:

http://lists.w3.org/Archives/Public/www-talk/2001MayJun/0046.html

Alcune persone hanno avuto i problemi citati in questo mio articolo, per esempio:

http://flrant.com/index.php?id=P21

Altri punti interessanti si trovano anche in altri post, per esempio:

> Ma Mozilla usa il suo parser xml per http://www.w3.org/ ?

No. Se lo facesse, renderebbe la pagina senza nessun riferimento esteso ad entità carattere, in quanto Mozilla non è un parser validante e quindi salta il parsing della DTD e non sa cosa sono  , · e ©. Per non dire che finirebbe per ignorare la sezione specifica per la stampa del foglio di stile, la quale usa nomi di elementi in maiuscolo e non troverebbe corrispondenze per gli elementi in minuscolo (riga 138 del primo foglio di stile), e userebbe un colore di sfondo non previsto per la pagina, in quanto il foglio di stile imposta lo sfondo su <body> e non su <html>, il che in XHTML porterebbe ad una resa differente rispetto all'equivalente in HTML4 (stesso foglio di stile, riga 5).

-- http://lists.w3.org/Archives/Public/www-talk/2001MayJun/0004.html

O questo post, vicino alla fine del thread:

Sto ancora cercando un buon motivo per scrivere siti web in XHTML in questo momento, dato che la maggioranza dei browser non supporta XHTML. L'unico motivo che ho trovato (da Dan Connolly [1]) è che rende la gestione del contenuto più semplice con gli strumenti XML... ma sarebbe altrettanto semplice convertire l'XML in zuppa di tag o in HTML prima della pubblicazione, e così non sono sicuro di capirlo. Dato che XML è per la gestione dei contenuti, perchè questo implica che una minoranza di browser devono trattare il documento come XML invece che come zuppa di tag? Qual'è il vantaggio? E dato che chi usa gli strumenti XML spesso gestisce anche i siti, perchè non ci si affida ad una procedura lato server piuttosto che spingere gli autori a spendere le loro già scarse risorse nell'implementazione di uno sniffing del tipo di contenuto?

[1]
http://lists.w3.org/Archives/Public/www-talk/2001MayJun/0031.html

-- http://lists.w3.org/Archives/Public/www-talk/2001JulAug/0005.html

Appendice A: application/xhtml+xml

Si veda: http://ln.hixie.ch/?start=1036767231&count=1

Appendice B: autori esperti

Alcuni autori esperti sono in grado di dare l'XHTML come application/xhtml+xml ai browser che lo supportano, e come text/html ai vecchi browser.

Presupponendo che usiate XHTML 1.0 conforme all'Appendice C (o che avete verificato che l' XHTML 1.0 che inviate è compatibile con i processori da zuppa di tag), allora va bene. Quello che dico è SOLO che inviare l'XHTML come text/html è pericoloso.

Nota: dare l'XHTML 1.1 come text/html non è MAI un bene. Non ci sono specifiche che lo consentono. Dare l' XHTML 2.0 ancora in sviluppo (senza test) non è MAI un bene, in quanto questa specifica non ha ancora raggiunto lo stato di Candidate Reccomendation (CR).

Si noti anche che vorrei suggerire agli autori esperti di non usare XHTML come text/html, in quanto molti autori copiano e incollano la marcatura da altri autori e questo può facilmente portare a copiare XHTML valido ma usarlo come HTML4.

Appendice C: Riconoscimenti

Grazie a Nick Boalch per l'introduzione. Grazie a Dan Connolly per la pignoleria che ha migliorato la qualità dell'articolo. Grazie a Ted Shaneyfelt, Quinn Comendant, per i miglioramenti al testo suggeriti.

Appendice D: Note a piè di pagina

[1] Il termine "trattato come una zuppa di tag" si riferisce al fatto che i browser di solito sono molto permissivi nella loro gestione degli errori, e non supportano nessuna delle caratteristiche "avanzate" di SGML. Per esempio, i browser trattano la stringa "<br/>" come "<br>" e non come " <br>&gt", essendo l'ultima quella che dovrebbe essere secondo HTML4/SGML. Allo stesso modo i browser del mondo reale non hanno problemi a gestire contenuto come "<b> foo <i> bar </b> baz </i>" anche se secondo le specifiche HTML4 non ha senso.