Una breve historia de HTML5

Este es el artículo que por lo general, pasa por alto. No se trata de una larga explicación de código, sino que describe los acontecimientos importantes que conducen a lo que ahora reconocemos como HTML5. Algunos de nosotros encontramos estas cosas interesantes, pero, sin duda, una lección de historia no puede ser su idea de un buen momento.

¿Cuál es la diferencia entre el W3C,WHATWG y HTML WG ?

W3C - Una comunidad con el único propósito de trabajar para desarrollar estándares web.

WHATWG - formado después de varios miembros de la W3C se mostraban agitados por el rumbo que ha tomado con XHTML 2.0. Ellos preferían un enfoque diferente, menos drásticas, donde se amplió el HTML existente.

HTML WG - Una vez que el W3C finalmente reconoció que XHTML 2.0 no era el futuro, indicaron su deseo de trabajar con el grupo de trabajo lo que en desarrollo de lo que eventualmente se convertiría en HTML5. Se contrató el Grupo de Trabajo de HTML para este propósito.

Si aún así suena confuso, no se preocupe, continúe leyendo para toda la historia.

HTML vs XHTML

A la vuelta de la época que HTML avanzado a la versión 4.01 (alrededor de 1998), el suelo empezó a cambiar un poco. Los desarrolladores comenzaron a hablar de esta cosa nueva al lado del W3C está trabajando en: ". Extensible Hypertext Markup Language", XHTML, que se mantuvo para esta primera especificación 1.0 era más o menos idéntico al HTML 4.01, aparte de la inclusión de un nuevo tipo MIME, application / xhtml + xml .

Se requiere diseñadores y desarrolladores para seguir un conjunto de normas al crear marcas. ¿Cómo puede ser malo? La ironía es que, a pesar de que siguió a estas nuevas reglas, la mayoría de nosotros continuó sirviendo las páginas con el texto / html tipo MIME, lo que significa que el navegador no le importaba cómo creamos nuestras marcas. De esta manera, XHTML podría ser opt-in.

Por lo que estaban escribiendo el marcado en cierto modo, estrictamente para pasar la validación XHTML que no tuvo ningún efecto o influencia en la prestación del navegador. Un poco raro, ¿eh?

Todo esto cambió con la introducción de XHTML 1.1 - un cambio significativo hacia pura XML. Con este lanzamiento, la aplicación / xhtml + xml tipo MIME se requería. Claro, esto puede sonar como el siguiente paso natural, en teoría, pero hubo un par de problemas evidentes.

1. "Guardar en disco"

En primer lugar, Internet Explorer no pudo hacer documentos con este tipo MIME. Por el contrario, provocaría un cuadro de diálogo guardarlo en el disco .

"También he estado leyendo los comentarios desde hace algún tiempo en el IEBlog pidiendo apoyo a la" application / xml + xhtml "tipo MIME en IE. Debo decir que IE7 no tendrá soporte para este tipo de MIME -. Que, por supuesto, seguir leyendo XHTML cuando se desempeñó como "text / html", presumiendo que sigue las recomendaciones de compatibilidad HTML "- Chris Wilson

2. No tomar prisioneros

XHTML 1.1 era algo así como la profesora Umbridge, de Harry Potter.

En segundo lugar, XHTML 1.1 era algo así como la profesora Umbridge, de Harry Potter: extremadamente dura.

¿Alguna vez ha notado cómo, si se deja fuera de un cierre de etiqueta </ li> , el navegador no se inmuta? Los navegadores son inteligentes, y compensan el marco de corte (más sobre esto en breve). Mientras que, en estos días, la comunidad está comenzando a abrazar y tomar ventaja de esta verdad, con XHTML, el W3C quería imponer estrictas sintaxis XHTML. Sin embargo, hasta este momento, los desarrolladores podrían salirse con la suya dejando fuera, por ejemplo, el cierre de la etiqueta <head> o <body> , el W3C en marcha una nueva falla en el primer error del sistema, conocido como el manejo de errores draconianas. Si se detectó un error, el navegador se espera que cese la prestación de la página, y mostrar un mensaje de error, en consecuencia. Como ya he dicho: muy duras para las marcas.

Como resultado, pocos de nosotros utiliza XHTML 1.1, que era demasiado arriesgado. En cambio, hemos adoptado las mejores prácticas generales de XML, y continuó sirviendo a nuestras páginas como text / html .

XHTML 2

En sus mentes, el W3C se terminó con HTML 4. Ellos incluso apagar y rechartered el Grupo de Trabajo de HTML, y trasladado su foco a XHTML - o, en este punto, XHTML 2.0.

XHTML2 fue un esfuerzo por trazar una línea, fijar la web, y corregir los errores de HTML. Sin embargo, una vez más, esto suena fabuloso, en verdad, enojando a la mayor parte de la comunidad, debido al hecho de que nunca fue pensado para ser compatible con HTML 4. De hecho, era completamente diferente de XHTML 1.1 también!

El quiso W3C fue esencialmente ignorar la Web actual, y las demandas de sus desarrolladores, a favor de una estricta, lo que podría romper enfoque página XML. Simplemente no era práctico esperar una gran transición.

XHTML2 nunca se finalizó.

Lucha, lucha, lucha!

A la vuelta de este tiempo, la idea de que, " Hey - tal vez deberíamos volver a HTML"empezaron a venir de nuevo. El trabajo había comenzado en la Web Forms 2.0 , que logró despertar el interés renovado en HTML, en lugar de desechar por completo para XHTML2. Esta idea fue puesta a prueba en 2004, durante un taller del W3C , donde los defensores de HTML presentaron su caso, y el trabajo que había hecho con Web Forms 2.0.

Desafortunadamente, la propuesta fue rechazada con el argumento de que no cayó en línea con la meta original de trabajar por XHTML2. Huelga decir que este rechazo irritó a algunos en el grupo, integrado por representantes de Mozilla y Opera.

Por consiguiente, el grupo se diversificó, y formó el Grupo de Trabajo ¿WHAT WG (o " Web Application Technology Group de Trabajo de hipertexto. "), después de que, a falta de mejores palabras, llegando a ser molesto por la forma en la que XHTML 2 parecía encaminarse. Su objetivo era evitar tirar al bebé con el agua del baño. Continuar y ampliar el desarrollo de HTML, a través de tres especificaciones: Web Forms 2.0, Aplicaciones Web 1.0, y los controles Web 1.0.

Las dos reglas de oro

Este nuevo grupo se abrazan dos principios fundamentales:

Compatibilidad con versiones anteriores es de suma importancia. No ignore la red existente.
Especificaciones e implementaciones deben coincidir entre sí. Esto significa que la especificación debe ser muy detallada (por lo tanto, las 900 páginas).

"La web de hipertexto grupo de tecnología de aplicaciones de trabajo por lo tanto, tiene la intención de abordar la necesidad de un entorno de desarrollo coherente para aplicaciones Web. Con este fin, el grupo de trabajo creará las especificaciones técnicas que están destinados a la ejecución en los navegadores web del mercado de masas, en particular, Safari, Mozilla y Opera "-. WHATWG.org

Analizador

No hay que subestimar lo importante que era este logro.

Aunque XHTML 2.0 intención de cumplir perfecto XML, el Grupo de Trabajo se encargaró de documentar exactamente cómo HTML es, y debe ser analizado. - una tarea de cinco años!

Lo interesante es que, antes de la creación del Grupo de Trabajo , no había ninguna especificación que proporcionaba instrucciones a los proveedores de navegadores para saber cómo lidiar con los errores.Naturalmente, esto lleva a la pregunta: ¿cómo los navegadores coinciden entre sí de manejo de errores? La respuesta es a través de incansables (aunque fundamental) de ingeniería inversa. Firefox, Safari, Opera y copiar la aplicación de Internet Explorer, Explorador de Internet y revertir el manejo de ingeniería Netscape.

En el transcurso de cinco años, el grupo de trabajo trazó lo que ahora es conocido como el analizador de HTML5. No hay que subestimar lo importante que era este logro. Hoy en día, todos los navegadores modernos de análisis HTML de acuerdo con las directrices de esta especificación.Aunque quizás no tan atractivo como, por ejemplo, canvas , el analizador de HTML5 es un logro enorme.

Una línea en la arena

Como era de esperar, una línea imaginaria que fue dibujado en la arena. O estás de XHTML2 o HTML5 (lo que se convertiría).

En lugar de un enfoque basado en el consenso, donde los miembros de debate y votación en lo que sentían era el mejor, el Grupo de Trabajo tomó más de una posición de dictador-como, con Ian Hickson en el timón.

Espera - Dictador?

"La Web es, y debe ser impulsado por el mérito técnico, no el consenso. El W3C pretende lo contrario, y se desperdicia mucho tiempo para ello. El WHATWG no "-. Ian Hickson.

¿Cuál es el problema? Debo admitir que, en el papel, suena horrible, ¿no? ¿Nosotros preferimos este sistema?Políticamente hablando, sí, una dictadura puede ser una mala idea. Pero, cuando uno lo piensa en términos de la web, imagínese cuánto más rápido que puede hacer.Cuando una comunidad es tan apasionado como el nuestro, las cosas tienden a moverse muy lentamente, como los debates continúan y sigue ... y sigue.

Aunque el debate sin duda (y con razón) tiene lugar en el grupo de trabajo WHAT WG, en última instancia, Ian Hickson tiene el dedo en el botón (a menos que el grupo y la comunidad está en total desacuerdo con una decisión particular. En este punto, que puede ser sometido a juicio político, o, más a menudo que no, que va a re-evaluar y revertir su decisión).

Dicho esto, ciertamente no es ideal. El W3C tiene un enfoque basado en el consenso lento y constante, que muchos prefieren. Por otro lado, mientras que el grupo de trabajo WHAT WG se mueve a un ritmo más rápido, ciertamente hay hipo. Entonces, cuando se combinan los dos grupos, las cosas a veces pueden ser un poco fangoso!

El <data> Debacle

En octubre de 2011, Ian Hickson quitó la etiqueta <time> , y lo reemplazó con una solución de propósito más general: <data> . En sus propias palabras:

Hay varios casos de uso para <time> :

Más fácil el estilo de las fechas y horas de CSS.
Una forma de marcar la fecha de publicación / hora de un artículo (por ejemplo, para la conversión a Atom).
Una forma de marcar los tiempos de lectura mecánica y las fechas para su uso en los microformatos o los microdatos.

Los casos de uso A y B no parecen tener mucha tracción. El caso de uso C se aplica a algo más que fechas, y la falta de solución para las cosas fuera de las fechas y horas se está problemática para muchas comunidades.

Propuesta : volcar los casos de uso A y B, y el pivote <time> C en casos de uso, el cambio como lo que es igual que el <abbr> de datos legibles por máquina, principalmente para el uso de microformatos y cuentan con HTML microdatos. - Ian Hickson

Recuerde: usted tiene mucho más control sobre la forma de la web que es probable para que se dé crédito !

Lo que posiblemente no se dio cuenta de que gran parte de la comunidad, le da uso a la etiqueta <time>. Además, ellos consideran que, aunque más flexible, la propuesta de la etiqueta <data> era demasiado ambiguo; <data> ha significado un <span> , cuando se trata de semántica.

Después de un importante nivel de protestas de la comunidad, el Grupo de Trabajo de HTML ha anunciado que el cambiodel0 <time> debe ser revertido. Le dieron a Ian un breve plazo para hacer la inversión. Al mes siguiente, <time> fue reinstalado .

Esta cadena de eventos demuestra simplemente que, a pesar de que Ian tiene el derecho de proponer este tipo de cambios, la comunidad web, en su conjunto - y, por supuesto, los fabricantes de navegadores - tener un poco de control sobre la especificación. Hay una diferencia entre los creadores de especificaciones, y los autores que integran estos nuevos elementos y las API en sus proyectos. Si los autores no los usan, como bien podría ser removido de la especificación. Recuerde: usted tiene mucho más control sobre la forma de la web que es probable para que se dé crédito !

"¿Hay datos que muestran cómo la gente usa <time> en la práctica? es decir, es lo que realmente da a nadie de sus hipotéticos beneficios "- Comentario por Ian Hickson

La forma de una especificación

Mientras que algunos pueden pensar que un pequeño grupo de personas a determinar el futuro de la web, que está lejos de ser el caso. Tres facciones reciben el mismo peso, lo que se refiere a las especificaciones.

Spec Creadores - Obviamente ...
Autores - La gente como nosotros, si rechazamos (es decir, no uso) de un elemento en particular o API, que bien podría estar muerto en el agua.
Los vendedores - Los navegadores tienen una gran cantidad de insumos en estas especificaciones, muchas veces a la cabeza.

Si desea obtener más información sobre el <hora> debacle, revisar el hilo de errores , y de Ian Google + mensaje . Son interesantes lee, y no son tan blanco o negro como usted podría pensar.

De vuelta en el W3C ...

Volver a la W3C frente a lo que WG pelea . Bueno, no fue tanto una pelea, y más como dos grupos haciendo caso omiso de unos a otros por un par de años.

Como pasaba el tiempo, se hizo más claro que XHTML 2.0 no era la solución.

Mientras que el trabajo en el grupo de trabajo LO progresado con relativa rapidez, el trabajo en XHTML 2.0 del W3C fue - ¿cómo puedo poner esto ... - No va bien (casi inexistente). Como pasaba el tiempo, se hizo más claro que XHTML 2.0 no era la solución (aunque no sería totalmente caído hasta 2009). En 2006, el W3C cedió, y señaló que estaban interesados en colaborar con el Grupo de Trabajo sobre ¿QUÉ (lo que sería) HTML5. Se fletó otro grupo para este propósito: HTML GT, o el Grupo de Trabajo Hypertext Markup Language .

Tenían la intención de utilizar el trabajo del Grupo de Trabajo ¿QUÉ como base para el continuo desarrollo de HTML. Extraño, ¿no? Ahora tenemos dos grupos diferentes: el grupo de trabajo W3C HTML y el Grupo de Trabajo ¿QUÉ. Técnicamente, el W3C todavía no había dado hasta el XHTML. Sin embargo, como parte de la recién formada WG HTML, nombre Aplicaciones Web 1.0 para HTML5.

"Apple, Mozilla, Opera y permitió que el W3C para publicar la especificación bajo el copyright del W3C, mientras se mantiene una versión con la licencia menos restrictiva en el sitio ¿Qué grupo de trabajo." - WHATWG.org

Hoy

En estos días, el qué y el Grupo de Trabajo del W3C colaboran entre sí en HTML5. Es un poco de una relación extraña, pero de alguna manera se las arregla para funcionar, gracias a un suministro interminable de activistas muy apasionado.

Páginas

Historia