¿Por qué tarda tanto en finalizar la especificación HTML 5? [cerrado]

Estaba leyendo esto y una oración me llamó la atención (el énfasis es mío):

Así que Ian Hickson, el mayor crítico de XHTML, fue el padre de HTML 5, una especificación para niños orientada a la acción que no llegará a la edad adulta hasta 2022 , aunque parte de ella se puede usar hoy en día.

¿Es eso cierto? ¿Es realmente el ciclo de desarrollo de HTML 5? ¿Por qué lleva tanto tiempo? ¿Qué hace que sea tan difícil acertar que no será definitivo hasta dentro de 11 años?

La fecha mencionada para el proceso de finalización se estableció en el futuro porque el proceso de estándares para la especificación HTML se configuró de tal manera que garantizaba una amplia aceptación de la especificación.

Algunos antecedentes: hay dos organismos de estándares que trabajan en borradores relacionados con lo que comúnmente denominamos "HTML5": el Consorcio World Wide Web (W3C) y el Grupo de trabajo de tecnología de aplicación de hipertexto web (WHATWG). Antes de julio de 2012, ambos grupos estaban trabajando (principalmente) juntos para desarrollar HTML.

El proceso principal fue ejecutar una serie de hitos:

• Borrador de trabajo: la  especificación está en desarrollo activo y discusión
• Borrador de trabajo de última convocatoria (LCWD): la especificación está casi completa y los implementadores tienen la oportunidad de plantear cualquier última objeción a la especificación antes de que entre en el proceso de finalización
• Recomendación del candidato: la  especificación está efectivamente finalizada y es segura de usar para implementadores y autores de contenido
• Recomendación: dos implementaciones independientes, totalmente interoperables de la especificación se han completado por completo

El hito de LCWD comenzó en 2011 y se esperaba que la fase de Recomendación de Candidato llegara relativamente pronto en 2014. Fue el último hito, la Recomendación, que requirió dos implementaciones completas de la especificación, que habría llevado varios años y es la razón del 2022 fecha.

En este modelo, el primer hito real que involucró a los autores de contenido (no a los creadores de agentes de usuario, como los navegadores) fue el LCWD, ya que la especificación estaba destinada a finalizarse en su mayoría. Una vez que se completó el LCWD, HTML5 habría alcanzado el hito de la Recomendación del candidato, y habría sido una especificación final en todo menos en el nombre: habría podido implementarlo impunemente, como lo haría el último hito, la Recomendación. no tiene ningún efecto sobre el contenido del estándar y es poco interesante para los autores de contenido.

Sin embargo, en julio de 2012, el W3C y WHATWG formalizaron una división en cómo se desarrollaría el borrador HTML5. Esta división, que había estado funcionando funcionalmente durante algunos años, configura dos "pistas" HTML diferentes:

• Un estándar de vida, desarrollado por el WHATWG y simplemente llamado "HTML", en el que la especificación nunca está completamente completa. Se establece un consenso razonable para el estándar, pero no se requiere implementar todo.

• Instantáneas periódicas y estables del estándar desarrollado por el W3C como la especificación HTML5. A partir de septiembre de 2012, el W3C propone alcanzar el hito de la Recomendación sobre "HTML 5.0" en 2014, con instantáneas de puntos cada dos años (por ejemplo, "HTML 5.1" en 2016).

Debido a lo anterior, HTML5, tal como lo hemos entendido, ahora es utilizable . Desafortunadamente, como es un estándar de vida, usarlo como autor de contenido requiere comprender la implementación de cada agente de usuario.

La respuesta fácil: diseño por comité

El beneficio de la multitud de personas que observan el diseño es que todo el grupo presentará diferentes aspectos en los que el diseñador original no pensó. Eso es un plus.

Cuando el diseñador es una gran multitud, todos tienen diferentes agendas y cosas para mascotas que quieren ingresar al estándar por cualquier razón. A veces, las características entran en conflicto entre sí, a veces hay políticas que rodean las decisiones, etc. A un gran grupo de personas le lleva mucho tiempo llegar a un acuerdo. Eso es un menos.

Para bien o para mal, el W3C ha elegido desarrollar sus estándares de esta manera.

Porque es crítico que sea correcto.

• Se necesita tiempo para hacer las cosas bien: el estándar HTML5, una vez establecido, existirá durante mucho tiempo. Tiene que ser lo mejor que puede ser y tiene que ser lo correcto. Eso requiere debate por parte de expertos, prueba y error, aportes de usuarios y desarrolladores y análisis de estadísticas.

• Cuando un estándar cambia, la aplicación de alguien en algún lugar se romperá: los estándares deben ser correctos la primera vez. Con cada cambio a un estándar, la aplicación de alguien en algún lugar del mundo rompe con la nueva versión. Eso requiere que nosotros, como desarrolladores, lo arreglemos, lo que nos cuesta tiempo y dinero. Tiene que estar bien la primera vez.

• La vaguedad debe eliminarse : es fácil decir que esto es lo que hace la etiqueta del lienzo cuando solo está la etiqueta del lienzo en la página, pero ¿qué pasa cuando está dentro de otra etiqueta? ¿Qué pasa con las combinaciones de etiquetas? ¿Cómo deberían rendir? ¿Cómo deberían renderizar con atributos de estilo X establecidos en combinaciones particulares?

Bonificación: eche un vistazo a las especificaciones HTML5 en su forma actual y verá lo que contiene.

¿Largo? Microsoft tardó casi 8 años en hacer que CSS2 simple apenas funcionara en IE7, mientras que el soporte DOM1 en JavaScript todavía está roto en IE8. Esa es la especificación de 1998.

Es por eso que no verá una amplia adopción de HTML5 en multimedia en los próximos 20 años. Es muy complicado, inacabado, el rendimiento apesta. Incluso cosas simples como websockets están desactivadas por razones de seguridad.

Algunas cosas no funcionarán como estándares abiertos. ¿Está haciendo juegos o MM en un entorno que debería funcionar en thin client y soportar una degradación elegante? Eso es una locura.

EDITADO: Sí, primero es la complicación excesiva. Tiene un complemento flash que es el mismo en todos los navegadores y funciona de la misma manera cada vez. Esa es una solución simple y efectiva. Una interfaz, realiza el cambio una vez, vuelve a compilar y viola: tienes un complemento para todos los navegadores en el mercado, utilizando una capa intermedia entre el navegador y el complemento.

Por otro lado, tiene 10 navegadores y desea agregar, por ejemplo. soporte multimedia / película. Eso significa que cada empresa tendrá que implementar un reproductor multimedia desde cero, además de que todos quieren algo diferente. Apple quiere H.264 para que los propietarios de sitios web les paguen regalías por códec para reproducir películas, Google y Mozilla quieren VP8 para que su negocio no se vea afectado por las patentes de Apple, etc.

Por lo tanto, termina implementando cosas que todos quieren (mientras VP8 o H.264 lo harían, para empezar).

Entonces, antes de que puedan superar sus diferencias, Adobe implementará H.264 en flash, use su pila de transmisión y DRM ya disponible y ... está listo. 3-4 meses y tienes una tecnología que funciona con una tasa de adopción del 98%.

Simple, decide una compañía, para que puedan impulsar cambios masivos rápidamente y no tengan que agregar "ideas" de otros 20 miembros del "cuerpo de estandarización". Además de HTML5, está quizás 10-15 años atrás de flash, en multimedia. La brecha solo se hará más grande. En MAX avant reciente, se podía ver el soporte de los controladores de juegos y las aplicaciones de carreras 3D de pantalla completa, que se ejecutan en flash en FPS completo, soporte de aceleración de hardware, etc. Mientras tanto, Mozilla ahora puede reproducir video H.246 sin bloquear el navegador, pero solo reproducirlo. Todavía falta alguna funcionalidad adicional (como pantalla completa, transmisión, avance rápido).

Además, creo que W3C solo está desperdiciando recursos al tratar de hacer de HTML5 una copia de flash a medio cocer. No funcionará ... es como tratar de hacer flash una copia de HTML. No funciona

Básicamente, lograr que un grupo de personas esté de acuerdo en algo es bastante difícil. Sin mencionar que hay varios problemas que resolver. Por ejemplo, hay (¿hubo?) Mucho debate sobre qué códec usar para video.

Para bien o para mal, la mayoría de las especificaciones tardan un poco en desarrollarse.

Mark Pilgrim habla de esto en su "Inmersión en HTML5" aquí: http://diveintohtml5.org/past.html Parece que a muchas personas no les gusta la versión del libro porque no es lo suficientemente técnica, pero en esta sección el editorial está bastante justificada.

(Editar: solo quería proporcionar una referencia para mi comentario sobre las personas a las que no les gusta la calidad "habladora" del libro: revise las reseñas en Amazon . Personalmente disfruté leerlo y encontré que es informativo, por lo que el kilometraje puede variar. )

Parte del problema es que la especificación no se finalizará hasta que haya al menos dos implementaciones principales de la especificación, al menos dos navegadores separados que la admitan por completo. Por lo tanto, la especificación debe ser lo suficientemente completa para una implementación completa, luego debe implementarse realmente y luego puede finalizarse.

Parte del problema: quiero ogg theora en el navegador. ¿Estás de acuerdo? No. Quieres H.264. Pero estoy de acuerdo? No. Ese es el problema entre Google, Mozilla, Microsoft, Apple, Adobe y todas las empresas que juegan detrás de html 5. Intentan maximizar los ingresos y son los monopolistas. Su intensa competencia. Por lo tanto, se tarda más en completar.