7 days of WordPress plugins, themes & templates - for free!* Unlimited asset downloads! Start 7-Day Free Trial
Advertisement
  1. Code
  2. Web Development

Breve historia de HTML5

Scroll to top
Read Time: 14 mins

Spanish (Español) translation by Eva Collados Pascual (you can also view the original English article)

Este es el típico artículo que generalmente omites. Es uno en el que no detallo ni una pizca de código, en su lugar describo los acontecimientos relevantes que condujeron a lo que ahora conoces como HTML5. A algunos de nosotros esto nos parece interesante, pero sin duda, es posible que a ti una lección de historia no te resulte entretenido.

... Espera, ¿todavía estás aquí? Entonces sigamos con esto.

No nos vamos a remontar hasta los orígenes. Para ello sería necesario un libro completo por sí solo. En lugar de eso, nos remontaremos hasta el lanzamiento de HTML 4.01, al final de los años noventa.


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

  • W3C – Una comunidad con el único propósito de trabajar para desarrollar estándares web.
  • WHATWG – Formado después de que varios miembros del W3C se inquietasen por la dirección que se estaba tomando con XHTML 2.0. Este grupo prefirió tomar un enfoque diferente, menos drástico, en el que se ampliaba el HTML existente.
  • HTML WG – Una vez que el W3C reconoció finalmente que el futuro no estaba en el XHTML 2.0, indicaron que deseaban trabajar con WHAT WG en el desarrollo de lo que eventualmente se convertiría en HTML5. Y lanzaron el HTML WG para este propósito.

Si esto te sigue sonando algo confuso, no te preocupes; continua leyendo para comprender toda la historia.


HTML vs XHTML

Alrededor del período en el que HTML avanzó a la versión 4.01 (sobre 1998), el terreno comenzó a cambiar un poco. Los desarrolladores empezaron a hablar sobre esa nueva cosa en la que el W3C estaba trabajando: XHTML, que significaba "Extensible Hypertext Markup Language" (Lenguaje de marcado de hipertexto extensible). Esta primera especificación 1.0 era más o menos idéntica a HTML 4.01, a excepción de la inclusión de un nuevo tipo MIME, application/xhtml+xml.

Lo creas o no, siempre hemos sido capaces de salirnos con la nuestra omitiendo las comillas que acotan los valores de atributo (principalmente) y el cierre de las etiquetas que no se cierran automáticamente. Sin embargo, hasta hace poco, esto era generalmente considerado una mala práctica. Para los jóvenes entre aquellos que me leéis, la razón por la que lo veíamos como una mala práctica se debe en gran parte a la popularidad de XHTML.

Concibe el XHTML como si fuese tu abuela. Cuando esta viene de visita, te obliga a cepillarte los dientes, a mantenerte erguido y a comerte tus guisantes. Ahora reemplaza los dientes, la postura y los guisantes, por comillas, etiquetas de cierre automático y nombres de etiquetas en minúsculas.

Aunque estoy bromeando, en general, veíamos el XHTML 1.0 como algo bueno, un paso adelante. Requería que los diseñadores y desarrolladores siguieran un conjunto de estándares al crear marcado. ¿Cómo podría ser algo malo? La ironía es que, aunque seguíamos estas nuevas reglas, la mayoría de nosotros continuamos sirviendo páginas con el tipo MIME text/html, lo que significaba que al navegador realmente no le importaba cómo habíamos creado nuestro marcado. De esta manera, XHTML podría ser opcional.

Así que estábamos escribiendo marcado de una manera determinada y estricta para pasar la validación XHTML, pero esto tenía cero efecto o influencia en la representación del navegador. Curioso, ¿no?

XHTML 1.1

Todo esto cambió con la introducción de XHTML 1.1 – un avance significativo hacia el XML puro. Con esta versión, se requería el tipo MIME application/xhtml+xml. Claro, en teoría, esto puede sonar como el paso adelante lógico pero surgieron un par de problemas evidentes.

1. "Guardar en disco"

En primer lugar, Internet Explorer no pudo representar documentos con este tipo MIME. En su lugar, solicitaría un cuadro de diálogo de guardar en disco. ¡Uf!

"También he estado leyendo comentarios durante algún tiempo en IEBlog pidiendo soporte para el tipo MIME "application/xml+xhtml" en IE. Debo decir que IE7 no añadirá soporte para este tipo MIME, por supuesto, seguiremos leyendo XHTML cuando se sirva como "text/html", suponiendo que siga las recomendaciones de compatibilidad HTML." – Chris Wilson

2. No hagas prisioneros

XHTML 1.1 era como el profesor Umbridge, de Harry Potter.

En segundo lugar, XHTML 1.1 era algo así como el profesor Umbridge, de Harry Potter: extremadamente duro. ¿Alguna vez has notado cómo, si omites una etiqueta de cierre </li>, el navegador no se estremece? Los navegadores son inteligentes y compensan tus errores de marcado (más sobre esto en breve). Mientras en la actualidad la comunidad está empezando a aceptar y aprovechar esto, con XHTML, el W3C pretendía aplicar la sintaxis más estricta de XHTML. Aunque, hasta este punto, los desarrolladores podrían salirse con la suya dejando fuera, digamos, la etiqueta de cierre </head> o </body>, el W3C implementó un nuevo error en el primer sistema de error, conocido como gestión de errores draconianos. Si se detectaba un error, se esperaba que el explorador dejara de representar la página y mostrara, en consecuencia, un mensaje de error. Como comenté: algo increíblemente duro para el marcado.

Como resultado, pocos de nosotros acabamos usando alguna vez XHTML 1.1; era demasiado arriesgado. En su lugar, adoptamos las mejores prácticas generales de XML y continuamos sirviendo nuestras páginas como texto/html.

XHTML 2

En sus mentes, el W3C se terminó con HTML 4. Incluso cerraron y refletaron el grupo de trabajo HTML, y transfirieron su enfoque a XHTML, o, ya en este momento, XHTML 2.0.

XHTML2 fue un esfuerzo por dibujar una línea, arreglar la web y corregir los errores de HTML. Aunque, de nuevo, esto suena fabuloso, en verdad, enfureció a gran parte de la comunidad, debido a que nunca se pretendió que fuese compatible con HTML 4. De hecho, ¡era completamente diferente también a XHTML 1.1!

¿Entiendes a donde quiero llegar con esto? El W3C en esencia ignoraba la web actual y las demandas de sus desarrolladores, en favor de un enfoque XML estricto y potencialmente rompe páginas. Sencillamente, esperar una transición tan grande no fue práctico.

XHTML2 nunca se concluyó.


¡Pelea, pelea, pelea!

(Bien, no hasta el punto del Club de Lucha.) Justo en este momento, la idea de que, "Oye, tal vez deberíamos volver a HTML y trabajar a partir de eso" comenzó a emerger de nuevo. Se había comenzado a trabajar en los Web Forms 2.0, lo que logró despertar un renovado interés en HTML, en lugar de desguazarlo por completo para XHTML2. Este concepto se puso a prueba en 2004, durante un taller de W3C, donde los defensores de HTML presentaron su caso, y el trabajo que ya habían hecho con Web Forms 2.0.

Desafortunadamente, la propuesta fue rechazada con el argumento de que no se alineaba con el objetivo original de trabajar en pro de XHTML2. No hace falta decir que este rechazo enfureció a algunos en el grupo, incluyendo representantes de Mozilla y Opera.

En consecuencia, el grupo se ramificó y formó el WHAT Working Group (o, "Web Hypertext Application Technology Working Group."), después de que, a falta de mejores palabras, se enojara por la forma en que XHTML 2 parecía estar siendo guiado. Su objetivo era evitar sacar al bebé del agua del baño. Continuar y ampliar el desarrollo de HTML, a través de tres especificaciones: Web Forms 2.0, Web Apps 1.0 y Web Controls 1.0.

Las dos reglas de oro

Este nuevo grupo abarcaría dos principios fundamentales:

  1. La compatibilidad con versiones anteriores es algo primordial. No se debe ignorar la web existente.
  2. Las especificaciones y las implementaciones deben coincidir entre sí. Esto significa que la especificación debe ser increíblemente detallada (por lo tanto, las 900 páginas).

"Por lo tanto, el grupo de trabajo Web Hypertext Applications Technology tiene la intención de abordar la necesidad de un entorno de desarrollo coherente para las aplicaciones web. Con este fin, el grupo de trabajo creará especificaciones técnicas destinadas a su implementación en navegadores web con una amplia cuota de mercado, en particular Safari, Mozilla y Opera." - WHATWG.org

Analizador

No subestimes lo significativo que fue este logro.

Mientras que XHTML 2.0 tenía la intención de aplicar un XML perfecto, en su lugar, el Grupo de Trabajo WHAT se encargó de documentar exactamente cómo es HTML y cómo debe ser analizado. – ¡una tarea de cinco años!

¿Recuerdas cuando discutimos sobe cómo los navegadores realizan un excelente trabajo compensando los errores de tu marcado? Lo interesante es que, antes de la creación del WHAT Working Group, no había ninguna especificación que proporcionara instrucciones a los proveedores de navegadores sobre cómo lidiar con los errores. Esto naturalmente lleva a la pregunta: ¿cómo logran los navegadores hacer coincidir la gestión de errores entre sí? La respuesta es a través de la incansable, aunque esencial, ingeniería inversa. Firefox, Safari y Opera copiaron la implementación de Internet Explorer, e Internet Explorer la gestión de ingeniería inversa de Netscape.

En el transcurso de cinco años, el WHAT WG trazó lo que ahora se conoce como el analizador HTML5. No subestimes lo significativo que fue este logro. Hoy en día, todos los navegadores modernos analizan HTML de acuerdo con las directrices de esta especificación. Aunque tal vez no de forma tan sexy como, por ejemplo, canvas, el analizador HTML5 es un increíble logro.


Una línea en la arena

Como podrías esperar, se marcó una línea imaginaria sobre el terreno. Estás del lado de XHTML2, o lo estás de lo que eventualmente se acabaría convirtiendo en HTML5.

En lugar de un enfoque basado en el consenso, donde los miembros debatiesen y votasen sobre lo que consideraban mejor, el WHAT WG adoptó una postura similar a la de un dictador, con Ian Hickson al frente.

Espera – ¿¡Dictador!?

¿No solemos intentar saltar por encima de estos fanáticos del poder?

¿No solemos intentar saltar por encima de estos fanáticos del poder? ¿Cuál es el trato? Debo admitir que, sobre el papel, suena horrible, ¿no? ¿Hay un tipo determina el futuro de la web? ¿Preferimos este sistema? Hablando desde un punto de vista político, sí, una dictadura podría ser una mala idea. Pero, si lo plantea desde la perspectiva de la web, imagina en qué medida se podrían haber hecho las cosas mucho más rápido. Cuando una comunidad es tan apasionada como la nuestra, las cosas tienden a moverse muy lentamente, ya que los debates se mantienen continuamente abiertos... y así continúan indefinidamente.

"La web está, y debería estar, impulsada por el mérito técnico, no por el consenso. El W3C pretende lo contrario, y pierde mucho tiempo en ello. El WHATWG no lo hace." - Ian Hickson

Mientras que ciertamente, y con razón, la discusión tenga lugar en el WHAT WG, en última instancia, Ian Hickson tiene el dedo sobre el botón (a menos que el grupo y la comunidad no estén de acuerdo con una decisión concreta. En este punto, podría ser destituido (no como Bill Clinton), o, más posiblemente, volvería a evaluar y revertir su decisión).

Dicho esto, ciertamente no es lo ideal. El W3C tiene su enfoque lento y constante basado en el consenso, que muchos todavía prefieren. Por otro lado, aunque WHAT WG se mueve a un ritmo más rápido, sin duda se dan ciertos contratiempos. Por tanto, cuando combinas los dos grupos, ¡a veces las cosas pueden ponerse un poco embarradas!

La debacle de time

En octubre de 2011, Ian Hickson eliminó la etiqueta <time> y la reemplazó por una solución con un propósito más genérico: <data>. En sus propias palabras:

Existen varios casos de uso para <time>:

  1. Aplicación de estilo más sencilla de las fechas y las horas con CSS.
  2. Una manera de marcar la fecha/hora para un artículo (por ejemplo, para conversión a Atom).
  3. Una forma de marcar las horas y fechas de forma que sean legibles por máquinas para ser usadas en microformatos o microdatos.

Los casos de uso A y B no parecen tener mucha tracción. El caso de uso C es aplicable a más situaciones que únicamente a fechas, y la falta de solución para cosas que no sean fechas y horas está siendo problemática para muchas comunidades.

Propuesta: descartamos los casos de uso A y B, y pivotamos <time> en el caso de uso C, cambiándolo y haciéndolo como los <abbr> para datos legibles por máquinas, principalmente para ser usado por microformatos y la función de microdatos HTML. – Ian Hickson

Recuerda: ¡tú tienes mucho más control sobre como se moldea la web de lo que probablemente seas consciente!

De lo que posiblemente no se dio cuenta es de que, de hecho, gran parte de la comunidad usa la etiqueta <time>. Además, ellos (yo mismo incluido) consideraron que, aunque más flexible, la etiqueta <data> propuesta era demasiado ambigua; <data> tiene tanto significado como lo pueda tener un <span>, desde el punto de vista semántico.

Tras un significativo nivel de alboroto en la comunidad, el WG HTML anunció que el cambio de <time> debía ser revertido. Proporcionaron a Ian un breve plazo para hacer la reversión. Aunque no sin drama adicional, al mes siguiente, <time> fue restablecido.

Esta cadena de sucesos demuestra que, sencillamente, a pesar de que Ian tiene el derecho de proponer este tipo de cambios, la comunidad web en su conjunto y, por supuesto, los proveedores de navegadores, tienen también algún control sobre la especificación. Hay una diferencia entre los creadores de especificaciones y los autores que integran estos nuevos elementos y las APIs en sus proyectos. Si los autores no los utilizan, también podrían ser eliminados de las especificaciones. Recuerda: ¡tú tienes mucho más control sobre como se moldea la web de lo que probablemente seas consciente!

¡Regístrate en las diversas listas de correo y sé fuerte! De lo contrario, la gente como Ian no sabrá si usas estas nuevas características, o cómo lo haces.

"¿Hay algún dato que muestre cómo usa la gente <time> realmente en la práctica? es decir, ¿está realmente proporcionando a alguien cualquiera de sus hipotéticos beneficios?" – Comentario de Ian Hickson

La forma de una especificación

Mientras que algunos podrían pensar que un pequeño grupo de personas determinan el futuro de la web, eso está lejos de la realidad. Cuando se trata de especificaciones, intervienen tres facciones con el mismo peso.

  1. Creadores de especificaciones – Obviamente...
  2. Autores – Personas como nosotros; si rechazamos (es decir, no usamos) un elemento o API en particular, también podría acabar muerto en el agua.
  3. Proveedores – Los navegadores tienen una gran cantidad de inputs en estas especificaciones, y muchas veces lideran el camino.

Si quieres obtener más información sobre la debacle <time>, revisa el hilo de errores y la publicación de Google+ de Ian. Son lecturas interesantes, y no están tan polarizadas como podrías pensar.


De vuelta al W3C...

Volviendo a la contienda entre W3C y WHAT WG. Bueno, no fue tanto una disputa, fue más bien dos grupos ignorándose entre sí durante un par de años.

A medida que iba transcurriendo el tiempo, se hizo cada vez más claro que XHTML 2.0 no era la solución.

Mientras que el trabajo en el WHAT WG progresaba relativamente rápido, el trabajo en XHTML 2.0 que realizaba W3C era, ¿cómo podría explicarlo..., no marchaba bien (era casi inexistente). A medida que avanzaba el tiempo, se hizo más evidente que XHTML 2.0 no era la solución (aunque no se dejó caer por completo hasta 2009). En 2006, el W3C cedió, y señaló que estaban interesados en colaborar con el WHAT WG en (lo que sería) HTML5. Fundaron otro grupo para este propósito: HTML WG, o el Hypertext Markup Language Working Group (Grupo de trabajo de lenguaje de marcado de hipertexto).

Tenían la intención de utilizar el trabajo de WHAT WG como base para el desarrollo continuo de HTML. Extraño, ¿eh? Ahora tenemos dos grupos distintos: el W3C HTML WG y el WHAT WG. Técnicamente, el W3C aún no había renunciado a XHTML. Sin embargo, como parte del WG HTML recién formado, cambiaron el nombre de Web Apps 1.0 a HTML5.

"Apple, Mozilla y Opera permitieron que el W3C publicara la especificación bajo los derechos de autor de W3C, manteniendo una versión con la licencia menos restrictiva en el sitio de WHAT WG." – WHATWG.org

Actualmente

En estos días, WHAT WG y W3C colaboran juntos en HTML5. Es una relación un poco extraña, pero de alguna manera se las arreglan para funcionar, gracias a un suministro interminable de activistas increíblemente apasionados.

Este artículo es un extracto de mi próximo libro sobre HTML5 y sus amigos. ¡Mantente atento a Tuts+ para obtener más información sobre la fecha de lanzamiento!

Advertisement
Did you find this post useful?
Want a weekly email summary?
Subscribe below and we’ll send you a weekly email summary of all new Code tutorials. Never miss out on learning about the next big thing.
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.