Idee e opinioni

Standard web in subbuglio: arriva Html 5

di Maurizio Boscarol

thumbnail

02

Ago

2007

Dopo anni di lento avvicinamento a xHtml, si profila una rivisitazione di Html 4.01 a cui anche i produttori di browser guardano con interesse. Al botta e risposta di critici ed entusiasti mancava la posizione del W3C: eccola, per bocca di Karl Dubost, coordinatore dell'Html Working Group

Il mondo degli standard web è in subbuglio. Oddio, subbuglio. Tutti si sopravvive benissimo lo stesso, ma c’è (e non capitava da un paio d’anni) un po’ di fermento. Il motivo è semplice: dopo anni in cui il W3C, l’organismo internazionale diretto da Tim Berners Lee e che presiede allo sviluppo dei linguaggi sul web, ci ha ammannito in ogni possibile salsa la fine dell’Html in favore dell’xHtml, con tanto di articoli, corsi, tutorial e roadmap sul futuro del web semantico indissolubilmente legato ai linguaggi della famiglia Xml, improvvisamente tra il 2006 e il 2007 compare all’orizzonte degli sviluppatori una nuova proposta: l’Html 5.

Html 5 nasce come rivisitazione del vecchio Html 4.01, di cui un gruppo indipendente, il Whatwg, composto fra gli altri da sviluppatori legati a diverse case produttrici di browser (Apple, Opera, Mozilla, inizialmente), propone di sviluppare una nuova versione, finalmente riveduta e corretta. In sostanza, di migliorare ed espandere la vecchia specifica in modo che tutti i browser la interpretino allo stesso modo. Inizialmente è sembrata un’iniziativa indipendente, ma a inizio 2007 il W3C ha accettato di aprire un nuovo gruppo di lavoro per continuare lo sviluppo di Html, che era stato chiuso. Html 5 diventerà così una specifica ufficiale del W3C.

Questo ha scatenato le ire dei fautori dell’xHtml 2.0, la nuova versione di xHtml che avrebbe, forse, non si sa, prima o poi, sostituito nei nuovi browser l’xHtml 1.0, cioè il linguaggio di tendenza nel web design attuale. xHtml 1.0 però non è una vera rivoluzione: un po’ perché ha un vocabolario identico a Html 4.01, e un po’ perché viene servito con un mime-type (una tecnicaglia che indica un’informazione che il server manda al browser per dirgli come deve interpretare il documento che sta arrivando) text/html, anziché il più corretto application/xhtml+xml. Questo fa sì che di fatto tutto l’xHtml servito oggi in Rete è in realtà trattato dai browser come Html, facendo così perdere i vantaggi (modularità, motore di parsing più leggero) dell’Xml. La cosa bella è che non si può nemmeno fare molto diversamente, per ragioni troppo lunghe da spiegare qui e che difficilmente vi farebbero fare bella figura con gli amici (a meno che non abbiate amici appartenenti alle Falangi Unite per l’Xml Rivoluzionario, nel qual caso date pure un’occhiata qui, oppure qui e al limite anche qui, perché non tutti sono d’accordo).

Si sono sprecati articoli e polemiche su questa inaspettata via che il W3C ha intrapreso. Chi scrive ha tentato di riassumere i principali punti dell’Html 5 in una paginetta di domande e risposte, che inspiegabilmente è diventata la pagina più vista del sito (figuratevi le altre).

Mancava tuttavia un tassello: che ne pensa veramente il W3C? Come risponde l’ente presieduto dal baronetto che inventò l’Html a critiche e perplessità circa il nuovo linguaggio? E che fine avrebbe fatto la specifica di xHtml 2.0, ancora in via di definizione, e ufficialmente sconfessata dai produttori di browser? Abbiamo pensato allora di chiederlo direttamente a Karl Dubost, che del W3C Html WG è uno dei coordinatori, oltre ad essere co-chair (uno dei responsabili) del QA Interest group. Ecco cosa ci ha molto diplomaticamente risposto.


L’apertura del Working Group del W3C sull’Html 5 ha provocato un big-bang sul web. Ci puoi spiegare perché il W3C ha deciso di dar vita a questo nuovo gruppo?

Il W3C è un’organizzazione che è stata creata per offrire uno spazio per sviluppare e mantenere le discussioni sulle tecnologie web. Una parte dei membri del W3C non erano soddisfatti del modo in cui Html si era evoluto. Quando si sviluppano o si migliorano le tecnologie, bisogna tenere in considerazione l’Ecosistema Web. Ci sono un sacco di documenti sul web che devono essere letti, parsati (anglismo che vuol dire “elaborati da un parser”, cioè da un programma, ndr) e analizzati. Le precedenti specifiche Html non erano abbastanza precise per creare strumenti interoperabili. Il mercato si è evoluto, e dovevamo rispondere a queste necessità.


Un punto che sta creando confusione nella gente è il modo in cui Html 5 guarda all’Xml. La specifica del Whatwg (che è un gruppo autonomo, nato prima del gruppo del W3C, e che è in parte confluito nel nuovo gruppo del W3C, sebbene non si sia sciolto ma continui il suo lavoro parallelamente, ndr) dice che «In generale, gli autori devono essere scoraggiati da tentar di usare XML sul web, perché Xml ha regole sintattiche molto più rigide della variante “HTML5” descritta sopra, ed è relativamente più nuovo e di conseguenza meno maturo». Questo confonde. Ci è stato detto che Xml è il futuro del web, e, a dispetto del fatto che Html 5 coprirà anche una sintassi xHtml 5, le opinioni contro l’Xml sembrano sconcertanti. Ci puoi spiegare questa situazione?

Prima di tutto, la specifica è attualmente ospitata sul sito del W3C. L’ultima versione della bozza di lavoro evolve quotidianamente. In Html 5 c’è più di un modo di scrivere le cose. Le regole di marcatura di Xml sono molto più coerenti. Dunque è più facile scrivere Xml. Ma l’interpretazione di Xml è più rigida. C’è una regola in Xml che stabilisce un “fatal error”. Un elaboratore conforme alle regole Xml deve identificare e riportare all’applicazione ogni errore nel documento. Per un web designer significa dover avere un sito web con codice perfetto e un controllo di qualità prima della pubblicazione. Credo sia una cosa positiva, perché aggiunge qualità ad un livello più alto della filiera.

Il secondo aspetto riguarda le applicazioni (browser, robot indicizzatori eccetera) che non implementano il corretto mime-type per xHtml (application/xhtml+xml). Questo pone un serio problema di usabilità quando un browser non mostra il documento, ma propone, per esempio, di scaricarlo sul proprio computer (il comportamento di default di Internet Explorer con le pagine xHtml servite come application/xhtml+xml, ndr). HTML5 è un linguaggio – un modello, se preferisci – e ci sono due modi di scriverlo (noi la chiamiamo serializzazione), uno in Html e uno in Xml. Così diciamo che: Html5/html dev’essere servito come text/html e Html5/xml dev’essere servito come application/xhtml+xml. Allo stesso tempo, il lavoro di xHtml continua anche con Xforms, Xml Events, xHtml 2.0. È un insieme modulare di tecnologie: xHtml deve essere servito come application/xhtml+xml. Per il lavoro attorno xHtml, segnalo in particolare il documento che spiega le Rich Internet Applications.


Molte lamentele riguardano la mancanza di semantica e il cambio di significato e di utilizzo di alcuni tag o attributi. Non credi che la semantica del vecchio Html 4 dovrebbe semplicemente essere mantenuta e al limite chiarita (come gli attributi delle tabelle, o il tag acronym, e così via), e che il vero punto di forza di Html 5 dovrebbe semplicemente essere quello di introdurre dei nuovi tag e attributi per le web applications e di definire una gestione dell’errore corretta, senza escludere tag esistenti che già sono in opera sulle pagine web?

Il documento sull’Html 5 è una bozza. È addirittura una bozza di redazione (editor draft), per ora. La prima bozza pubblica dovrebbe essere pubblicata nelle raccomandazioni tecniche del W3C entro poche settimane o mesi. La gente la esaminerà, e manderà commenti sul documento che quindi evolverà. Parte della semantica definita in Html 4.01 è davvero minimalista e ha generato un sacco di discussione fra la gente su come dovrebbero usarla. Dunque c’è bisogno di un aggiustamento. Per esempio molte persone si lamentavano che introdurre valori normativi per i nomi di classe sarebbe stato un errore e questo è stato rimosso. Html 5 definisce il modello di parsing dell’Html (per la prima volta in assoluto), il Dom dell’Html, alcune Api e la semantica dell’Html. Direi che il dibattito sulla semantica in realtà non è che all’inizio.


Molta gente crede che ci vorrà troppo tempo per vedere i browser supportare veramente le idee nelle specifiche Html 5. Per non dire di Internet Explorer. Sappiamo anche che Html 5 sarà modulare. Dal tuo punto di vista, quando potremo iniziare a pensar di usare una prima versione della prima parte di Html 5 (e che cosa possiamo aspettarci da Internet Explorer)?

Html 5 sta definendo chiaramente come la maggior parte di Html viene gestito dai browser attualmente. È infatti una descrizione di come Html è compreso dagli attuali browser. Il che significa che per raggiungere l’interoperabilità sono richiesti solo pochi cambiamenti, che sono in corso proprio in questo momento. Anche Microsoft sta partecipando all’Html WG. Sulle nuove funzionalità proposte dalla specifica, ci potrebbe volere del tempo per vederle implementate. Ci sono tuttavia due aspetti. La specifica non è ancora pubblicata nemmeno come primo Working Draft (bozza di lavoro ufficiale). Dunque nessuna funzionalità può essere considerata stabile per il momento. Inoltre, le regole sono cambiate al W3C rispetto a xHtml 1.0. Ora noi stiamo richiedendo una doppia implementazione di ogni funzionalità nella specifica. Non era così quando xHtml 1.0 e Html 4.01 furono rilasciate come Raccomandazioni. Tutte le funzionalità che non avranno un comportamento interoperabile saranno eliminate dalla specifica.


Avete testato come si comportano i browser odierni con le pagine Html 5? Tenteranno di interpretare alcune cose e ignoreranno il resto?

HTML5 è sviluppato prendendo in considerazione che cosa i browser stanno facendo oggi. È un processo inverso. Ciascuno può testare da solo usando il Live Dom Viewer con differenti browser. Prendete un pezzo di codice Htm l. Andate alla seguente Uri con differenti browser: http://software.hixie.ch/utilities/js/live-dom-viewer/. Tagliate e incollate e guardate come il documento viene rappresentato nel browser: la vista Dom.


In Html 5 uno dei più importanti aspetti, da quanto capisco, è la gestione dell’errore di parsing. Credo che uno dei principali problemi dell’Html in origine fu quella di non coprire affatto gli errori di codice, allo stesso modo in cui uno dei problemi per il web “di massa” sia che xHtml richiede una gestione dell’errore draconiana. Per questo una gestione dell’errore standardizzata sarebbe una risposta necessaria e benvenuta. Alcuni, tuttavia, temono che questo possa portare a browser più pesanti e più lenti, a causa di una gestione degli errori troppo complessa. Il mio primo pensiero è che questo non sia veramente un problema, ma mi piacerebbe approfondire questo aspetto con una persona che ha un colloquio quotidiano con i produttori di browser: dobbiamo dunque aspettarci che la gestione dell’errore standardizzato sia davvero un problema, in termini di complessità di programmazione, nei browser futuri? Ci servirà un hardware più potente per far girare quei browser?

I browser fanno già una gestione dell’errore, perché devono mostrare comunque la pagina dal lato utente. Il problema è che non lo fanno nello stesso modo. Così la specifica Html 5 definisce come recuperare dall’errore in un modo unico. Non ha impatto sulla performance (la gestione dell’errore viene già fatta), ma risparmia tempo ai programmatori definendo un meccanismo dell’errore ben codificato, così non devono fare reverse-engineering (o meglio, tirare a indovinare) quello che gli altri fanno.


Html 5 sarà un miglioramento per l’accessibilità? O un peggioramento? O sarà piuttosto neutrale per questo aspetto?

La specifica Html 5 viene sviluppata con l’accessibilità in mente. Il punto riguarda più come l’accessibilità dovrebbe essere gestita. Alcuni partecipanti ai gruppi hanno visioni differenti su come dovrebbe essere fatto. A volte questo crea dei dibattiti accesi. Credo sia normale, è parte di una sana comunità che deve discutere a fondo su questo argomento e interrogarsi su come siamo abituati a fare le cose. Sarà utile se il risultato sarà positivo. La discussione non è finita. È ancora in corso.


Quale relazione esiste fra Html 5 e xHtml 2? I browser dovranno implementare entrambe le specifiche? Vedranno entrambe la luce e verranno usate sul web? E se sì, non credi che questo possa creare confusione?

I produttori di browser (Mozilla, Apple, Opera e Microsoft) finora hanno dichiarato che non avevano interesse a implementare xHtml 2.0. Non significa che questa situazione non possa cambiare. Sostanzialmente, i produttori di browser stanno seguendo il mercato e i suoi bisogni. Se una richiesta massiccia salirà dalla comunità per richiedere xHtml 2.0, allora verrà implementata. xHtml 2.0 usa un insieme di tecnologie diverse da Html 5. Non è la stessa architettura.


Vuoi dire qualcosa che non ti abbiamo chiesto, per aiutarci a capire Html 5?

È un work in progress. Davvero in progress. Abbiamo bisogno di persone nell’Html WG che sviluppino Cms, librerie Html e strumenti autore.