Ecologia dei siti web.net

17 maggio 07

Domande e risposte sull'HTML5

di Maurizio Boscarol

Proviamo a riassumere, in forma di ipotetiche domande e di concrete risposte, la storia dell’ HTML5 fino a questo punto. Se notate errori o imprecisioni, segnalatele pure usando i commenti. Ultimo aggiornamento: 15 giugno 2007.

Cos‘è questa storia dell’HTML5? L’HTML non doveva essere morto con la versione 4.01, nata nel 1999?

Sì. Doveva essere sostituito per sempre da linguaggi basati sull’XML. Poi è successo che alcuni produttori di browser, come Apple, Opera e Mozilla, si sono liberamente riuniti per discutere una nuova possibilità: creare una nuova versione di HTML, chiamata inizialmente Web Application 1.0, ma resa popolare come HTML5. Hanno creato un gruppo chiamato WHATWG, e iniziato a proporre delle specifiche. Qualche tempo dopo il W3C è tornato sui suoi passi, ha raccolto la sfida del WHATWG, e ha messo in piedi un nuovo gruppo di lavoro interno per scrivere una nuova versione di HTML. E così l’HTML è di nuovo in pista, resuscitato dall’oltretomba. Al gruppo del W3C partecipano anche rappresentanti del WHATWG, così non si può parlare di un percorso alternativo, ma piuttosto di una direzione comune.

Cioè, in pratica il W3C ha subito la pressione dei produttori di browser?

E’ possibile vederla anche così. Ma Tim Berners-Lee in persona ha spiegato la scelta. Si tratta di un cambio di strategia, perché alcune specifiche devono essere cambiate per gradi. HTML5 non rinnega la strategia del W3C, secondo Berners-Lee, ma la riformula in un percorso diverso. Più o meno. Poi ognuno può farsi la sua opinione.

E Microsoft? Non sarà mica una mossa di altri produttori, che non verrà mai implementata perché Microsoft non ci sta?

Non dovrebbe. Nel gruppo del W3C ci sono anche rappresentanti della Microsoft. Uno dei coordinatori del gruppo è proprio Chris Wilson, Platform Architect dell’Internet Explorer Platform team alla Microsoft.

Per quale motivo i produttori di browser vogliono un HTML5?

HTML5 propone alcune modifiche all’HTML4, introducendo alcuni elementi non legati al concetto di documento, orientati alla produzione di applicazioni web. In sostanza, nuovi marcatori vengono introdotti per gestire le transazioni via form, elementi interattivi come i menu, la memorizzazione di stati della pagina (fondamentale per tutte le applicazioni del cosiddetto web 2.0), di dati persistenti, e così via. HTML5 in realtà aggiunge modifiche al DOM, alle API, e altre novità interessanti.

Oltre a HTML5, il WHATWG propone Web Forms 2.0, un modo per estendere le funzionalità dei form HTML. Una versione abbastanza matura di questa specifica è stata anche recepita dal W3C.

Se volete approfondire, in un’intervista tradotta anche su questo sito Ian Hickson del WHATWG spiega in prima persona le ragioni per la nascita di HTML5

Sembra ragionevole. Ma perché non proporre queste modifiche in XHTML?

Il WHATWG sostiene che è perché l’HTML è ciò che la maggior parte della gente (e dei siti) usa, dunque è giusto occuparsi di ciò che la gente usa. Poi è probabile che sia anche perché la strada intrapresa con XHTML 2.0 non è piaciuta alla maggior parte dei produttori di browser e degli sviluppatori. Ma HTML5 non abolisce l’uso di XHTML. Infatti la specifica porta avanti parallelamente due linguaggi: HTML5, e il corrispondente XHTML5. Chi vorrà potrà ancora utilizzare XHTML.

HTML5 sarà retrocompatibile con il vecchio HTML?

Sì. Lo scopo del WHATWG non è solo quello di introdurre nuovi elementi, ma è anche quello di produrre una specifica che sia retrocompatibile con tutte le pagine web esistenti. Il WHATWG lo dice chiaramente: HTML5 dovrà essere compatibile con HTML 4.01. Per questa ragione, non si prevede che HTML muoia, ma che, piuttosto, proceda di pari passo con XHTML. Chi ne ha bisogno, potrà usare XHTML, chi non ne ha bisogno, potrà usare una nuova versione di HTML.

Ma questo vuol dire che esisteranno ancora i browser che interpreteranno il tag-soup, quel minestrone di codice non valido che l’xml voleva evitare?

Su questo fronte ci sono le principali novità. La nuova specifica infatti decide di definire in maniera univoca come dovranno essere interpretati gli eventuali errori di codice presenti nelle pagine di HTML5. Dunque il tag soup, o gli errori veniali, verranno opportunamente interpretati secondo un meccanismo finalmente definito a priori di gestione dell’errore.

Che significa? HTML5 non obbligherà le pagine ad essere valide? E l’interoperabilità?

Nessuna specifica obbliga gli autori a fare pagine valide, o conformi alle specifiche. Ciò che le specifiche fanno è stabilire cosa devono fare i browser (e tutti i programmi utente) quando incontrano una pagina non conforme alle specifiche. XHTML prescrive che i browser semplicemente blocchino il parsing. L’utente non riceve neanche un contenuto, nemmeno se l’errore è banale. L’HTML, al contrario, non prescrive nulla, e non dà indicazioni ai browser su come interpretare errori di codice. Nè dice che non devono essere interpretati.

In sostanza, la grande differenza tra HTML e X(HT)ML è che il primo non mette alcuna regola ai browser, il secondo ne mette una drastica. Fra il lasciar che i browser facciano quel che vogliono e bloccare il parsing, ci sarà pure una via di mezzo, no? HTML5 sta tentando proprio questa via di mezzo.

Ma l’interoperabilità non richiede codice ben formato?

Non necessariamente. L’interoperabilità richiede che le cose siano non ambigue. Cioè che gli strumenti possano trarre in maniera predicibile le stesse conclusioni dallo stesso messaggio. L’ideale è che queste conclusioni siano le stesse dell’autore, naturalmente. Ma se l’autore ha commesso errori, è vitale almeno che persone diverse (o programmi diversi) non capiscano cose diverse, come accade ora.

Con XHTML (servito come XML), succede questo: se la pagina è valida, il programma costruisce una struttura non ambigua. Se non è valida, non costruisce nulla. Chiaro, preciso, anche se penalizzante per l’utente in quest’ultimo caso.

HTML invece soffre di eccesso di indeterminatezza, per così dire. Se la pagina è conforme alle specifiche, allora anche in questo caso i programmi costruiscono una struttura non ambigua, come con l’XML. Ma se non è conforme (comunemente viene detto “non è valida”, ma è improprio per l’HTML), allora i browser non è che non fanno niente: tentano di correggere gli errori, tirando ad indovinare. Questo è un bene per l’utente, che almeno qualcosa si vede restituire. Ma è male che ogni browser lo faccia a modo suo. Ma questo avviene perché HTML non ha specificato all’origine un modo corretto di farlo.

E HTML5, invece sì?

Sì. Anzi, potremmo dire che la vera novità di HTML5, al di là dei nuovi elementi che introduce, è quella di correggere il peccato originario di HTML: quello di non aver previsto un meccanismo di correzione degli errori. Un peccato grave, una delle cause (non l’unica) dei problemi di parsing. Per poter competere sul mercato tutti i browser dovevano infatti almeno provare a imitare il modo in cui correggevano l’errore i browser concorrenti. Poi ci hanno messo del loro, facendo anche di testa propria. Il risultato, comuque, è stata una gran confusione. Ora HTML5 introduce nell’algoritmo di parsing delle regole (chiamate parse error) che dicono come si deve comportare il browser in presenza di una specifica tipologia di errore. Il risultato è sempre univoco, e non blocca il parsing.

Questo, di fatto, elimina il problema di HTML, e lo rende anche più interessante rispetto all’XHTML. Infatti, se in futuro ci saranno delle pagine senza errori, sia in HTML5 che in XHTML5 daranno vita alla medesima struttura di dati, non ambigua.

Se invece le pagine presenteranno errori, in HTML5 tutti i browser ricostruiranno comunque la medesima struttura di dati, senza ambiguità. Ma in XHTML5, coerentemente con le specifiche XML, il parser si bloccherà.

Questo darà un evidente vantaggio a HTML5 su XHTML5 per quanto riguarda gli usi comuni sul web, perché gli utenti non rischieranno di trovarsi davanti un messaggio di errore.

Questo meccanismo di correzione dell’errore non porterà a parser (cioè a browser) molto più complessi e pesanti? E non dovranno quindi girare su macchine molto più potenti?

Pericolo inesistente, per diverse ragioni:

1. E’ vero che i parser XML, non dovendo correggere l’errore (e dunque bloccandosi in presenza di errori), sono più leggeri e più rapidi dei parser HTML. Quel che di solito non si dice però è che questa differenza è mediamente piccola, specie se rapportata ai normali ritardi dovuti alla connessione, anche con banda larga. Comunque non è tale da risultare sensibile o significativa per gli utenti.
2. In ogni caso non è vero che i nuovi browser saranno più lenti degli attuali, perché i nostri browser implementano già ora una correzione dell’errore. Solo che adesso ognuno la fa a modo suo. In futuro tutti dovrebbero farla nello stesso modo, con evidente vantaggio per tutti. Non si tratterà dunque di una nuova funzione, ma del miglioramento di una funzione già presente nei browser.
3. Circa la potenza dei computer, be’, questa è una strana obiezione, visto che attualmente sui nostri computer i browser sono fra i programmi più semplici e che richiedono meno risorse. Pensate a videogiochi, programmi di editing 3d, ecc. E persino per i dispositivi portatili, dotati di minori risorse, il problema è relativo. In futuro lo sarà sempre più, perché i browser non diventeranno significativamente più complessi (almeno non a causa del motore di parsing), mentre l’hardware dei computer segue la legge di Moore e dunque ridurrà i prezzi a parità di potenza o aumenterà la potenza a parità di prezzo, come è sempre accaduto.

Non capisco: se HTML5 stabilisce regole di parsing non ambigue anche in presenza di errori di codice, perché non può trarne vantaggio anche XHTML5, che è equivalente?

Perché questo andrebbe contro le specifiche di XML.

Ma HTML5 e XHTML5 non sono parte della medesima specifica?

Sì, ma è una specifica che definisce due linguaggi diversi. Viene anzi chiarito che anche i parser non potranno essere gli stessi. XHTML5 continuerà a venir parsato dagli strumenti nati per XML. I quali però non saranno adeguati a parsare l’equivalente pagina in HTML5.

E viceversa.

HTML5 e XHTML5 useranno insomma due algoritmi di parsing differenti, e strumenti differenti (anche se entrambi possono essere implementati nello stesso browser).

A rigore, HTML5 non fa nemmeno più parte della famiglia di linguaggi SGML. Il nome trae in inganno, ma per introdurre tutti questi nuovi concetti, i collaboratori del WHATWG hanno deciso di scrivere un linguaggio nuovo, con regole nuove, uscendo dai limiti imposti da SGML.

Che confusione: era proprio necessario?

Visto che XHTML non ha funzionato sul web, probabilmente sì.

Perché XHTML non avrebbe funzionato sul web? Un sacco di siti lo usano.

No, usano HTML con un doctype XHTML. Ma i browser continuano ad interpretarlo come HTML. La maggior parte di essi inoltre non è valida, e se fosse interpretata come XML non verrebbe visualizzata.

Sono passati almeno 6 anni da quando si è iniziato a suggerire questa transizione verso XML, e i passi avanti sono quasi nulli. Non è pensabile che questo cambi nei prossimi anni. Di conseguenza, forse la rigidità di XHTML semplicemente non si addice alle esigenze del web. Magari si addice ad altri scopi, ma non allo stato attuale del web.

E RSS, allora?

Anche RSS, Atom e tutti i feed hanno problemi, e in genere non vengono parsati correttamente, cioè nel pieno rispetto delle specifiche. Questo lo aveva già segnalato Mark Pilgrim in un vecchio illuminante articolo del 2004. Le cose non sono cambiate moltissimo. Ad ogni modo, niente vieta che i medesimi dati, opportunamente trattati dai CMS, possano dar vita a pagine HTML5 e a documenti XML. Con un qualunque linguaggio di programmazione lato server, la conversione è triviale, se serve.

E il web semantico?

Il web semantico è un’altra storia. Prima di tutto, non è chiaro se e quando le premesse del web semantico si realizzeranno. Secondo, non si sa nemmeno come si realizzeranno.

Certo, se il web semantico si baserà sull’XML, che vuole solo pagine valide e riccamente marcate, allora avere un HTML5 non sembra un gran passo avanti. Anche se in realtà niente vieta, tramite apposite routine, di trasformare dati HTML univocamente decodificati in dati XML.

Ma al momento non vi sono convincenti usi e applicazioni di web semantico in contesti web reali che si basino su XML. Esistono diversi dubbi anche sulle ontologie, come ricordavamo in passato. Il futuro del web semantico potrebbe anche prendere direzioni diverse da quelle originariamente immaginate. Ma al momento, sui suoi concetti e sulla tecnologia che userà, ci sono moltissime incognite.

Il fatto che esisterà un XHTML5, comunque, lascia aperta anche la possibilità di un web semantico basato su XML.

L’accessibilità trarrà danno o beneficio dall’HTML5?

Beneficio, se non altro perché ogni elemento potrà essere univocamente dedotto dal codice. Che è ciò che serve ai programmi utente. Naturalmente, se la marcatura ha scarso valore semantico, i problemi per gli utenti rimangono. Ma questo è un problema culturale, non di validità.

Ma quando verrà supportato HTML5? E le vecchie pagine ora esistenti?

HTML5 viene sviluppato in maniera modulare. Alcune parti sono più mature, altre meno. Gli autori prevedono che lo sviluppo completo occuperà i prossimi 15 anni, dunque hanno preso le cose seriamente… Attualmente, alcuni browser già interpretano parti della specifica, anche se pare non correttamente. In realtà, trasformare pagine HTML in HTML5 sarà facile: grazie al fatto che HTML5 è retrocompatibile, basterà cambiare il doctype.

Inoltre, una cosa poco nota di HTML5 è che i browser che si dichiareranno compatibili con HTML5 dovranno interpretare tutti i linguaggi serviti con il mime-type text/html come HTML5. Niente più supporto per i vecchi formati: verranno tutti interpretati come versioni, magari bacate, della specifica più recente. Niente più quirk e standard mode. L’algoritmo di parsing dell’HTML si farà carico di offrire un’interpretazione univoca alle vecchie pagine.

Questo meccanismo consente di supporre che in effetti HTML5 avrà un ruolo di rilievo nel web del futuro. Forse più importante di quello finora assunto da XHTML.

Non è che domani mattina, o fra tre anni, se ne esce un nuovo gruppo con un nuovo linguaggio?

E’ possibile, visto che in realtà la lista del W3C in cui si discute dell’HTML è abbastanza litigiosa e suoi membri non sembrano d’accordo su nulla. Ma è meglio non augurarselo, perché di una lingua veramente franca sul web c‘è un gran bisogno.

Sezione: blog - Argomenti: (x)html, web semantico |