HTML 5: un altro buon motivo per non usarlo

terrore per HTML 5

HTML 5 ha una strana storia. Intorno al 2007, Ian Hickson (Hixie) inizia a lavorare con W3C sulle specifiche allora chiamate “Web Applications 1.0“, prodotte da Hickson stesso, che diventano HTML 5 (molto grossolanamente).

Però, parallelamente allo sviluppo di HTML 5, il WHATWG (un gruppo costituito da Apple, Mozilla Foundation e Opera Software con lo scopo di sviluppare Bible 5) continua a lavorare su specifiche proprie, differenti da quelle sviluppate con il W3C note come HTML 5.

Ovviamente questo non aiuta lo sviluppo di uno standard, e le specifiche del WHATWG si sono allontanate tanto da quelle di HTML 5 W3C da indurre Ian Hickson a dividere il lavoro dei due gruppi, formalizzando ufficialmente quello che da tempo stava accadendo (il primo annuncio è del 2011), per la gioia degli sviluppatori che avranno da litigare con due confuse pseudo specifiche nessuna delle due complete e senza avere la minima idea di quale si imporrà nel supporto dei browser.

Perché questo è il problema: le due specifiche si differenziano, hanno un sistema di bug tracking diverso, la confusione regna sovrana e nessuno capisce più di chi sia il bug, se di W3C HTML 5 o WHATWG  HTML 5…

Ora, secondo Hickson, dovremmo parlare di “HTML Living Standard” [1. attenzione, caricando la pagina facile che il browser si inchiodi]. No comment, ma io non userei HTML 5 per produzione, a meno che non vi piaccia rifare i lavori.

Giusto per capire di cosa stiamo parlando, dice Steve Faulkner:

The HTML standard contradicts the HTML5 specification (or vice versa) on a number of author conformance requirements and advisory techniques, including use of tables, use of ARIA and use of the title attribute…

…All in all I do not agree with your claim of the HTML living standard being canonical. It is unfortunately the case that we now have at least 2 specifications; HTML5 and the living standard neither of which can claim to be canonical description of HTML for stakeholders other than browser vendors.

Avanti così, facciamoci del male… Ora dobbiamo anche chiederci “Quale HTML 5”.

 

 

Annunci

9 pensieri su “HTML 5: un altro buon motivo per non usarlo

  1. ah boh, spero di no perché Apple non è che con gli standard faccia un granché di buon lavoro (vedi epub 3). Però, in definitiva, non me ne frega tanto di questo, quanto della confusione che questa gente sta generando.

  2. HTML5, in confronto ai trenta dialetti precedenti, è un grosso passo in avanti. Inoltre, il fatto che ci siano due enti che si occupano di portare avanti lo standard è un bene perché favorisce lo sviluppo di soluzioni nuove e migliori. Poi, certamente arriveranno ad accordi per il bene comune. Insomma, va tutto bene 🙂

  3. Uhm ho paura di no. HTML Living Standard è per sua natura il contrario di quello che dovrebbe essere uno standard, ovvero un ambiente stabile, condiviso e documentato.
    Sarà invece un markup fatto dai venditori di browser, soggetto a continui cambiamenti. Sicuro che sia una buona idea?
    Non capisco cosa intendi con “trenta dialitti precedenti”. A cosa ti riferisci?

  4. Sulla confusione hai ragione, Livio. Sto finendo di leggere in questi giorni The truth about HTML5 di Luke Stevens ( http://www.truthabouthtml5.com ), molto controcorrente rispetto all’hype e alla riverenza. Suggerisce per esempio di non usare i tag semantico-strutturali HTML5, con alcuni buoni argomenti. Tanto la sematica non passerà per quelli ma per microdata, pare, e fuori di ogni consultazione aperta e condivisa.

    Peraltro usare fin d’ora non impone nulla: è libertà in più e slash inutili in meno. XHTML è figlio di una logica pedante, da web solo testuale. Ed è una linea chiusa. Pare ovvio passare rapidamente al nuovo, per quanto è già possibile, supportato ed effettivamente utile.

    Certo, abbiamo bisogno di standard condivisi, ma, salva la retrocompatibilità per un dato arco di tempo, non è detto che gli standard debbano essere stabili, perchè è in continuo cambiamento lo spazio che pretendono di ‘governare’. Ci sta arrivando addosso la rivoluzione mobile che affrontiamo armati di una manciata di media queries. L’introduzione di nuovi gruppi di feature può benissimo avvenire con tempi più rapidi di quelli lunghissimi della cartabollata del W3C. Le media queries sono diventate web standard solo il 20 giugno 2012 (http://www.w3.org/TR/2012/REC-css3-mediaqueries-20120619/) e i CSS2.1 il 7 giugno 2011 (http://www.w3.org/TR/2011/REC-CSS2-20110607). Eventi passati quasi inosservati: li usavamo tranquillamente da molto tempo perchè quello che è ampiamente supportato è standard di fatto. Il problema non è questo anticipo nell’uso, il problema è la lentezza dei tempi ufficiali.

    Ciao, mez

    p.s.: a proposito di Apple, retina, mq e prefissi… interessante questo:
    http://www.w3.org/blog/CSS/2012/06/14/unprefix-webkit-device-pixel-ratio/

  5. Grazie per la segnalazione, sembra una lettura interessante e mi fa piacere sapere che non sono il solo ad avere qualche dubbio. Io non sono contrario all’uso di qualsiasi cosa, se si sa cosa si fa.
    Non trovo sia utile o produttivo per il web in genere usare qualcosa perché “il mio amico mi ha detto che è più fico” e/o accettare supinamente determinati hype puramente commerciali.
    Il problema secondo me non consiste né nell’anticipo né nella lentezza, se le feature introdotte funzionano. Ritengo sia un vero problema invece quando si sostengono funzionalità ritenute innovative senza che queste funzionino realmente, nel caso di html5 per esempio form, audio, video, microdata.
    Un conto è l’innovazione, che anticipa i tempi ufficiali per definizione, un conto è la patacca 🙂

  6. HTML5 presenta dei punti dubbi, uno fra tutti la validazione. Mi sembra un controsenso eliminare la DTD dal DOCTYPE per poi comunque usarla nella validazione. Infatti non si può validare senza regole sintattiche precise. La DTD rendeva le cose più chiare, perchè bastava leggerla per capire come andava strutturata la marcatura. Ora HTML5 ha introdotto nuovi concetti nella validazione, quando sarebbe stato sufficiente riprendere i concetti XHTML di block e inline, molto più semplici. Tra l’altro i nuovi elementi sono figli di un sondaggio condotto da Ian Hickson sugli attributi più usati dagli sviluppatori. Quindi header è figlio di id=”header” e così via, che sa tanto di presentazionale. La cosa interessante di HTML5 sono le API, ma queste si sarebbero potute aggiungere ad XHTML col minimo sforzo. Molto fumo, molta moda e finora poco arrosto.

Rispondi

Inserisci i tuoi dati qui sotto o clicca su un'icona per effettuare l'accesso:

Logo WordPress.com

Stai commentando usando il tuo account WordPress.com. Chiudi sessione / Modifica )

Foto Twitter

Stai commentando usando il tuo account Twitter. Chiudi sessione / Modifica )

Foto di Facebook

Stai commentando usando il tuo account Facebook. Chiudi sessione / Modifica )

Google+ photo

Stai commentando usando il tuo account Google+. Chiudi sessione / Modifica )

Connessione a %s...