Perché ci vuole così tanto tempo per finalizzare le specifiche HTML 5? [chiuso]

Stavo leggendo questo e una frase ha attirato la mia attenzione (enfasi sulla mia):

Quindi Ian Hickson, il più grande critico di XHTML, ha creato HTML 5, una specifica per bambini orientata all'azione che non raggiungerà l'età adulta fino al 2022 , anche se alcuni di questi possono essere utilizzati oggi.

È vero? È davvero il ciclo di sviluppo di HTML 5? Perché ci vuole così tanto tempo? Cosa rende così difficile ottenere il giusto che non sarà definitivo fino a 11 anni da oggi?

La data menzionata per il processo di finalizzazione è stata fissata così lontano nel futuro perché il processo degli standard per le specifiche HTML è stato impostato in modo tale da garantire un'ampia accettazione delle specifiche.

Alcuni retroscena: ci sono due organismi di standard che lavorano su progetti correlati a ciò che comunemente chiamiamo "HTML5": il World Wide Web Consortium (W3C) e il Web Hypertext Application Technology Working Group (WHATWG). Prima di luglio 2012, entrambi i gruppi lavoravano (principalmente) insieme per sviluppare HTML.

Il processo principale è stato quello di passare attraverso una serie di pietre miliari:

• Bozza di lavoro: le  specifiche sono in fase di sviluppo e discussione attiva
• Last Call Working Draft (LCWD): le specifiche sono per lo più complete e gli implementatori hanno l'opportunità di sollevare le ultime obiezioni alla specifica prima che entri nel processo di finalizzazione
• Raccomandazione del candidato: le  specifiche sono state finalizzate in modo efficace e sicure da usare per gli implementatori e gli autori dei contenuti
• Raccomandazione: due implementazioni indipendenti e completamente interoperabili delle specifiche sono state completamente completate

La pietra miliare della LCWD è iniziata nel 2011 e la fase della Raccomandazione per i candidati dovrebbe arrivare relativamente presto nel 2014. È stata l'ultima pietra miliare, la Raccomandazione, che ha richiesto due implementazioni complete delle specifiche, che avrebbe richiesto diversi anni ed è la ragione del 2022 Data.

In questo modello, la prima vera pietra miliare che ha riguardato gli autori di contenuti (non i creatori di user agent, come i browser) è stata la LCWD, poiché le specifiche erano destinate principalmente a essere finalizzate. Una volta completato il LCWD, HTML5 avrebbe raggiunto il traguardo della Raccomandazione del Candidato, e sarebbe stata una specifica finale in tutti tranne che nel nome: avresti potuto implementarlo impunemente, come l'ultimo traguardo, Raccomandazione, non ha alcun effetto sul contenuto dello standard ed è in gran parte poco interessante per gli autori di contenuti.

Tuttavia, a luglio 2012, il W3C e WHATWG hanno formalizzato una divisione nel modo in cui sarebbe stata sviluppata la bozza HTML5. Questa divisione, che funzionava da alcuni anni funzionalmente, imposta due diverse "tracce" HTML:

• Uno standard di vita, sviluppato da WHATWG e semplicemente chiamato "HTML", in cui le specifiche non sono mai completamente complete. Viene stabilito un ragionevole consenso per lo standard ma non è necessario implementare tutto.

• Istantanee periodiche e stabili dello standard sviluppato dal W3C come specifica HTML5. A partire da settembre 2012, il W3C propone di raggiungere la pietra miliare della Raccomandazione su "HTML 5.0" nel 2014, con istantanee puntuali ogni due anni (ad esempio, "HTML 5.1" nel 2016).

A causa della prima, HTML5, come abbiamo capito, è utilizzabile ora . Sfortunatamente, poiché è uno standard di vita, usarlo come autore di contenuti richiede la comprensione dell'implementazione di ciascun agente utente.

La risposta semplice: Design by Committee

Il vantaggio della folla di persone che osserva il design è che l'intero gruppo troverà diversi aspetti a cui il designer originale non ha pensato. Questo è un vantaggio.

Quando il designer è una grande folla, tutti hanno diversi programmi e cose da animali domestici che vogliono entrare nello standard per qualsiasi motivo. A volte le caratteristiche sono in conflitto tra loro, a volte c'è politica che circonda le decisioni, ecc. Ci vuole molto tempo prima che un folto gruppo di persone raggiunga un accordo. Questo è un aspetto negativo.

Nel bene e nel male, il W3C ha scelto di sviluppare i propri standard in questo modo.

Perché è fondamentale che sia giusto.

• Ci vuole tempo per sistemare le cose: lo standard HTML5, una volta impostato, sarà disponibile per molto tempo. Deve essere il meglio che può essere e deve essere giusto. Ciò richiede il dibattito di esperti, prove ed errori, input da utenti e sviluppatori e analisi delle statistiche

• Quando uno standard cambia, l'app di qualcuno da qualche parte si romperà: gli standard devono essere giusti la prima volta. Con ogni modifica a uno standard, l'app di qualcuno da qualche parte nel mondo si rompe con la nuova versione. Ciò richiede a noi sviluppatori di risolvere il problema, costando tempo e denaro. Deve essere giusto la prima volta.

• La vaghezza deve essere rimossa - È facile dire che è ciò che fa il tag canvas quando c'è solo il tag canvas sulla pagina, ma che dire quando si trova all'interno di un altro tag? Che dire delle combinazioni di tag? Come dovrebbero essere resi? Come devono essere visualizzati con attributi di stile X impostati in combinazioni particolari?

Bonus: dai un'occhiata alle specifiche HTML5 nella sua forma attuale e vedrai cosa ne accadrà.

Lungo? Microsoft ha impiegato quasi 8 anni per rendere CSS2 semplice funzionante a mala pena in IE7, mentre il supporto DOM1 in javascript è ancora rotto in IE8. Sono le specifiche del 1998.

Ecco perché non vedrai un'ampia adozione di HTML5 nei contenuti multimediali nei prossimi 20 anni. È molto complicato, incompiuto, le prestazioni fanno schifo. Anche cose semplici come i websocket sono disattivate per motivi di sicurezza.

Alcune cose non funzioneranno come standard aperti. Fare giochi o MM in un ambiente che dovrebbe funzionare su thin client e supportare un grazioso degrado? Questa è follia.

EDITED: Sì, il primo è l'eccesso di complicazioni. Hai un plug-in flash che è lo stesso in ogni browser e funziona allo stesso modo ogni volta. Questa è una soluzione semplice ed efficace. Un'interfaccia, fai una volta la modifica, ricompila e viola: hai un plug-in per tutti i browser sul mercato, utilizzando un livello intermedio tra il browser e il plug-in.

Dall'altro hai 10 browser e vuoi aggiungere ad es. supporto multimediale / film. Ciò significa che ogni azienda dovrà implementare il lettore multimediale da zero, oltre a tutti vogliono qualcosa di diverso. Apple vuole H.264, quindi i proprietari di siti Web pagheranno le royalties per il codec per la riproduzione di film, Google e Mozilla vogliono VP8 in modo che i loro affari non siano influenzati dai brevetti di Apple, ecc.

Quindi finisce per implementare le cose che tutti vogliono (mentre VP8 o H.264 farebbero, per cominciare).

Quindi, prima di poter superare le loro differenze, Adobe implementerà H.264 in flash, utilizzerà lo streaming e lo stack DRM già disponibili e ... sarà pronto. 3-4 mesi e hai una tecnologia funzionante con un tasso di adozione del 98%.

Semplice, una società decide, in modo che possano spingere rapidamente enormi cambiamenti e non dovranno aggiungere "idee" di altri 20 membri del "corpo di standarization". Accanto a HTML5 è forse 10-15 anni indietro rispetto a Flash, nel settore multimediale. Il divario aumenterà solo. Nel recente MAX avant puoi vedere il supporto dei controller di gioco e le app di corse 3D a schermo intero, in esecuzione in flash con FPS completo, supporto per l'accelerazione hardware e così via. Nel frattempo, mozilla ora può riprodurre video H.246 senza arrestare il browser, ma solo giocare. Qualsiasi funzionalità aggiuntiva (come schermo intero, streaming, avanzamento rapido) manca ancora!

Inoltre penso che W3C stia semplicemente sprecando risorse cercando di rendere HTML5 una copia di Flash a metà. Non funzionerà ... è come provare a fare in flash una copia di HTML. Non funzionerà

Fondamentalmente, ottenere un gruppo di persone d'accordo su qualcosa è piuttosto difficile. Per non parlare del fatto che ci sono vari problemi da risolvere. Ad esempio, c'è (c'era?) Un sacco di dibattito su quale codec usare per i video.

Nel bene e nel male, la maggior parte delle specifiche richiede un po 'di tempo per essere risolta.

Mark Pilgrim ne parla nel suo "Dive Into HTML5" qui: http://diveintohtml5.org/past.html Sembra che a molte persone non piaccia la versione del libro perché non è abbastanza tecnica, ma in questa sezione il la redazione è abbastanza giustificata.

(Modifica: volevo solo fornire un riferimento per il mio commento su persone che non apprezzano la qualità "chiacchierona" del libro: controlla le recensioni su Amazon . Personalmente mi è piaciuto leggerlo e l'ho trovato informativo, quindi il chilometraggio può variare. )

Parte del problema è che le specifiche non saranno finalizzate fino a quando non ci saranno almeno due importanti implementazioni delle specifiche - almeno due browser separati che la supportano per intero. Quindi le specifiche devono essere abbastanza complete per la piena implementazione, quindi devono essere effettivamente implementate, quindi possono essere finalizzate.

Parte del problema: voglio ogg theora nel browser. Sei d'accordo? No. Vuoi H.264. Ma sono d'accordo? No. Questo è il problema tra Google, Mozilla, Microsoft, Apple, Adobe e tutte le società che giocano dietro HTML 5. Stanno cercando di massimizzare le entrate ed essere il monopolista. La sua intensa competizione. Quindi diventa più lungo da completare.