HTML, XHTML, HTML 5: miti e leggende metropolitane

Io ne ho viste cose che voi umani non potreste immaginarvi. Navi da combattimento in fiamme al largo dei bastioni di Orione, E ho visto i raggi B balenare nel buio vicino alle porte di Tannhäuser. E tutti quei momenti andranno perduti nel tempo… come lacrime nella pioggia. È tempo…di morire. (Blade Runner)

Premessa a posteriori: sembra che questo argomento riceva una certa attenzione, stando alle statistiche di accesso, voglio quindi spiegare molto chiaramente cosa penso dell’argomento HTML5: credo che qualsiasi articolo, dibattito, previsione del futuro non meriti più di un commento “da bar”. È del tutto inutile e autocelebrativo predisporre FAQ o rivelare quello che nessuno sa, nemmeno il W3C, ovvero se, quando e in che forma questo progetto andrà in porto. Mi interesserà certo molto di più quando ci sarà qualcosa di concreto. Per ora il gruppo di lavoro sembra più impegnato a discutere fra sé e sé che a produrre qualcosa di utile, anzi stan facendo danni. Per essere chiari: l’argomento HTML 5 oggi per me è interessante quanto l’uscita della nuova versione di Paintbrush… Ok, magari sarà anche innovativo, ma quando verrà si vedrà se serve a qualcosa o meno, niente di più.

Ok, la citazione è esagerata, ma periodicamente si assiste a un riaprirsi di dibattiti su come realizzare le proprie pagine Web, e francamente molte volte si sentono dire delle cose che non stanno né in cielo né in terra.

Ultimamente sembra che “siccome il futuro è HTML5 allora faccio le mie pagine in HTML4“, o strane discussioni sul fatto che “siccome la mia pagina XHTML viene servita con content type text/html allora non è in XHTML“. Tanto per iniziare, quale XHTML? È fondamentale distinguere, XHTML 1.0 è una cosa diversa da XHTML 1.1.

Per continuare, HTML5 sostituirà, fra dieci anni, sia HTML4 sia XHTML 1.0 di cui è il legittimo successore e meno male, le braghette di HTML4 sono diventate davvero troppo strette (This specification is intended to replace (be the new version of) what was previously the HTML4, XHTML 1.0, and DOM2 HTML specifications). Inoltre, XHTML2 (il successore di XHTML 1.1) non mi risulta che sia stato ucciso da una qualche strana setta, e il gruppo di lavoro sta lavorando alacremente per recuperare il tempo perso.

Poi si leggono cose decisamente balzane, sembra quasi che HTML5 decreti la fine di XHTML, una specie di HTML4 redivivo che uccide XHMTL… Mi chiedo se queste persone si siano mai prese la briga di guardare almeno le specifiche. HTML5 è una cosa completamente diversa sia da HTML4 sia da XHTML1.0, e li rimpiazzerà tutti e due c’è scritto alla seconda riga delle specifiche. Se uccide qualcosa, uccide anche HTML4…

Un documento HTML5 non viene definito in termini sintattici, come HTML e XHTML, ma in termini di DOM, la rappresentazione ad albero utilizzata dai browser per riprodurre i documenti.

I validatori di HTML5 non si basano su DTD, ma sul concetto di conformità: “The fundamental idea underlying the text/html support of the conformance checker is that HTML5 can be treated as an alternative infoset serialization for a subset of possible XML infosets [Infoset]. An HTML parser can appear to the XML tooling as an XML parser parsing XHTML“).

Questo è il tree del documento:

tree di un documento html5

Questo è il documento in HTML 5:

<!DOCTYPE html>
<html>
<head>
<title>An HTML Document</title>
</head>
<body>
<h1>Example</h1>
<p>This is an example HTML document.
</body>
</html>

E questo in XHTML5:

<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>An HTML Document</title>
</head>
<body>
<h1>Example</h1>
<p>This is an example HTML document.</p>
</body>
</html>

Se il documento viene servito con content type text/html e ha il doctype, si chiama HTML5. Se con content type application/xml+xhtml si chiama XHTML5.
Se le cose stanno così, con che criterio c’è chi afferma “torno a HTML4 perché il futuro è HTML“? Quale è il senso? A me ricorda tanto Tafazzi, avete presente?

Di solito il sapiente di turno enuncia l’editto: non lo sai che Internet Explorer non gestisce il content type application/xml+xhtml e che XHTML servito come text/html ha zero vantaggi rispetto a xhtml?

La prima parte è vera ( e sarebbe bello conoscere il perché di questa decisione di Microsoft), la seconda no.

XHTML possiede diversi vantaggi, indipendentemente dal mime type utilizzato. C’è questa leggenda metropolitana che XHTML deve essere servito con mime type application/xhtml+xml. Non è per niente vero, basterebbe anche qui leggere le specifiche: di che XHTML stiamo parlando? Se di XHTML 1.0, va benissimo servire le pagine XHTML come text/html, così come è legittimo omettere la dichiarazione XML Quindi, che significato hanno le dichiarazioni “ah, ma se metto la XML declaration Explorer va in Quirk”?

Dove sta scritto che è obbligatorio usarla? Le specifiche dicono l’esatto contrario, sono pochi i documenti che la richiedono, anche se ne viene incoraggiato l’uso.

Il documento è quello che avete deciso che sia scegliendo una DTD, indipendentemente da quello che dice il mime type. Potreste servire il documento XHTML con mime image/jpg, questo non significa che quel documento diventerà un’immagine jpeg, non confondiamo una semplice etichetta con il contenuto.

Analogamente, servire il documento in text/html non significa che questo non sia più un documento XHTML. Sarà né più né meno quello che avete deciso che sia dichiarando un doctype.

Il media type in alcune circostanze può essere una utile indicazione per chi fruisce della pagina, ma non controlla questa scelta in alcun modo.

Questa leggenda metropolitana è stata promulgata dagli zeloti ^X^HTML, come molti stanno notando, per impedire a tutti i costi e a chiunque l’uso di XHTML. Cercano di distruggere gli standard insistendo su una presunta e insensata conformità agli stessi con rocambolesche e funamboliche “seghe mentali” su improbabili evenienze a base di colpi di / tristi comportamenti non dimostrati dei parser, correndo poi a dire “ma no, non hai capito, io parlavo soltanto con chi le pagine Web non le sa fare” (che tristezza…), nonostante l’esperienza pratica di chiunque abbia mai sviluppato una pagina Web dica il contrario. Vi è mai capitato che un vostro utente si lamentasse della vostra pagina XHTML? Che sia venuto sotto casa vostra dandovi del “harmful“? Semmai si lamenterà di come l’avete realizzata, ma non del suo doctype.

Il massimo vantaggio a costi minimi. Ecco cosa permette XHTML. Servire XHTML ben formato come text/html oltre a essere una pratica del tutto conforme agli standard XHTML 1.0 è un’azione solida e pragmatica, che garantisce vantaggi reali agli autori e non impone alcuna spesa agli utenti, a cui giustamente non può fregare di meno del mime type.

Ecco di seguito soltanto alcuni dei vantaggi che si ottengono creando pagine xhtml 1.0, compatibili appendice C, servite come text/html, ovviamente valide e se possibile Strict (sennò che ne parliamo a fare?).

  • Razionale compatibilità all’indietro: i siti possono essere realizzati per essere ben visualizzati anche con browser sorpassati, pur presentando una migliore visualizzazione con browser moderni e conformi agli standard.
  • Compatibilità in avanti: i siti continueranno a funzionare con tutti i futuri browser e user agent.
  • Si può iniziare a preparare la strada per l’eventuale transizione a un codice interamente XML e a layout realizzati con CSS.
  • XHTML è lo standard corrente, non HTML.
  • XHTML è più coerente di HTML, quindi è meno probabile la presenza di errori di visualizzazione.
  • XHTML 1.0 è un ponte per le future versioni di XHTML, e anche di XHTML5. Succeda quel che succeda, sarà più facile l’eventuale adattamento da XHTML che da HTML.
  • I vecchi browser sono perfettamente a loro agio sia con XHTML sia con HTML. Non è un vantaggio, ma nemmeno uno svantaggio.
  • I nuovi browser adorano XHTML, specialemente la versione 1.0, trattamento speciale non garantito alle pagine HTML. Per esempio, Firefox e Explorer rendono i layout CSS in modo più accurato se il doctype è XHTML.
  • XHTML funziona bene sia in browser desktop sia su periferiche particolari come palmari, screen reader e altri user agent, eliminando in molti casi la necessità di creare specifiche versioni di markup. Il rapporto causa-effetto non è così automatico, ma è certo che molti siti HTML sono ingombri di versioni wireless, solo testo e pagine printer-friendly. Al contrario, molti siti XHTML sono privi di queste ridondanze (e costi).
  • XHTML fa parte della famiglia degli standard Web, inclusi CSS e DOM, e permette di controllare il comportamento delle pagine Web su più piattaforme, browser e dispositivi.
  • Sviluppare in XHTML può aiutarci ad abbandonare l’abitudine di scrivere codice di markup presentazionale, evitandoci allo stesso tempo problemi di accessibilità e incoerenze di visualizzazione fra diversi browser.

Mi sembra inutile continuare, e a questo punto consiglio la lettura di un libro secondo me fondamentale, Progettare siti Web standard di Jeffrey Zeldman, seconda edizione.

In tutto questo, HTML5 non c’entra proprio niente… magari ne riparleremo più avanti. In ogni caso, da specifiche:

1.4 HTML vs XHTML

[...]The first such concrete syntax is “HTML5″. This is the format recommended for most authors. It is compatible with all legacy Web browsers. If a document is transmitted with the MIME type text/html, then it will be processed as an “HTML5″ document by Web browsers.

The second concrete syntax uses XML, and is known as “XHTML5″. When a document is transmitted with an XML MIME type, such as application/xhtml+xml, then it is processed by an XML processor by Web browsers, and treated as an “XHTML5″ document. Authors are reminded that the processing for XML and HTML differs; in particular, even minor syntax errors will prevent an XML document from being rendered fully, whereas they would be ignored in the “HTML5″ syntax.

Fine della questione… se lo servite come text/html si chiama HTML5, se usate application/xhtml+xml si chiama XHTML5.

Ma dire uso HTML perché questo è il futuro, francamente è davvero una grossa sciocchezza.

Approfondimenti:
Using the HTML5 doctype prematurely “considered harmful” e un divertente scritto di Eric Meyer, why “considered harmful” can be considered harmful by itself.

9 pensieri su “HTML, XHTML, HTML 5: miti e leggende metropolitane”

  1. “Potreste servire il documento XHTML con mime image/jpg, questo non significa che quel documento diventerà un’immagine jpeg, non confondiamo una semplice etichetta con il contenuto.

    Analogamente, servire il documento in text/html non significa che questo non sia più un documento XHTML. Sarà né più né meno quello che avete deciso che sia dichiarando un doctype.

    Il media type in alcune circostanze può essere una utile indicazione per chi fruisce della pagina, *ma non controlla questa scelta in alcun modo*.”
    Invece succede esattamente il contrario: i browser decidono come parsare la pagina non in base al doctype (come in teoria dovrebbero fare) ma in base al content-type quindi, anche se il documento è effettivamente una pagina XHTML, se servita con content-type text/html verrà parsata con un parser HTML che non sarà quindi in grado di riconoscere il / nei tag come o alcuni attributi come xml:lang. Se il parser scelto dipendesse effettivamente dal doctype non ci sarebbe nessuna differenza tra un documento servito come text/html e uno servito come application/xhtml+xml (e credo che il browser proverebbe ad aprirlo come immagine se fosse servito come image/jpeg).

    Analogamente Firefox apre tranquillamente un sorgente python (*.py) servito come text/html ma ti chiede di salvarlo se servito come application/python, anche se è un semplice file di testo.

    Detto questo è bene precisare che io non sono contrario a XHTML in sé, ma all’uso scorretto che se ne fa. Hai parlato di “massimo vantaggio a costi minimi” e di “un’azione solida e pragmatica, che garantisce vantaggi reali agli autori e non impone alcuna spesa agli utenti, a cui giustamente non può fregare di meno del mime type”. Sul fatto che agli utenti non gliene frega niente sono d’accordo, d’altronde visitano quotidianamente siti fatti con Word senza neanche rendersene conto. Per quanto riguarda i vantaggi di cui parli non ne vedo nemmeno uno. Il principale vantaggio di XHTML è l’estensibilità (da qui la “X” nel nome) che funziona *solo* se il documento è servito come application/xhtml+xml. Quindi ora puoi scegliere di usare XHTML, estenderlo, servirlo come application e subirti tutte le conseguenze che ne conseguono (IE non lo apre, problemi minori con altri browser) oppure non estenderlo, usare *le stesse identiche cose* che hai in HTML4 (che è pure supportato meglio dai vari browser e quindi crea meno problemi e costi per risolverli) e servirlo come text/html.

    Per riassumere: i broswer (non tutti almeno) non supportano ancora bene XHTML, quindi chi sceglie di usarlo è costretto a inviare un documento XHTML dicendo al browser che è HTML e consapevole del fatto che verrà parsato con un parser HTML e che tutte le cose che XHTML introduce non potranno essere usate (oppure metterle sapendo che il parser le ignorerà). Oppure uno può scegliere di usare HTML4 che *è* HTML, viene parsato con un parser HTML e non ha “intrusi” (come o xml:lang).
    C’è anche da dire che HTML permette di scrivere codice “peggiore”, ma questo non vuol dire assolutamente che non sia possibile scrivere codice valido e ordinato, come d’altronde è possibilissimo scrivere tag soup in XHTML (tanto finché viene servito come text/html non ci sono conseguenze).

  2. >Invece succede esattamente il contrario: i browser >decidono come parsare la pagina non in base al doctype (come in teoria dovrebbero fare) ma in base al >content-type quindi, anche se il documento è

    No, non è così. Prova a caricare con IE la pagina a http://www.tiuvizeta.it/default.xml.
    E’ una pagina xml con content type application/xhtml+xml. IE ci metterà un po’ ma la carica correttamente.
    Per Firefox ovviamente nessun problema.
    Se il provider non cofigura i mime, o si rifiuta di farlo, certo ci sono ulteriori problemi, ma esulano da questa discussione.

    >che non sarà quindi in grado di riconoscere il / nei tag >come o alcuni attributi come xml:lang. Se il parser

    Non è vero nemmeno questo, se stiamo parlando di xhtml 1.0.

    >parlato di “massimo vantaggio a costi minimi” e di >“un’azione solida e pragmatica, che garantisce vantaggi >riguarda i vantaggi di cui parli non ne vedo nemmeno >uno. Il principale vantaggio di XHTML è l’estensibilità

    Che gli elementi di html e xhtml 1.0 siano gli stessi, non ci piove. I vantaggi sono per lo sviluppatore, che può senza dubbio scrivere del codice più pulito e maneggevole.
    Trovo un po’ ridicolo dichiarare il doctype html e scrivere il codice in xhtml come fa Meyer, per esempio.
    Ma saran ben affari suoi :-). Per me, è fighettismo, niente di più.

    >supportano ancora bene XHTML, quindi chi sceglie di >usarlo è costretto a inviare un documento XHTML dicendo

    Occorre distinguere bene: XHTML 1.0 è DIVERSO da XHTML 1.1 in sù. Quello che dici vale senza dubbio per XHTML 1.1, ma non per XHTML 1.0 (non lo dico io, lo dicono le specifiche e anche Hixie, benché l’abbia aggiunto in stile codicillo dei contratti di assicurazione nelle note del suo advocacy.

    >C’è anche da dire che HTML permette di scrivere codice >“peggiore”, ma questo non vuol dire assolutamente che

    No, certamente. La differenza è che in xhtml almeno chiudi gli elementi…

  3. > No, non è così. Prova a caricare con IE la pagina a http://www.tiuvizeta.it/default.xml.
    > E’ una pagina xml con content type application/xhtml+xml. IE ci metterà un po’ ma la carica correttamente.
    Se faccio View Page Info da firefox mi dà text/xml, non application/xhtml+xml, è se IE è in grado di parsare il primo, non è altrettanto vero per il secondo.
    Se guardi questa pagina http://wolfprojects.altervista.org/beware/examples/1.php?type=xhtml puoi vedere la differenza che c’è inviandola come application/xhtml+xml (su firefox viene mostrato un errore e non viene aperta perché non è well-formed, su IE invece chiede di salvarla) oppure come text/html (funziona bene su entrambi).
    Puoi scegliere il content-type cambiando l’URL e mettendo type=html o type=xhtml, c’è uno script PHP che semplicemente invia il content-type scelto tra i due con un header, inoltre cambiando il numero della pagina (da 1.php a 10.php) ci sono diversi esempi e ognuno si comporta in maniera diversa semplicemente cambiando il content-type (il codice XHTML è lo stesso).

    > Non è vero nemmeno questo, se stiamo parlando di xhtml 1.0.
    Se apri una pagina in XHTML inviata come text/html e fai View Page Source da Firefox vedrai tutti i / in tag come BR segnati in rosso, perché il parser HTML non li riconosce, se la stessa pagina invece è inviata come application/xml+xhtml sono in nero, perché per quello XHTML sono validi. Puoi vederlo su 2.php?type=html (dove il / nei tag svg:circle è rosso) e su 2.php?type=xhtml (dove è nero, inoltre qua svg e mathml funzionano perché la pagina è stata servita con il content type corretto e parsata con il parser adatto).
    Per quanto riguarda xml:lang non ho nessun esempio pronto, ma come per ogni altro attributo che non fa parte delle specifiche HTML (perché con text/html viene parsato come HTML) dovrebbe essere semplicemente ignorato.
    Ci sarebbe anche da dire che il / in HTML è usato per i NET (Null End Tags) quindi <br/> è una sintassi abbreviata valida in HTML che corrisponde a <br>> e se il browser non mostra il > di troppo è solo perché questa sintassi non è supportata volutamente dai principali browser.

    > Che gli elementi di html e xhtml 1.0 siano gli stessi, non ci piove. I vantaggi sono per lo sviluppatore, che può senza dubbio scrivere del codice più pulito e maneggevole.
    È ben perché i tag son gli stessi se non c’è alcuna differenza (tranne alcuni casi come i BR – vedi fine del commento): quello che puoi scrivere in XHTML lo puoi scrivere anche in HTML. Come ho già fatto notare in HTML puoi anche aprire un LI o un P senza chiuderlo e la pagina rimane valida, ma non è il fatto di *poterli* lasciare aperti che ti permette di scrivere codice migliore in XHTML. Io chiudo tutti i LI e tutti i P anche in HTML e il mio codice è ordinato come un qualsiasi altro codice scritto in XHTML ordinato. Quindi XHTML non aggiunge cose “nuove” che permettono un ordine maggiore, ma semplicemente vieta cose che porterebbero a un disordine maggiore. Chi si preoccupa di validare e di scrivere codice ordinato non ha bisogno di questi “divieti”, al contrario chi non si preoccupa scrive la stessa tag soup anche in XHTML.

    >Occorre distinguere bene: XHTML 1.0 è DIVERSO da XHTML 1.1 in sù.
    In XHTML 1.0 il text/html è tollerato perché deve essere un “passaggio intermedio” per migrare da HTML a XHTML 1.1 e quindi mantiene una certa retro-compatibilità, ma i motivi di questa scelta non sono certo tecnici, se invii una pagina XHTML 1.1 come text/html il browser riesce a parsarla senza problemi (ovviamente senza mostrare tutte le “estensioni” tipo SVG, ma lo stesso accade anche con XHTML 1.0). Se da XHTML 1.1 non è più possibile (così come non è più possibile usare doctype transitional e frameset) è perché chi doveva “convertirsi” ha avuto il tempo di farlo con XHTML 1.0 e quindi tutte queste cose “scorrette” che prima erano tollerate ora non lo sono più.

    > La differenza è che in xhtml almeno chiudi gli elementi…
    Questo non deve essere per forza una cosa buona. Sono completamente d’accordo che chiudere gli elementi che hanno un contenuto (P, LI, DIV, ecc) sia cosa buona e giusta, ma IMHO non ha senso farlo con elementi come BR, HR, IMG ecc. Scrivere <br /> equivale a <br></br> che sarebbe come dire “qui inizia un line break” “qui finisce il line break”, quando il line break è semplicemente un singolo carattere, che non può avere né un inizio né una fine (né tanto meno un contenuto). Questi tag fanno solo da “segnaposto” senza marcare nessun contenuto. A tal proposito ti segnalo anche l’articolo di Jukka Korpela “Empty elements in SGML, HTML, XML, and XHTML” (http://www.cs.tut.fi/~jkorpela/html/empty.html), che addirittura sostiene che in un linguaggio di markup come (X)HTML questi tag non dovrebbero esistere, appunto perché non marcano niente.

    (Spero che i vari tag che ho usato negli esempi e i link si vedano correttamente, perché nel post precedente sono stati cancellati.)

  4. > Se faccio View Page Info da firefox mi dà text/xml, non application/xhtml+xml

    Accidenti, hai ragione. e’ una cosa di anni fa e si vede che nel frattempo il provider ha cambiato associazioni.
    Non sto a rifarlo, è una cosa che si sa fin dal 2004 e IE funziona anche con application/xhtml+xml, senza sniffing.
    (http://dean.edwards.name/my/application_xml.html, guarda i response header)
    E’ da usare? no, non lo è, ovviamente.
    Tutto il resto francamente non mi interessa, son cavilli poco significativi e piuttosto aleatori, senza alcuna influenza sulla resa della pagina. Stiamo parlando di xhtml 1.0, non 1.1. E’ questo che si dimentica sempre.
    Per me, come già detto, il discorso è: non c’è niente di male a creare pagine xhtml 1.0 e a inviarle ai browser come text/html, è del tutto lecito e non fa alcun male a nessuno.
    Per altre informazioni, leggi anche http://h3h.net/2005/12/xhtml-harmful-to-feelings/, se non l’hai già fatto perché ho visto che hai fatto un ottimo lavoro sul tuo sito.
    Inoltre, se chi crea la pagina è esperto e si cura di validarla, per me la può fare anche in HTML 3.2.
    Per i motivi per cui è preferibile usare xhtml invece di html, farò un’aggiunta al post, che così in effetti sembra un’affermazione perentoria e campata in aria.

  5. diceva Obert, che ho fatto un restore ed è sparito il commento:
    una specie di HTML redivivo che uccide XHMTL

    dicevo io: sai che non ho capito?

  6. livio, cancellali pure questi commenti, ti informavo soltanto che c’e’ un errore di battitura: HTML redivivo che uccide XHMTL — XHTML non XHMTL. saluti.

Lascia un Commento

L'indirizzo email non verrà pubblicato. I campi obbligatori sono contrassegnati *

È possibile utilizzare questi tag ed attributi XHTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>