Ecologia dei siti web.net

28 giugno 07

Traduzione dell'intervista di Vlad Alexander a Ian Hickson sull'HTML 5

di Maurizio Boscarol

Vlad Alexander, già autore di X-Standard e responsabile del sito XHTML.com ha fatto un’intervista a Ian Hickson del WHTAGWG a proposito di HTML5. Giudicando l’intervista molto buona sia per la qualità delle domande che per la chiarezza esemplare delle risposte, ho pensato di impiegare un paio d’ore del mio tempo per tradurla in italiano.

La versione completa è già online sul sito di Vlad. Per comodità (e per la possibilità di commentare) ne riporto qui una buona parte, ovvero i passaggi secondo me più significativi.

L’intervista chiarisce credo abbastanza bene perché HTML5 è nato. Sul sito XHTML.com segnalo anche un’intervista parallela a Steve Pemberton sull’XHTML2, già tradotta, in quel caso, in italiano, da Pasquale Popolizio. Così potete comparare gli interventi e farvi un’idea più precisa dei rispettivi scopi dei due linguaggi. Buona lettura.

I passi più significativi dell’intervista

Perché abbiamo bisogno di X/HTML5? E quando è diventato chiaro questo bisogno?

HTML è nato come un lnguaggio di descrizione di documenti per consentire agli scienziati di condividere il loro lavoro. Si è evoluto nel tempo; per esempio, l’elemento img e i form sono stati aggiunti, sono state aggiunte alcune possibilità di formattazione WYSIWYG e poi rimosse a favore dei CSS, e così via. Negli anni più recenti il web si è nuovamente evoluto, raggiungendo uno stato più dinamico di quanto non avesse in precedenza (gli eruditi lo chiamano WEB 2.0). Lo sforzo di HTML5 è di mantenere e far evolvere HTML per soddisfare i bisogni degli autori web del 21esimo secolo.

X/HTML 5 presenta nuovi costrutti di marcatura come gli elementi di divisione in sezioni, miglioramenti dell’elemento input, un costrutto per i dialoghi, un modo per marcare le immagini, e molto altro. Puoi descrivere brevemente questi nuovi costrutti e la ragione per cui sono stati aggiunti?

Stiamo tentando di usare un processo molto più scientifico nello sviluppo di HTML5 rispetto a quanto normalmente si faccia per le nuove specifiche. Così, per esempio, molti dei nuovi elementi per la divisione in sezioni (ad esempio per marcare i blocchi di navigazione, gli articoli, le sezioni, i piè di pagina, le testate, e così via) si sono basati su uno studio di molti miliardi di documenti svolto da Google, dove abbiamo visto che questi erano gli elementi di divisione più usati dagli autori.

Qualche altra caratteristica, come la funzione di foglio di stile limitato, che consente all’elemento style di essere inserito nel documento stesso assieme al contenuto, in modo che solo lo stile di quel contenuto venga influenzato, è stato aggiunto in base al feedback degli autori.

Una delle altre nuove possibilità nella bozza è datagrid, che è un controllo per viste ad albero/viste ad elenco con un supporto incorporato per dati gestiti da AJAX, in modo che si possa fare qualcosa tipo la tipica vista stile webmail, con tutte le decine di miglialia di mail che si hanno, ma invece di mostrarne solo 20 alla volta, si possono scrollare tutte, senza doverle scaricare fino a che non sono richieste.

Abbiamo anche un’API di immagazzinamento lato-client (già implementata in Firefox, credo), indicatori di stato di offline che consentono di scrivere applicazioni che possono capire quando ci si sta disconnettendo, API per il drag-and-drop compatibile con quelle implementate da Explorer e Safari, varie API di rete per avere una comunicazione sicura sia fra i domini che fra i frame, e per una comunicazione bidirezionale client-server. Naturalmente non c’è modo di sapere quale di queste sopravviveranno effettivamente, siamo pronti a tagliare molte funzioni nel momento in cui queste non si rivelassero abbastanza importanti.

Uno dei principali problemi di HTML è che gli autori possono continuare a scrivere “tag soup”.

E’ veramente un problema? O non è piuttosto la ragione per cui il web ha avuto un così incredibile successo? Il web si sarebbe diffuso allo stesso modo se avesse funzionato come la maggior parte degli altri sistemi, che mostrano messaggi di errore dappertutto quando qualcosa è anche solo leggermente sbagliato?

Dato che possono continuare con il tag soup, la maggior parte degli autori di contenuti non sente il bisogno di scrivere la marcatura rispettando le specifiche. Quando la marcatura non rispetta le specifiche, i CSS potrebbero non essere applicati correttamente, Javascript potrebbe non funzionare, e alcuni programmi utente potrebbero non essere in grado di elaborare il contenuto nel modo in cui l’autore voleva.

Avere una gestione dell’errore draconiana – il termine che usiamo quando non si consente nessun errore, invece di avere un recupero dell’errore silente, come fa HTML – non è la sola soluzione per avere comportamenti coerenti fra i browser. L’approccio che abbiamo intrapreso con HTML5 è di definire quello che qualunque documento significa, anche se è invalido – fino all’ultimo dettaglio, così che ogni browser possa gestire ogni documento in maniera equivalente, che il documento sia conforme oppure no (è la stessa tecnica utilizzata dai CSS).

Perché non metter fine al tag soup semplicemente richiedendo ai programmi utenti di accettare solo marcatura conforme alle specifiche?

Ci sono letteralmente dozzine, se non centinaia di miliardi di documenti già esistenti sul web. Uno studio su un campione di diversi miliardi di questi documenti con un test di implementazione della specifica del parser di HTML5 che ho fatto per Google ha portato ad una stima molto conservativa della frazione di queste pagine con errori di marcatura a più del 78%. Quando abbiamo modificato un po’ il test per cercare qualche altro errore, il numero è diventato 93%. E questi sono solo errori di pura sintassi – non ho contato gli usi sbagliati di HTML, come mettere un p dentro un ol.

Se chiedessimo ai browser di rifiutare questi documenti, allora non potremmo più sfogliare oltre il 90% del web.

Ma considera anche questo: mettiamo che un browser mostrasse messaggi di errore su mezzo web, e un altro browser non mostrasse alcun messaggio di errore e invece mostrasse il web più o meno come voleva l’autore. Quale browser sarebbe preferito dall’utente medio?

Se vogliamo che HTML 5 abbia successo, dobbiamo essere sicuri che i produttori di browser lo tengano in considerazione. Ogni requisito che faccia scendere le quote di mercato dei browser che non seguano le specifiche verrebbe immediatamente ignorato.

L’elemento font è un costrutto terribile, principalmente perché gli autori di contenuto usano strumenti autore che usano l’elemento font invece di marcatura semantica. La specifica X/HTML5 supporta l’elemento font quando il contenuto è creato usando editor WYSIWYG. Qual è la spiegazione per questo? Perché il mondo degli editori WYSIWYG dovrebbe fare eccezione? Questa eccezione non rischia di rendere il web meno accessibile?

La questione dell’elemento font e degli editor WYIWYG è ancora in piedi, il testo attuale è soltanto un’ipotesi e abbiamo ricevuto un sacco di buoni feedback su questo, e li dovremo prendere in considerazione.

La principale ragione per cui gli editor WYSIWYG dovrebbero essere considerati un’eccezione è che allo stato dell’arte le interfacce utente oggigiorno non hanno una buona soluzione per rendere un editor semantico utilizzabile dalla persona media. Potremmo richiedere editor in grado di fare questo, ma siccome nessuno sa come farlo, sarebbe una richiesta stupida. Ancora una volta, dobbiamo cercare un compromesso tra la perfezione e i vincoli, le necessità del mondo reale.

E’ a causa dei difetti insiti in HTML che è così difficile costruire strumenti autore, come gli editor WYSIWYG, che generino una marcatura semanticamente ricca, che incorporino buone pratiche e che possano essere facilmente usate da persone non esperte tecnicamente?

No, credo che sia qualcosa che è semplicemente difficile di per sé. Le persone pensano in termini visuali. Riuscire a chiedere ai web designer di pensare nei termini di, per esempio, intestazioni, invece che di dimensione del testo è qualcosa che i realizzatori di editor visuali e gli studiosi di interfacce utente semplicemente non hanno ancora risolto. Personalmente non credo che sia una causa persa, ma non abbiamo ancora una soluzione.

Dato che molto del contenuto sul web è creato usando questi strumenti autore visuali, potremo mai raggiungere un web accessibile e semanticamente ricco?

Ci sarà sempre un continuo di siti che va dal totalmente inusabile fino al molto accessibile. Come in tutti i settori dell’ingegno umano, ci saranno sempre web designer fortemente competenti che comprendono i fondamenti della costruzione di siti indipendenti dal dispositivo che possano servire ogni tipo di utente, e quelli che saranno sempre dei web designer inesperti e ignoranti che pensano solo nei termini della propria personale esperienza, occupandosi solo di uno specifico browser senza prendere in considerazione alcuna altra potenziale esperienza utente.

Probabilmente il meglio che possiamo fare è progettare il linguaggio per rendere le cose giuste più probabili, e investire maggiormente nell’educazione. A questo proposito HTML è uno degli argomenti importanti assieme ad altri; immagino che quanto più miglioreremo la qualità dell’educazione in generale, tanto più miglioreranno la comprensione dell’importanza dell’accessibilità e degli argomenti correlati.

La specifica XHTML5 dice che “in generale, gli autori vanno scoraggiati a tentar di usare XML sul web”. Perché scrivere una specifica XML come XHTML5 e poi scoraggiare gli autori ad usarla. Perché non abbandonare semplicemente il supporto per XML (con XHTML 5)?

Alcune persone vorranno usare comunque XML con HTML5, qualunque cosa facciamo. E’ abbastanza facile – XML è un metalinguaggio per descrivere strutture ad albero, HTML5 è una struttura ad albero, dunque è ovvio che XML può essere usato per descrivere HTML 5. Il problema è che se noi non lo specifichaimo, allora chiunque pensasse che è ovvio e proseguisse a farlo, lo farebbe in modi leggermente differenti, e noi ci troveremmo nel bel mezzo di un incubo di interoperabilità. Così preferiamo prendere il toro per le corna e definire come deve funzionare qualora qualcuno volesse farlo.

Il capo dell’HTML WG al W3C, Steven Pemberton, ha detto che “HTML è un casino!” e “piuttosto che essere progettato, HTML è cresciuto, con persone differenti che ci aggiungevano ciascuno il suo”.

Ha ragione! E continua tutt’ora. Stiamo tentando di portare il processo ad un qualche livello di ragionevolezza, tuttavia!

Dato che HTML è così mal progettato, vale proprio la pena salvarlo? Siamo sicuri che HTML si possa aggiustare? E se sì, come farà X/HTML5 ad aggiustarlo?

La ragione per cui sono stato coinvolto in origine in questo lavoro è che ho capito che la razza umana ha scritto letteralmente miliardi di documenti elettronici, ma senza mai realmente dire come dovrebbero essere interpretati. Se, fra migliaia di anni, qualcuno trovasse un reperto di documenti HTML e decidesse di scrivere un browser HTML per leggerlo, non saprebbe come farlo! Anche con le attuali specifiche HTML – HTML 4, SGML, DOM 2, XHTML – un’implementazione perfetta non potrebbe rendere la maggioranza dei documenti come originariamente volevano gli autori.

Ogni produttore principale di browser oggi spende almeno la metà delle proprie risorse allocate a sviluppare browser in reverse-engeneering a capire come gli altri browser riescono funzionano. Per esempio, se prendete:

<p> <b> Hello <i> Cruel </b> World! </i> </p>

...e poi lanciate uno javascript per mostrare quali elementi ci sono e quali sono i loro genitori, cosa accadrebbe? Scopriamo che, prima di HTML5, nessuna specifica lo ha mai definito!

Ho deciso che, a beneficio delle generazioni future, dovremmo documentare esattamente come elaborare i documenti odierni, così che quando loro guarderanno indietro, potranno ancora reimplementare dei browser HTML e ripristinare i nostri dati, anche se non avranno più accesso al codice sorgente di IE (dato che IE è proprietario, è improbabile che il suo codice sorgente sopravviva così a lungo in futuro; Potremmo essere più fortunati con qualcuno degli altri browser, la cui sorgente è più o meno liberamente disponibile).

Una volta che sono effettivamente riuscito a documentare HTML per il futuro, mi è capitato di accorgermi che questo lavoro potrebbe anche avere qualche beneficio immediato, per esempio gli attuali produttori di browser sarebbero in grado di usare un’unica specifica invece di farsi reverse-engeneering reciprocamente; e che potremmo anche aggiungere nuove funzionalità per gli autori.

I sostenitori di X/HTML5 dicono che XHTML 2 è troppo radicale. La storia ci ha mostrato che i cambi radicali di tecnologia sono spesso controversi, ma alla fine sono la scelta migliore. Per esempio, negli ultimi 40 anni, la tecnologia di trasporto della musica è radicalmente cambiata, dal vinile, alle cassette, ai CD, al puro digitale. Perché il web dovrebbe essere timido di fronte ad un cambio tecnico radicale?

Se guardiamo alla musica notiamo diversi fattori chiave. Il passaggio dal vinile alle cassette avvenne con nuovi radicali benefici come la resistenza agli urti e la natura di scrittura/lettura del supporto. Per di più, notiamo che le cassette non hanno rimpiazzato il vinile; entrambe coesistettero con pubblici differenti per lungo tempo. Anche l’introduzione di supporti per lettori ottici digitali (CD) introdusse nuovi radicali benefici: una qualità significativamente più alta e una riproduzione senza perdita. I CD rimpiazzarono i vinili, perché facevano la stessa cosa, ma radicalmente meglio. Tuttavia, le cassette continuarono ad essere usate per anni, fino a che i CD riscrivibili non divennero largamente disponibili. Stiamo ora assistendo ad un passaggio da collezioni di CD all’audio immagazzinato in media magnetici digitali (come gli iPod), ma se si guarda attentamente si vedrebbe che esiste un percorso molto chiaro di migrazione dai CD audio e e dalle cassette sul nuovo media, e che il nuovo media può funzionare con adattatori sulle autoradio delle macchine come le vecchie cassette.

Dunque vediamo che i cambiamenti radicali di successo hanno bisogno di alcune caratteristiche chiave:

1. Nuovi radicali benefici per sopperire al costo del cambiamento
2. Una compatibilità all’indietro con le vecchie tecnologie.

Sono certo che verrà un giorno in cui esisteranno nuove tecnologie che faranno spostare il web verso mondi completamente nuovi, ma non credo che ci siamo ancora.

In un certo senso, comunque, HTML5 è esso stesso un cambiamento radicale. Non per ciò che specifica, ma per il modo in cui è stato creato. E’ la prima comunità veramente aperta, collaborativa, che si è incaricata di un compito di questa grandezza (nientemeno che riscrivere il libro del linguaggio alla radice del web) – è auspicabile che anche le future tecnologie seguiranno questo modello, invece dei più tradizionali modelli a porta chiusa, o gli approcci sponsorizzati dalle aziende che la maggior parte delle altre tecnologie hanno usato.

Nella mente della maggior parte delle persone, HTML è morto e X/HTML5 è percepito come un tentativo di risuscitarlo. Data questa percezione, come pensate di riuscire a diffondere e a promuovere HTML ai consumatori (cioè a coloro che costruiscono siti web?)

Secondo qualche altra ricerca che ho fatto per HTML5, oltre il 95% del web oggi è HTML, mentre il resto è per lo più un accrocchio di PDF, Word e plain text. In quale accezione del termine potremmo considerarlo “morto”? I web designer non hanno mai smesso di scrivere pagine HTML. Non credo che avremo alcuna difficoltà a convincerli a continuare.

Nota alla traduzione italiana

Fin qui l’intervista. Mi preme notare alcuni aspetti notevoli che emergono dal testo.

Primo, Vlad Alexander è considerato un “tecno-estremista”, come quelli che da noi amano rivendicare con compiacimento (e dubbio gusto) l’espressione di “talebani del codice”. Quasi ci fosse da vantarsi. Eppure riesce a dialogare con argomenti e pacatezza con un “realista” come Hickson, sfuggendo alla tentazione della derisione, della battuta fine a se stessa o dell’attacco personale. Un bell’esempio di civiltà dialettica che da noi (forum e mailing list sono purtroppo lì a documentarlo) manca, e che sarebbe serio recuperare.

Secondo, nessuno è neutrale fino in fondo. Ad esempio, Vlad Alexander tradisce le sue preferenze verso XHTML fin da come imposta le domande. Chiama ripetutamente ed esclusivamente HTML5 come X/HTML5: un’etichetta che non è presente nella specifica originaria e che lui, in buona sostanza, si inventa. Lo fa per mettere l’accento sulla X, ovviamente, e minimizzare, secondo il suo credo, la parte HTML del discorso. Hickson ribatte puntualmente chiamando la specifica HTML5, omettendo la X. Come nei dibattiti televisivi, ognuno continua con il proprio frame.

Ma anche Hickson, in qualche misura, esagera. Dire che HTML5 è rivoluzionario per il modo in cui viene sviluppato da una comunità aperta, mi sembra minimizzare tutti i progetti open source di successo. Ed è una piccola vanità a difesa della sua creatura.

Uscendo dalle note di stile per arrivare alla sostanza, direi che l’intervista riesce a centrare il punto cruciale: HTML non è mai uscito dalle nostre abitudini di progettazione e i browser non solo lo continuano a supportare, ma dovranno farlo pure in futuro a causa di tutte le pagine HTML che ci sono in giro. Allo stato attuale, significa continuare a farlo con una specifica che omette di specificare un sacco di cose. Dunque di HTML5 pare esserci obiettivo bisogno se non altro per rendere omogenea la resa dei browser e ridurre le risorse impiegate in reverse-engineering.

La questione dei nuovi tag è ancora aperta, come si è visto, e ho il sospetto che non sarà questa ad essere decisiva. Così come ho il sospetto che, al di là delle intenzioni, HTML5 continuerà a convivere con marcature XHTML (incluso XHTML2), ma rimarrà dominante a causa delle caratteristiche di tolleranza silente dell’errore che ne hanno decretato finora il successo.

Sezione: interviste - Argomento: (x)html |