Poche persone conoscono il web e le sue tecnologie come Ian Hickson. Ian ha imparato il funzionamento interno dei browser quando lavorava alla Opera software e passava il suo tempo libero a correggere i bachi nel Bugzilla di Mozilla. Nonostante il lavoro a tempo pieno lo si poteva trovare a rispondere a domande sulle tecnologie web su molti forum e mailing sotto lo pseudonimo di "Hixie". Attualmente Ian lavora per Google dove nel 2005 ha condotto la più completa analisi di come il codice di marcatura è usato sul web. Dal 2007, Ian è uno dei curatori della specifica di X/HTML 5 ed è un membro del gruppo di lavoro sui CSS al W3C.
- xhtml.com
- Perché abbiamo bisogno di X/HTML5? E quando è diventato chiaro questo bisogno?
- Ian Hickson
- 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 HTML 5 è di mantenere e far evolvere HTML per soddisfare i bisogni degli autori web del 21esimo secolo. - xhtml.com
- X/HTML 5 è attualmente nello stato di Working Draft, bozza di lavoro. Quali sono le tempistiche attese per far passare X/HTML 5 attraverso il normale processo di approvazione verso lo stato di Raccomandazione?
- Ian
Con HTML 5 stiamo sperimentando un nuovo modello di definizione delle specifiche, dove alcune parti della specifica possono essere considerate pronte prima di altre. Questo perché ci sono parti della specifica che sono molto mature, con molte implementazioni, test suite, e un uso già molto attivo, mentre ne abbiamo altre che sono molto recenti e ancora in divenire.
Attualmente questo non è così evidente; i membri della comunità stanno lavorando su un sistema che segnalerà al volo lo stato della specifica, così si potrà facilmente vedere quali parti sono stabili e quali no. Altri membri della comunità hanno anche lavorato su una pagina che consente di scegliere quali cambiamenti della specifica vedere, in modo che sia possibile, per esempio, scegliere di vedere solo i cambiamenti a parti stabili della specifica che influenzano Firefox.
Tutto questo rende difficile fornire una tempistica. Alcune parti della specifica sono già finite e realmente in uso - per esempio Yahho! Pipes utilizza la funzione canvas di HTML 5. Storicamente, il momento in cui le specifiche diventano raccomandazione sono sempre stati un po' arbitrari. Per esempio, HTML 4, che ha ottenuto lo stato di Raccomandazione alla fine degli anni 90, viene ancora sviluppato e corretto. Non tutte le parti di HTML 4 sono implementate nei browser, alcune parti di HTML 4 sono notoriamente sbagliate ma non hanno un'errata corrige, e così via. Una gran parte del lavoro di HTML 5 è in realtà proprio quello di correggere i difetti di HTML 4.
HTML 5 viene sviluppato in maniera completamente aperta, comunque. Chiunque può partecipare. Potete vedere http://www.whatwg.org/ per i link ai forum, ai canali IRC, al blog, alle FAQ, ai wiki, alle mailing list, eccetera.
- xhtml.com
- 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? - Ian
Stiamo tentando di usare un processo molto più scientifico nello sviluppo di HTML 5 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.
Uno 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.
- xhtml.com
- Uno dei principali problemi di HTML è che gli autori possono continuare a scrivere "tag soup".
- Ian
- 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?
- xhtml.com
- 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.
- Ian
- 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 HTML 5 è 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).
- xhtml.com
- Perché non metter fine al tag soup semplicemente richiedendo ai programmi utenti di accettare solo marcatura conforme alle specifiche?
- Ian
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.
- xhtml.com
- X/HTML 5 ha un costrutto aggiungere della semantica ulteriore agli elementi esistenti attraverso nomi di classi predefinite. I nomi di classe predefiniti potrebbero essere la parte più controversa di X/HTML 5, a causa del sovraccarico implementativo dell'attributo
class. XHTML 2 fornisce una funzionalità simile usando l'attributo role. Quale approccio ritieni sia migliore e perché? - Ian
La proposta di avere nomi di classe predefinite è in via di discussione, stiamo per lo più aspettando i feedback dagli autori e dalle implementazioni per capire se può funzionare. Attualmente la specifica di HTML 5 lascia aperta una serie di domande (come cosa può succedere se due classi su un elemento sono contraddittorie), e non è definitiva.
Non sono stato in grado di capire cosa l'attributo role faccia o come dovrebbe essere implementato. C'è una specifica, ma è assai poco chiara. Così non sono in grado di fare commenti.
- xhtml.com
- 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/HTML 5 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?
- Ian
Anche in questo caso, 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.
- xhtml.com
- 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?
- Ian
- 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.
- xhtml.com
- Dato che molto del contenuto sul web è creato usando questi strumenti autore visuali, potremo mai raggiungere un web accessibile e semanticamente ricco?
- Ian
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.
- xhtml.com
- La specifica XHTML 5 dice che "in generale, gli autori vanno scoraggiati a tentar di usare XML sul web". Perché scrivere una specifica XML come XHTML 5 e poi scoraggiare gli autori ad usarla. Perché non abbandonare semplicemente il supporto per XML (con XHTML 5)?
- Ian
- Alcune persone vorranno usare comunque XML con HTML 5, qualunque cosa facciamo. E' abbastanza facile - XML è un metalinguaggio per descrivere strutture ad albero, HTML 5 è 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.
- xhtml.com
- 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".
- Ian
- Ha ragione! E continua tutt'ora. Stiamo tentando di portare il processo ad un qualche livello di ragionevolezza, tuttavia!
- xhtml.com
- Dato che HTML è così mal progettato, vale proprio la pena salvarlo? Siamo sicuri che HTML si possa aggiustare? E se sì, come farà X/HTML 5 ad aggiustarlo?
- Ian
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.
- xhtml.com
- I sostenitori di X/HTML 5 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?
- Ian
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:
- Nuovi radicali benefici per sopperire al costo del cambiamento
- 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, HTML 5 è 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.
- xhtml.com
- Nella mente della maggior parte delle persone, HTML è morto e X/HTML 5 è 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?)
- Ian
- Secondo qualche altra ricerca che ho fatto per HTML 5, 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.