La World Wide Web nació cerca de Ginebra (Suiza) en el CERN, el laboratorio europeo de física de partículas. Su principal creador fue Tim Berners-Lee (nacido en Londres en 1955), que propuso en marzo de 1989 la creación de un sistema de hipertexto para facilitar el intercambio de información entre los investigadores del CERN. El primer servidor web de la historia se instaló en el CERN en diciembre de 1990. En el verano de 1991, este sistema (servidor y navegador) se puso a disposición de todos los usuarios de Internet. El 20 de abril de 1993, el CERN anunció oficialmente que la licencia del software del navegador y del servidor sería el dominio público, permitiendo su expansión sin límites.
El éxito de la web impulsó la creación en 1994 del W3C (World Wide Web Consortium), organismo formado por empresas y universidades de todo el mundo. El W3C se organiza en grupos de trabajo, en los que las empresas y organismos interesados desarrollan por consenso especificaciones que, una vez publicadas, reciben el nombre de recomendaciones.
El W3C está presidido por Berners-Lee y su objetivo es conducir la web a su pleno desarrollo, asegurando su estabilidad. El éxito de la web como espacio compartido de información y entretenimiento ha hecho necesario ir ampliando las capacidades de la web. Para conseguirlo, el W3C ha publicado un gran número de recomendaciones, que pueden consultarse en la web.
Pese al extraordinario desarrollo y utilización de la web, su breve historia está llena de crisis, pasos atrás y conflictos enquistados. Los usuarios de la web y las pequeñas y medianas empresas están interesados en que existan unas normas comunes que permitan la interoperabilidad y la competencia, pero las empresas que dominan un mercado suelen preferir que no existan normas comunes para que sus productos se conviertan en la norma "de facto" y asegurar su dominio. En función de su control del mercado, algunas empresas han cambiado varias veces de bando y seguramente lo seguirán haciendo en el futuro.
El W3C tiene sedes en varios países. Desde octubre de 2003, existe una oficina española del W3C, con sede en Asturias. Entre otras cosas, mantienen una lista de recomendaciones del W3C traducidas al español.
El W3C no es el único organismo que juega un papel en el desarrollo de la web. La IETF (Internet Engineering Task Force) se ocupa desde 1986 del desarrollo de la arquitectura de Internet y publica las normas que definen los protocolos empleados en Internet. Por razones históricas, estas normas reciben el nombre de RFC, Request For Comments. La IANA (Internet Assigned Numbers Authority) se ocupa desde 1972 de la asignación de direcciones a cada ordenador conectado a Internet.
En junio de 2004 los principales fabricantes de navegadores crearon el WHATWG (Web Hypertext Application Technology Working Group), un grupo independiente del W3C que de hecho es el que desarrolla desde entonces el HTML, aunque el W3C publicó hasta 2017 recomendaciones con números de versión (HTML 5, 5.1 y 5.2) basadas en el trabajo del WHATWG.
En mayo de 2019 el W3C y el WHATWG firmaron un acuerdo por el que el W3C dejaba en manos del WHATWG el desarrollo del HTML, del DOM y de algunas APIs. El W3C continúa teniendo a su cargo el desarrollo de las CSS, de muchas APIs y del resto de tecnologías relacionadas (accesibilidad, WebAssembly, SVG, WebFonts, etc.).
En julio de 2023 el W3C publicó el documento Vision for W3C para exponer sus valores e intenciones, documento que se complementa con el documento W3C TAG Ethical Web Principles, que trata sobre los valores éticos que guían al W3C.
Tim Berners-Lee presentó su propuesta de sistema de hipertexto el 12 de marzo de 1989 y por ello el W3C celebra el cumpleaños de la web el 12 de marzo.
En abril de 2013, para conmemorar los 20 años de la web, el CERN abrió una web de homenaje a la primera web, que se puede visitar de nuevo.
En febrero de 2019, el CERN publicó un simulador del navegador WorldWideWeb de 1990 y un sitio web dedicado a la historia de este navegador, con el que se puede intentar visitar páginas actuales (mediante el menú Document > Open from full document reference). Tenga en cuenta que el navegador sólo admite las etiquetas del primer HTML (nada de imágenes u hojas de estilo, por ejemplo).
Proceso de elaboración de las recomendaciones del W3C
El proceso de elaboración de recomendaciones del W3C es un proceso largo que permite obtener documentos fruto del consenso entre los diferentes actores implicados. El proceso de elaboración se describe en W3C Process Document y los distintos tipos de documentos.
Antes de llegar al estado de recomendación (REC), los borradores pasan por una fase no oficial (ED) y tres fases oficiales de elaboración (WD, CR y PR). Los proyectos descartados antes de convertirse en recomendaciones pueden publicarse como WGN y las recomendaciones que dejan de estar en vigor por un motivo u otro se consideran ORS.
ED (Editor's Draft): Borrador del Editor
WD (Working Draft): Borrador de grupo de trabajo
CR (Candidate Recommendation): Candidata a Recomendación
En el proceso de elaboración los documentos van avanzando a lo largo de las cuatro primeras fases, aunque también pueden retroceder a fases anteriores. En la fase de borrador del editor se suelen publicar muchas versiones puesto que no tienen que pasar por la aprobación del grupo de trabajo. En las fases de borrador o candidata se suelen publicar varias versiones del documento. Los documentos que merecen ser difundidos pero que, por algún motivo, no consiguen alcanzar la fase de recomendación se suelen publicar como Notas del grupo de trabajo (Working Group Note).
En marzo de 2017 el W3C añadió tres posibles estados más, pensados para las recomendaciones que el W3C no quiere que se sigan utilizando, declarándolas obsoletas, anuladas o reemplazadas:
OR (Obsolete Recommendation): Recomendación obsoleta, se utilizará cuando una recomendación no ha sido adoptada por la industria (una recomendación obsoleta podría dejar de serlo si se utilizara en el futuro).
RR (Rescinded Recommendation): Recomendación anulada, se utilizará cuando no haya problemas en ella que no pueden resolverse (como existencia de patentes, etc.).
SR (Superseded recommendation): Recomendación reemplazada, se utilizará cuando haya otras recomendaciones más modernas que el W3C recomiende en su lugar.
En marzo de 2018 se declararon Reemplazadas (Superseded) las recomendaciones de versiones antiguas del HTML (hasta HTML 5) y XHTML.
En septiembre de 2020 el W3C incorporó un modelo de recomendación continua (living documents o Evergreen standards), como hace el WHATWG [información en la wiki del W3C]. Los grupos de trabajo podrán elegir entre dos opciones: mantener la norma en la fase de Candidata a Recomendación (CR) sin llegar a aprobarla, publicando nuevas versiones cuando sea necesario, publicar la norma como Recomendación o publicar nuevas versiones cuando sea necesario [W3C Process Document].
Proceso de elaboración de las recomendaciones del WHATWG
El WHATWG sigue un modelo de desarrollo continuo en el que no existen versiones de las normas, sino únicamente la versión actual, que se modifica continuamente. Cada norma dispone de un repositorio en GitHub en el que se coordina todo el trabajo.
Desde su creación en 2004 hasta 2017, el WHATWG funcionó de manera informal, sin normas escritas, simplemente como espacio de colaboración entre los fabricantes de navegadores. En diciembre de 2017, el WHATWG adoptó una serie de normas de funcionamiento para permitir la incorporación de más entidades.
El WHATG está ahora dirigido por un comité directivo formado por cuatro representantes de los principales navegadores (Google, Apple, Mozilla y Microsoft).
Los grupos de trabajo del WHATWG se llaman WorkStreams. Cada WorkStream suele estar dedicado a una única norma y está dirigido por un Editor (o varios), que es el responsable de la coordinación con el comité directivo.
Las normas de la web
Para que la web funcione, se necesitan tres mecanismos:
la identificación de los recursos disponibles (URI)
reglas de comunicación entre el servidor y el navegador (HTTP)
un formato común para los documentos intercambiados (HTML, XML)
Tanto la identificación de los recursos como las reglas de comunicación son aspectos relativamente estables, mientras que el formato de los documentos ha tenido una evolución más compleja y continúa en desarrollo. A continuación se describen los diferentes estándares que conforman la web.
URI (Uniform Resource Identifier = Identificador Uniforme del Recurso)
El URI de un elemento identifica su posición en la web (su "dirección" web). En un principio se utilizó el término URL (Uniform Resource Locator = Localizador Uniforme del Recurso).
diciembre de 1994: RFC 1738, escrita por Berners-Lee y otros, en la que se detallaban las reglas y características de los URLs.
agosto de 1998: RFC 2396, escrita por Berners-Lee y otros, en la que ya se adoptó la denominación URI, más general y que engloba direcciones absolutas y relativas.
enero de 2005: RFC 3986, escrita por Berners-Lee y otros, que sustituía a la RFC 2396 y que adecuaba las URIs a la internacionalización de los nombres de dominio.
enero de 2005: RFC 3987, escrita por Martin Dürst y Michel Suignard, que definía los IRIs (Internationalized Resource Identifiers = Identificadores de Recursos Internacionalizados), permitiendo la utilización de caracteres Unicode.
El Sistema de Nombres de Dominios (DNS) permite convertir los nombres de dominio (escrito con caracteres) en direcciones IP (numéricas).
noviembre de 1983: RFC 882 y RFC 883, escritas por Paul Mockapetris, en la que se definían el sistema de nombres de dominio y sus protocolos y servidores.
noviembre de 1987: RFC 1034 y RFC 1035, escritas por Paul Mockapetris, que actualizaban y sustituían las RFC 882 y RFC 883.
El sistema DNS sólo permite los caracteres del alfabeto latino, los dígitos de 0 a 9, el punto y el guion (-). En 1986 M. Duerst propuso la internacionalización de los nombres, pero hasta marzo de 2003 no se publicaron las normas RFC 3454, RFC 3490, RFC 3491 y RFC 3492, escritas por Hoffman, Blanchet, Faltstrom y Costello, que definían el sistema IDNA (Nombres de Dominio Internacionalizados para Aplicaciones) para poder interpretar los nombres de dominios con caracteres Unicode.
El sistema IDNA (también llamado punycode) establece las reglas para transformar cadenas Unicode a cadenas de caracteres del sistema DNS. Por ejemplo, la dirección http://www.españa.es se traduce en http://www.xn--espaa-rta.es/.
Desde hace años bastantes dominios permiten ya el uso de caracteres no-ASCII. Por ejemplo, Chile lo permite desde 2005 (ejemplo: www.ñandú.cl), el dominio .cat lo permite desde 2006 (ejemplo: www.fundació.cat) y el dominio .es los permite desde octubre de 2007 (por ejemplo: www.león.es).
Los dominios internacionalizados no han tenido éxito, básicamente por dos motivos:
El primero es que el correo electrónico no admite nombres internacionalizados, lo que puede generar confusión en los usuarios (las direcciones web y de correo electrónico de una misma empresa u organización tienen que ser distintos, con y sin acentos o eñes).
El segundo y más importante es que un timador puede registrar un dominio internacionalizado similar a uno legítimo y atraer incautos a su web que no se han dado cuenta de que la dirección no es la misma (este procedimiento es una variedad de spoofing).
Firefox 1.5, Internet Explorer 7 y Google Chrome desde su primera versión ya admitían nombres de dominio internacionalizados (Internet Explorer 6 no los admitía). Para evitar suplantaciones, los navegadores muestran las direcciones como punnycode si algún carácter no es del idioma del navegador. Por ejemplo la url https://₿.org (en el que se utiliza el carácter unicode del bitcoin ₿) se mostraría como https://xn--4zg.org/.
HTTP (HyperText Transfer Protocol = Protocolo de Transferencia de HiperTexto) y HTTPS (HyperText Transfer Protocol Secure = Protocolo de Transferencia de HiperTexto Seguro)
La web, como cualquier otro servicio de Internet, necesita unas reglas definidas de petición y entrega de la información. Las normas de este protocolo son elaboradas por el IETF HTTP Working Group y son publicadas por la IETF en forma de RFC:
Las versiones iniciales (de 1991 hasta 1996) de este protocolo no llegaron a ser publicadas como norma.
mayo de 1996: RFC 1945, escrita por Berners-Lee y otros, primera versión "oficial" HTTP 1.0.
enero de 1997: RFC 2068, escrita por R. Fielding y otros, que define la versión HTTP 1.1.
junio de 1999: RFC 2616, escrita por R. Fielding y otros, que actualiza el protocolo HTTP 1.1.
junio de 1999: RFC 2617, escrita por J. Franks y otros, que define la autenticación HTTP 1.0.
junio de 2014: RFC 7230 y RFC 7231, escritas por R. Fielding y J. Reschke, que actualizan de nuevo el protocolo HTTP 1.1.
mayo de 2015: RFC 7540, escrita por M. Belshe y otros, que define la versión HTTP 2.
mayo de 2015: RFC 7541, escrita por R. Peon y otros, que define la compresión de cabeceras HTTP.
junio de 2022: RFC 9114, escrita por M. Bishop, que define la versión HTTP 3, protocolo que pasa a trabajar sobre QUIC, basado a su vez en UDP, en vez de trabajar sobre TCP.
La versión HTTP 2 se criticó bastante, sobre todo la precipitación con la que se redactó y aprobó, pero quizás era la única manera de evitar que otros implantaran protocolos alternativos (como SPDY, desarrollado por Google en 2012 para reducir la latencia del tráfico web, pero que tras la publicación de HTTP 2 Google dejó de usar en 2016). [Reportaje de Linux Week News sobre el estado de desarrollo de HTTP 2.0 de marzo de 2014]
A finales de 2018 se empezó a trabajar en una nueva versión de HTTP (HTTP/3 [ref]), basada en UDP y no en conexiones TCP. En junio de 2022, la IETF ha publicado la norma RFC 9114. Se basa en el protocolo QUIC, propuesto por Google en 2013 y normalizado en mayo de 2021 por la IETF con la norma RFC 9000 (complementada por las normas RFC 8999, RFC 90001 y RFC 9002).
Para garantizar la seguridad de las comunicaciones entre el servidor y el navegador, existe una variante de HTTP llamada HTTPS (HyperText Transfer Protocol Secure). El primer navegador en incorporar este protocolo fue Netscape Navigator en 1994. La empresa Netscape desarrolló las primeras versiones del protocolo SSL (Secure Sockets Layer). La primera versión pública fue SSL 2.0, publicada en febrero de 1995, y SSL 3.0, publicada en noviembre de 1996. A partir de entonces, el desarrollo de este protocolo pasó a la IETF, que lo rebautizó como TLS (Transport Layer Security).
A medida que ha ido creciendo la preocupación por la privacidad de las comunicaciones y que iniciativas como Let's encrypt han abaratado la adquisición de certificados, los sitios web están pasando a usar siempre HTTPS, aunque no se intercambie información personal. Algunas estadísticas (W3Techs, SSL pulse) indican que actualmente (septiembre de 2024), cerca del 85% de los sitios web utilizan HTTPS de forma predeterminada, mayoritariamente con la versión TLS 1.2.
Las normas de este protocolo son elaboradas por el IETF TLS Working Group y son publicadas por la IETF en forma de RFC:
noviembre de 1998: RFC 6101, escrita por A. Freiser y P. Karlton, que define SSL 3.0. Este RFC se publicó en agosto 2011 por su interés histórico.
enero de 1999: RFC 2246, escrita por T. Dierks y C. Allen, que define TLS 1.0.
mayo de 2000: RFC 2817, escrita por R. Khare y S. Lawrence, que define cómo realizar conexiones seguras y no seguras a través del mismo puerto.
mayo de 2000: RFC 2818, escrita por E. Rescorla, que define HTTPS como HTTP sobre TSL.
abril de 2006: RFC 4346, escrita por T. Dierks y E. Rescorla, que define TLS 1.1.
agosto de 2008: RFC 5246, escrita por T. Dierks y E. Rescorla, que define TLS 1.2.
marzo de 2011: RFC 6176, escrita por S. Turner y T. Polk, que prohibe el uso de SSL 2.0 por su falta de seguridad.
junio de 2015: RFC 7568, escrita por R. Barnes y otros, que prohibe el uso de SSL 3.0 por su falta de seguridad.
agosto de 2018: RFC 8446, escrita por E. Rescorla, que define TLS 1.3.
HTML (HyperText Markup Language = Lenguaje de Marcas de HiperTexto)
Una página web es un documento de texto con marcas (también llamadas etiquetas). Las marcas permiten modificar la presentación del documento, incluir elementos no contenidos en el texto (por ejemplo, imágenes), crear hiperenlaces, etc. La utilización de marcas se remonta a los años 60 y su formalización culminó en 1986 con la publicación de la norma ISO 8879:1986 (las normas ISO son de pago), que definía el SGML (Standard Generalized Markup Language = Lenguaje de Marcas Generalizado y Normalizado).
Basándose en el SGML, Berners-Lee creó el HTML, definiendo un conjunto de marcas muy reducido que permitiera su utilización en cualquier sistema operativo y la creación de enlaces de hipertexto. El éxito de la World Wide Web en los primeros años 90 hizo necesario la ampliación de las características del HTML, lo que requería nuevas marcas. Este desarrollo fue impulsado por las empresas que desarrollaban los navegadores (básicamente Netscape y Microsoft) y fue un desarrollo bastante caótico que no se logró encauzar hasta mediados de los 90, con la creación del W3C (World Wide Web).
En noviembre de 1995 la IETF publicó la norma RFC 1866, escrita por Berners Lee y D. Connolly, que define la versión HTML 2.0 y el tipo MIME (Multipurpose Internet Mail Extension) text/html. Esta versión recapitulaba el estado del HTML de 1994 y recibió el nombre de HTML 2.0 para distinguirla de los HTML anteriores, que nunca recibieron nombre oficial. LA IETF dejó de trabajar en este campo en 1996, aunque en junio de 2000 publicó la norma RFC 2854 que resumía y anulaba los RFC anteriores relativos al HTML.
El W3C publicó en enero de 1997 la recomendación HTML 3.2, editada por Dave Raggett. Esta versión incorporó muchas estructuras nuevas al HTML (tablas, imágenes flotantes, applets, hojas de estilo). En diciembre de 1997 se publicó la recomendación HTML 4.0, aunque la versión definitiva HTML 4.0, editada por Dave Raggett y otros, se publicó en abril de 1998 corrigiendo erratas de la primera edición. Los cambios más importantes fueron la incorporación de los frames y la mayor relevancia de las hojas de estilo. En diciembre de 1999 se publicó la recomendación HTML 4.01, que modificaba ligeramente la versión anterior.
En HTML 4.01 se definen tres tipos de documentos: Strict (estricto), Frameset (con marcos) y Transitional (de transición). El tipo Transitional intenta parecerse a las versiones anteriores de HTML, manteniendo el mayor número posible de etiquetas. El tipo Frameset es como el Transitional, salvo que incluye además la posibilidad de crear marcos (frames). El tipo Strict elimina las etiquetas directamente relacionadas con el aspecto visual (como font, s o u).
Con estas recomendaciones, uno de los objetivos del W3C había sido profundizar la separación entre contenido y su presentación, es decir, eliminar del HTML las etiquetas que hicieran referencia directa al formato visual (y almacenar esta información en una hoja de estilo). Pero al mismo tiempo, el W3C tuvo que aumentar el número de etiquetas para dar respuesta a las demandas de los usuarios, cada vez más diferentes. Pero como estas demandas son inagotables, el W3C tomó un camino diferente: el XML. XML (eXtensible Markup Language = Lenguaje de Marcas Extensible) no es un nuevo lenguaje de marcas, sino las reglas para poder crear nuevos lenguajes de marcas compatibles entre sí. En febrero de 1998 se aprobó la recomendación XML 1.0, editada por Tim Bray y otros.
Lógicamente, el siguiente paso fue adaptar el HTML a las exigencias del XML. El resultado se publicó en enero de 2000: la recomendación XHTML 1.0 (Extensible HyperText Markup Language = Lenguaje de Marcas de HiperTexto Extensible), editada por Steven Pemberton y otros, de la que en agosto de 2002 se publicó la segunda edición. En realidad, XHTML 1.0 no es más que el HTML 4.01 adaptado a las reglas (más formalizadas) del XML 1.0.
Paralelamente, para abordar el problema de la diversidad de aplicaciones, el W3C aprobó en abril de 2001 la recomendación Modularización del XHTML. La idea era dividir el lenguaje en grupos de marcas relacionadas para poder limitar o ampliar el lenguaje, definiendo por ejemplo perfiles xhtml+mathml o xhtm+mathml+svg.
En el camino de la modularización se aprobó en mayo de 2001 la recomendación XHTML 1.1, que apenas modificaba el XHTML 1.0 Strict, pero que se estructura de forma modular. También se aprobaron varias recomendaciones que desarrollaban módulos definidos en la recomendación de modularización, como la Notación Ruby para lenguajes asiáticos.
A partir del año 2002, el grupo de trabajo del W3C dejó de funcionar y aunque formalmente continuaba el desarrollo de la recomendación XHTML 2.0, en la práctica su trabajo se convirtió en irrelevante.
Por desgracia, el paso del HTML al XHTML, que el W3C pensaba que sería inmediato, resultó ser un fracaso. Probablemente, el principal motivo del fracaso fue el problema de los tipos MIME en Internet Explorer (en las versiones anteriores a IE 9), que por aquel entonces era el navegador hegemónico, aunque también es verdad que el requisito de ausencia de errores de sintaxis en el XHTML es un requisito muy exigente, sobre todo en las páginas creadas manualmente.
Los tipos MIME definen tipos de documentos y son la manera en que el servidor le dice al navegador qué tipo de documento le va a enviar. El tipo MIME de los documentos html es text/html mientras que el tipo MIME de los documentos xhtml es application/xhtml+xml . El problema es que los Internet Explorer anteriores a IE 9 no admitían el tipo application/xhtml+xml (definido en la norma RFC 3236, de enero de 2002) y simplemente no mostraban los documentos enviados con este tipo MIME. La alternativa es enviar los documentos xhtml como text/html, pero eso ocasiona multitud de problemas. El más importante es que los navegadores no tratan el documento como xhtml sino como html y por tanto el navegador piensa que el documento está lleno de errores, aunque los navegadores los ignoran y consiguen mostrar la página. Dado que Internet Explorer era el navegador más utilizado, prácticamente nadie enviaba los documentos xhtml con el tipo MIME application/xhtml+xml y como al enviarlos con el tipo MIME text/html se pierden todas las ventajas del xhtml, la conclusión era inmediata: no valía la pena usar xhtml. De hecho, la mayoría de las páginas disponibles en la web que decían ser xhtml, ni eran válidas ni se servían como tal.
Ante este bloqueo que impedía el desarrollo del HTML (el W3C había abandonado el desarrollo del HTML en favor del XHTML pero el mercado -por culpa de Microsoft, especialmente- rechazaba el XHTML), en 2004 se creó el WHATWG (Web Hypertext Application Technology Working Group), un grupo de trabajo informal formado por individuos y empresas (Mozilla, Opera, Apple, Google entre ellas) y dedicado al desarrollo del HTML, sobre todo para facilitar el desarrollo de las aplicaciones Web. Este grupo empezó a elaborar las especificaciones HTML 5 (también llamada Web Applications 1.0), Web Forms 2.0 y Web Controls 1.0, editadas por Ian Hickson, con la intención de que en el futuro se publicaran como recomendaciones del W3C con el nombre de HTML 5.
A finales de 2006, Tim Berners-Lee anunció la creación de un nuevo grupo de trabajo sobre HTML dentro del W3C y la reestructuración de los grupos existentes para reintregar el trabajo del WHATWG.
En marzo de 2007 se creó el grupo de trabajo HTML con la misión de retomar el desarrollo del HTML y con participación de todos los implicados (incluso de Microsoft, que se mantiene al margen del WHATWG, pero que forma parte del grupo de trabajo HTML del W3C desde el verano de 2009). Este grupo adoptó los borradores del WHATWG y desde 2008 publicó regularmente borradores de HTML 5 (en un principio idénticos a los borradores del WHATWG).
En marzo de 2007 también se creó el grupo de trabajo XHTML2 con la misión de continuar el desarrollo del XHTML, pero ese grupo se cerró en diciembre de 2009 sin llegar a publicar la recomendación del XHTML 2.0. XHTML 2.0 se acabó publicando finalmente en 2010 como nota del grupo de trabajo, es decir, como trabajo abandonado.
En enero de 2011, el W3C anunció su compromiso definitivo con el HTML 5 y la intención de publicar la recomendación en 2014. Simultáneamente, el WHATWG anunció que cambiaba su modelo de desarrollo a un modelo de desarrollo continuo, es decir, dejar de hablar de versiones de HTML, llamarlo siempre HTML y que la norma se vaya modificando continuamente (durante un tiempo se publicó un blog dedicado a la evolución de los borradores de HTML, pero lleva años abandonado).
El reparto de papeles (el WHATWG desarrollando continuamente el HTML, los navegadores implementando el HTML del WHATWG y el W3C fijando versiones cada ciertos años), comenzó con buen pie pero que dos grupos distintos pudieran desarrollar su trabajo sin fricciones resultaba sorprendente. Hasta mediados de 2012 el funcionamiento correcto de este modelo de desarrollo se debió en gran parte a que el editor de ambos documentos era la misma persona, el físico suizo-británico Ian Hickson, empleado de Google. Pero en julio de 2012 Hickson dejó de ser el editor del W3C para centrar su trabajo en el WHATWG.
En noviembre de 2016 se publicó la recomendación HTML 5.1. Esta versión no supuso un gran cambio respecto a HTML 5, pero introducía algunos elementos nuevos. En octubre de 2017 se publicó la recomendación HTML 5.1 2ª edición, sin apenas cambios respecto a la primera edición.
En diciembre de 2017 se publicó la recomendación HTML 5.2, que introdujo algún elemento nuevo y eliminó algunos elementos introducidos en HTML 5.1.
En marzo de 2018 se declararon obsoletas y reemplazadas (Superseeded) todas las recomendaciones del HTML y XHTML anteriores a HTML 5.1 y en enero de 2021 se declararon obsoletas y reemplazadas (Superseeded) todas las recomendaciones del HTML del W3C posteriores (HTML 5.1 y HTML 5.2).
El W3C detuvo a finales de 2018 el desarrollo de las recomendaciones HTML 5.3 y DOM 4.1 (ambas fueron publicadas como notas del grupo de trabajo, HTML 5.3 en enero de 2021 y DOM 4.1 en marzo de 2020). El motivo de la paralización fue que el W3C y el WHATWG habían empezado a negociar un acuerdo para unificar el trabajo sobre el HTML, una manera elegante de reconocer que el intento iniciado en 2007 de recuperar el desarrollo del HTML por el W3C había fracasado.
El acuerdo entre el W3C y el WHATWG se aprobó finalmente el 28 de mayo de 2019. Este acuerdo dejó oficialmente en manos del WHATWG el desarrollo del HTML y otras tecnologías asociadas, delimitó el ámbito en el que el W3C ha integrado su trabajo en el WHATWG y establecía un procedimiento de resolución de conflictos.
Así:
El W3C cerró el antiguo grupo de trabajo Web Platform del W3C (copia en archive.org).
El W3C creó un nuevo grupo de trabajo Web Applications para continuar el trabajo sobre las APIs en las que no trabaja el WHATWG.
El W3C creó un nuevo grupo de trabajo HTML para canalizar las aportaciones del W3C al WHATWG y publicar recomendaciones con periodicidad anual, basándose en los Review Drafts semestrales del WHATWG (HTML Review Drafts de diciembre y DOM Review Drafts de junio). Las únicas versiones publicadas han sido DOM 2019-06, publicada en noviembre de 2020, HTML 2020-01, publicada en enero de 2021, y DOM 2020-06, publicada en septiembre de 2021. Probablemente, esto signifique que el W3C ha aceptado por fin que ha perdido el control del HTML.
En cualquier caso, desde el verano del 2019 se debe considerar que el HTML es el lenguaje de marcas definido por la norma HTML Living Standard del WHATWG, sin relación ya con el W3C.
CSS (Cascading Style Sheets = Hojas de estilo en cascada)
Las hojas de estilo es el mecanismo elegido por el W3C para separar la presentación de una página web de su contenido. En las primeras versiones del html, el aspecto visual (tipos de letras, colores, etc) se incorporaba en la propia página web. Trabajando con hojas de estilo, la página web (el fichero .html) no contiene información sobre la forma de representar la página, sino que esa información se encuentra en la hoja de estilo (el fichero .css). Las ventajas son evidentes: se asegura la uniformidad del diseño (ya que varias páginas pueden utilizar la misma hoja de estilo) y se facilita su modificación (ya que sólo hay que cambiar el diseño en la hoja de estilo). Se denominan Hojas de Estilo en Cascada, porque la información de estilo se puede situar en varios lugares (hoja de estilo externa, hoja de estilo incluida en la página web o estilos incluidos en las etiquetas de la página web) y se aplican de forma jerárquica.
En diciembre de 1996 se aprobó la recomendación CSS nivel 1, editada por Håkon Wium Lie y Bert Bos. En mayo de 1998 se aprobó la recomendación CSS nivel 2, editada por Bert Bos y otros, que manteniendo la compatibilidad con las hojas de estilo de nivel 1, incluía nuevas características (posicionamiento, estilos de tablas) y permitía la utilización de hojas de estilo adaptadas al medio de presentación (visual, oral, impreso, etc). En enero de 1999 y abril de 2008 se aprobaron versiones revisadas que básicamente corregían erratas y errores menores.
Como en el caso del XHTML, aunque por razones distintas, el grupo de trabajo sobre hojas de estilos prácticamente dejó de funcionar durante unos años. En el año 2001 Microsoft se hizo con más del 90% del mercado de los navegadores y dejó de sacar nuevas versiones de Internet Explorer. Internet Explorer 6 fue el navegador hegemónico hasta 2008 y su implementación de la recomendación CSS nivel 2 era pésima (no solamente no implementaba muchas características de la recomendación, sino que implementaba otras muchas al revés de lo que decía la recomendación). En esas condiciones, no tenía sentido continuar desarrollando nuevas recomendaciones cuando la antigua no se utilizaba.
Entre el año 2000 y el 2010, el grupo de trabajo siguió trabajando preparando muchas recomendaciones, pero en la práctica apenas se publicaron algunos borradores, a un ritmo lentísimo
la recomendación CSS 2.1, una "puesta al día" de la recomendación CSS nivel 2, corrigiendo erratas, eliminando aspectos que los navegadores no habían incluido y añadiendo aspectos que sí. La recomendación se publicó finalmente en junio de 2011.
unas versiones reducidas de CSS 2 para teléfonos móviles, televisión e impresoras, que se acabaron publicando en octubre de 2014 como notas del grupo de trabajo por falta de interés real en ellas.
la recomendación CSS nivel 3, con un enfoque distinto a las anteriores. En vez de elaborar una única recomendación como en las versiones anteriores, las diferentes partes se separaron en recomendaciones distintas (más de 30), en teoría para facilitar su actualización.
Con la aparición del navegador Firefox en 2004, comprometido con el cumplimiento de las recomendaciones del W3C, y su uso creciente, Microsoft se vio obligado a actualizar Internet Explorer y mejorar el cumplimiento de las recomendaciones. En marzo de 2009 Microsoft publicó Internet Explorer 8 que ya cumplía correctamente la recomendación CSS 2, uniéndose al resto de navegadores que ya lo hacían (Firefox, Opera, Chrome, etc).
A medida que los navegadores fueron cumpliendo CSS nivel 2, el ritmo de trabajo se fue recuperando, y se han ido publicando algunas recomendaciones CSS 3 (en algunos casos, incluso varias versiones, en esta lista se indica únicamente la última versión publicada):
noviembre de 2013: CSS Style Attributes, editada por Tantek Çelik y Elika J. Etemad.
Paralelamente, desde 2015 se han ido publicando CSS Snapshots, notas del grupo de trabajo que resumen el estado de las distintas recomendaciones CSS. La última versión disponible se publicó en diciembre de 2023, CSS Snapshot 2023, editada por Tab Atkins Jr. y otros.
En abril de 2016 se empezó a trabajar en CSS 2.2, otra actualización de CSS 2 para ajustar la recomendación a su implementación por los navegadores.
En septiembre de 2018 se declaró obsoleta y reemplazada (Superseeded) la recomendación CSS nivel 1.
Actualmente (septiembre de 2024) continuamente se publican nuevos borradores de trabajo de las futuras recomendaciones CSS 3 (y algunas CSS nivel 4, 5 e incluso 6), pero las versiones definitivas tardarán años en publicarse al ritmo actual. Para consultar las novedades sobre la elaboración de las recomendaciones, se puede consultar el agregador de noticias del grupo de trabajo CSS del W3C. Las lecciones Recomendaciones CSS estables y Recomendaciones CSS inestables contiene enlaces a las recomendaciones CSS3 aprobadas, a los últimos borradores publicados y a los borradores de los editores. La distinción entre CSS estables e inestables se basa en lo establecido en la clasificación de recomendaciones CSS en CSS Snapshot 2023.
JavaScript, DOM y Web APIs
JavaScript es el lenguaje de programación diseñado para ser incluido dentro de las páginas web. Para facilitar el acceso y manipulación de los elementos de las páginas web a cualquier lenguaje de programación (no solamente a JavaScript), el W3C desarrolló un interfaz denominado DOM (Document Object Model = Modelo de Objeto de Documento) que proporciona una representación estructurada del documento y una forma normalizada de acceder a sus elementos y modificarlos.
Desde hace unos años, el W3C ha empezado a normalizar también toda una serie de APIs (Application Programming Interface = Interfaz de programación de aplicaciones), para que JavaScript pueda acceder a los servicios proporcionados por los navegadores. Algunas APIs están normalizadas por el WHATWG.
JavaScript y WebAssembly
JavaScript fue creado por Brendan Eich en 1995 para Netscape y su nombre se debe a que se trata de un lenguaje de script con una sintaxis similar a la del lenguaje de programación Java. Netscape delegó en la ECMA (European Computer Manufacturers Association) la normalización del lenguaje.
Por ello, el nombre oficial del lenguaje es ECMAScript, aunque todo el mundo le sigue llamando JavaScript. Estrictamente hablando, JavaScript debería utilizarse para referirse a la adaptación de ECMAScript incluida por Netscape/Mozilla, de la misma manera que jscript era la adaptación de ECMAScript incluida por Internet Explorer.
Desde 1997, ECMA ha publicado varias versiones de ECMAScript. Desde 2015, ECMA está publicando una nueva versión cada año. Las últimas versiones disponibles son:
junio de 2024: ECMAScript (versión 15) -
html -
pdf
junio de 2024: ECMAScript Internationalization API (11ª edición) -
html -
pdf
junio de 2023: ECMAScript embedded systems API specification (2ª edición) -
html -
pdf
En 2004 se publicó ECMA-357 (conocida también como E4X), una versión de ECMAScript que podía manipular documentos XML, pero que sólo se implementó en Firefox. En 2013 Firefox eliminó su soporte y en 2015 esas normas se retiraron.
En 2013, Firefox implementó asm.js, un subconjunto de JavaScript que puede ser optimizado por los navegadores y al que se puede traducir código escrito en otros lenguajes (sobre todo, C/C++, pero también otros como Perl, Python o Ruby). Este subconjunto se incluyó en ECMAScript 6, por lo que tanto Internet Explorer como Chrome también lo admitían.
En 2015 empezó a desarrollarse WebAssembly, un formato binario gestionado por el intérprete de JavaScript del navegador, pero con una velocidad mucho mayor y que permitirá crear programas escritos en otros lenguajes (inicialmente, C/C++). En 2107 un primera versión de WebAssembly se incluyó en los principales navegadores: Firefox 52 (marzo 2017), Chrome 57 (marzo 2017), Microsoft Edge 15 (abril 2017) y Safari 11 (septiembre 2017).
En agosto de 2017 se creó el grupo de trabajo WebAssembly en el W3C. En diciembre de 2019 el W3C aprobó las tres primeras recomendaciones relacionadas con WebAssembly:
JavaScript y WebAssembly fuera del navegador: Node.js y Wasmtime
Aunque JavaScript se creó para que los programas se ejecutaran en un navegador web, su popularidad ha hecho que se crearan las herramientas para poder ejecutar programas JavaScript fuera de un navegador.
En mayo de 2009, Ryan Dahl presentó Node.js, un entorno de ejecución de JavaScript que aprovecha el motor de JavaScript de Chrome (V8) y que permite ejecutar programas JavaScript como aplicaciones independientes del navegador. En mayo de 2018, el mismo Ryan Dahl presentó Deno, un nuevo entorno de ejecución de JavaScript como Node.js, pero diseñado desde cero para mejorarlo. Actualmente (septiembre de 2024), Node.js sigu siendo más popular de Deno.
En septiembre de 2022, la ByteCode Alliance, una asociación sin ánimo de lucro en la que participan las empresas más importantes de la informática, publicó Wasmtime 1.0, un entorno de ejecución de WebAssembly que permite ejecutar programas WebAssembly como aplicaciones independientes del navegador.
DOM (Document Object Model = Modelo de Objeto de Documento)
El DOM es un interfaz que permite a los programas y scripts acceder y modificar dinámicamente el contenido, la estructura y el estilo de los documentos. El documento puede ser procesado posteriormente y el resultado del procesamiento se puede actualizar en el documento que se está mostrando. La recomendación DOM level 1 trataba sobre documentos HTML y XML. Las recomendaciones DOM level 2 añadieron al nivel 1 nuevos aspectos como el tratamiento de espacios de nombres XML o de eventos. Las recomendaciones DOM level 3 añadieron al nivel 2 nuevos aspectos como el tratamiento de XML Information Set o XML Base.
El W3C publicó 4 versiones de la recomendación DOM entre 1998 y 2015, pero en el marco del acuerdo entre el W3C y el WHATWG de mayo de 2019, el W3C ha dejado el desarrollo del DOM oficialmente en manos del WHATWG y el W3C integrará su trabajo en el WHATWG.
Así pues, la norma actual sobre DOM es la norma DOM Living Standard del WHATWG. Aún así, el W3C sigue teniendo la intención de publicar recomendaciones sobre el DOM con periodicidad anual, basándose en los Review Drafts semestrales del WHATWG (DOM Review Drafts). Así se han publicado como versiones aprobadas por el W3C el Review Draft del WHATWG de junio de 2019, ratificada por el W3C en noviembre de 2020, y el Review Draft del WHATWG de junio de 2020, ratificada por el W3C en septiembre del 2021.
Desde hace unos años, varios grupos de trabajo del W3C ha normalizado toda una serie de APIs (Application Programming Interface = Interfaz de programación de aplicaciones), para que JavaScript (y otros lenguajes) pueda acceder a todos los servicios proporcionados por los navegadores y otros dispositivos.
Las recomendaciones vigentes publicadas por los grupos de trabajo son las siguientes (pueden consultarse también la lista de recomendaciones reemplazadas):
mayo de 2023: Web Share API, editada por Matt Giuca y otros.
septiembre de 2024: Geolocation, editada por Andrei Popescu.
Actualmente (septiembre de 2024) se están preparando las siguientes recomendaciones (se muestran únicamente las que se encuentran en fase de candidatas (CR) o propuestas definitivas (PR)):
Otras APIs se desarrollan en el WHATWG como normas independientes (la fecha indica la fecha de creación del repositorio, aunque la norma puede estar basada en trabajo anterior del W3C)
El término DHTML (Dynamic HTML = HTML Dinámico) no corresponde a ninguna recomendación del W3C. Es un término comercial utilizado a finales de los 90 para referirse a las páginas webs que utilizaban hojas de estilo y rutinas ECMAScript para aumentar la interactividad. El término ha caído en desuso.
AJAX y Web 2.0
Completar.
Otros lenguajes de marcas
Además del HTML, el W3C ha desarrollado otros lenguajes de marcas, dirigidos a dominios específicos
SVG es un lenguaje de marcas dirigido a la representación de gráficos vectoriales (dibujos y texto) que poco a poco se ha ido imponiendo como formato común para gráficos vectoriales. Muchos editores gráficos permiten exportar los dibujos en formato SVG o incluso trabajan con SVG como formato nativo (por ejemplo Inkscape, un editor con licencia GPL), la suite ofimática LibreOffice trabaja con gráficos SVG y los entornos de escritorio de GNU/Linux GNOME y KDE utilizan el formato SVG como formato gráfico. También cabe destacar la colección de imágenes en formato SVG Open Clip Art Library, con licencia Creative Commons (dominio público).
La versión actual de SVG es la recomendación SVG 1.1 (2ª edición), editada por Erik Dahlström y otros y publicada en agosto de 2011.
Actualmente (septiembre de 2024), el grupo de trabajo lleva años preparando las recomendaciones SVG 2 y SVG Accessibility API Mappings, pero cada vez parece más difícil que este trabajo llegue a buen puerto. Estas recomendaciones estaban previstas inicialmente para finales de 2019, pero ni siquiera se han actualizado esas previsiones, como puede comprobarse en la planificación del grupo de trabajo SVG.
MathML (Mathematical Markup Language = Lenguaje de Marcas Matemático) es un lenguaje de marcas dirigido a la representación de fórmulas matemáticas.
El grupo de trabajo MathML original se cerró en abril de 2016, pero en enero de 2019 se puso en marcha el grupo de trabajo comunitario MathML Refresh Community Group, con el objetivo de actualizar las recomendaciones relacionadas con MathML. A raíz del trabajo realizado por este grupo el W3C ha relanzado en abril de 2021 el grupo de oficial trabajo MathML, con el objetivo de publicar recomendaciones actualizadas.
Se puede consultar el funcionamiento de MathML en Firefox, Internet Explorer y Chrome en la lección sobre MathML.
El grupo de trabajo Math se creó en 1997 (aunque venía trabajando de manera informal desde abril de 1995), se cerró en abril de 2016 y se reabrió en abril de 2021.
El grupo de trabajo MathML ha publicado las siguientes recomendaciones:
abril de 1998: MathML 1.0, editada por Patrick Ion y Robert Miner.
julio de 1999: MathML 1.01, editada por Patrick Ion y Robert Miner, que básicamente corregía errores de la primera versión.
febrero de 2001: MathML 2.0, editada por Robert Carlisle y otros, en la que se introdujeron y eliminaron algunos elementos.
octubre de 2010: MathML 3.0, editada por David Carlisle y otros, en la que se introdujeron algunos elementos (escritura bidireccional, notación para matemáticas elementales, etc.).
Las imágenes pueden almacenarse como imágenes de mapa de bits o como imágenes vectoriales. Dependiendo del contenido y del uso que quiera hacerse de las imágenes, resulta más conveniente utilizar un tipo u otro.
En este apartado se comentan únicamente los formatos PNG y SVG. Otros formatos se comentan en la lección sobre Formatos de imagen.
El formato PNG (Portable Network Graphics = Gráficos de Red Portátiles) se desarrolló en 1994 como alternativa al formato GIF, el más extendido a principios de los 90, cuando la empresa Unysis, poseedora de una patente del algoritmo LZW, empezó a reclamar derechos económicos a los usos comerciales del formato. El nuevo formato PNG fue creado por un grupo informal de desarrolladores y rápidamente adoptado por el W3C.
enero de 1995: versión preliminar propuesta por Thomas Boutell.
Las ventajas de PNG son muchas: se trata de un formato libre, sin pérdida, que consigue mayor compresión que GIF (alrededor de un 20%), con transparencia alfa (cada pixel puede tener su propio nivel de transparencia), canal gamma (para ajustar el brillo) y entrelazado.
En septiembre de 2021 se puso en marcha un grupo de trabajo en el W3C con la intención de publicar una nueva versión de la recomendación PNG a finales de 2024. La intención del grupo de trabajo es ampliar el formato PNG para, por ejemplo, incluir imágenes animadas (imágenes APNG) o para ampliar los sistemas de colores admitidos por el formato (HDR entre otros).
Actualmente (noviembre de 2024), el grupo de trabajo está preparando la recomendación:
En 2009 se desarrolló un formato de fuentes llamado WOFF (Web Open Font Format) pensado para la web. En realidad no se trata de un nuevo formato, puesto que una fuente WOFF no es más que una fuente TrueType, OpenType, Open Font o SVG comprimida y con metadatos para indicar detalles como el origen de la fuente o la licencia.
En abril de 2010, Mozilla, Microsoft y Opera presentaron este formato al W3C, que aprobó la recomendación WOFF File Format 1.0 en diciembre de 2012.
En marzo de 2016 el grupo de trabajo publicó como Nota el WOFF 2.0 Evaluation Report en el que se justificaba la decisión técnica de elegir el uso del algoritmo de compresión Brotli en WOFF 2.0.
En marzo de 2018 se aprobó la recomendación WOFF File Format 2.0, que redujo el tamaño de las fuentes a la cuarta parte, aumentó la velocidad de descompresión y redujo los requisitos de memoria. En julio de 2021, marzo de 2022 y agosto de 2024 se publicaron nuevas ediciones de la recomendación.
Se puede consultar el funcionamiento de las fuentes web en Chrome, Firefox y Edge en la lección sobre Web Fonts.
En octubre de 2020, el grupo de trabajo publicó la nota de trabajo Progressive Font Enrichment: Evaluation Report, evaluando las posibilidades de mejora de las fuentes web para los lenguajes con muchos caracteres (como los lenguajes asiáticos). Las conclusiones de este estudio aconsejan elaborar una nueva recomendación Progressive Font Enrichment que impulsaría el uso de fuentes web en lenguajes asiáticos.
Las últimas versiones de las recomendaciones publicadas por el grupo de trabajo Web Fonts son las siguientes:
Estas recomendaciones pretenden resolver el problema del gran tamaño de las fuentes que incluyen todos los caracteres Unicode definiendo mecanismos para que sea posible descargar las fuentes de forma incremental, a medida que se vayan necesitando nuevos subconjuntos de caracteres.
diciembre de 2021: ARIA in HTML, editada por Steve Faulkner y otros. Esta recomendación sigue el modelo de recomendación continua y se modifica a menudo.
El grupo de trabajo JSON-LD se creó en junio de 2018. Actualmente (septiembre de 2024) es uno de los dos únicos grupos de trabajo relacionados con el XML o la Web Semántica que siguen abiertos en el W3C.
Antiguo Grupo de trabajo Publishing/Audiobooks en el W3C (cerrado):
Homepage -
Charter:
2017-2020 -
2020-2023
Originalmente, el formato EPUB de libros electrónicos fue desarrollado por el International Digital Publishing Forum, que publicó especificaciones entre 1999 y 2017 (bajo las denominaciones Open eBook, Open Publication y finalmente EPUB). En 2017, el IDPF se integró en el W3C, creándose el Grupo de trabajo comunitario EPUB 3, que en mayo de 2019 publicó la versión EPUB 3.2. En agosto de 2020 se creó formalmente el grupo de trabajo EPUB 3 para continuar el desarrollo del formato EPUB. Por otro lado, en 2017 se creó el grupo Publishing para el desarrollo de EPUB 4, aunque en 2020 el grupo se rebautizó como Audiobooks y restringió su trabajo a los audiolibros. Finalmente, En junio de 2023 se cerraron los grupos de trabajo EPUB 3 y Audiolibros para crear el grupo Publishing Maintenance, que se dedicará al mantenimiento de las recomendaciones ya publicadas, pero en principio no a nuevos desarrollos.
El formato EPUB todavía sigue basado en XHTML. Un archivo EPUB es un archivo comprimido ZIP que incluye todos los recursos (texto e imágenes) que componen la publicación junto con las instrucciones para mostrarlos de forma ordenada.
El grupo de trabajo Publishing Maintenance (o los grupos anteriores EPUB 3, Publishing y Audiobooks) ha publicado las siguientes recomendaciones:
El grupo de trabajo Verifiable Claims se creó en abril de 2017 y se cerró en octubre de 2019. El trabajo continuó en el grupo comunitario W3C Credentials Community Group. En 2020 se reabrió el grupo de trabajo para seguir actualizando la recomendación Verifiable Credentials Data Model.
El grupo de trabajo Verifiable Claims ha publicado las siguientes recomendaciones:
Estos son algunos grupos de trabajo, recomendaciones, borradores y notas de trabajo que tengo pendiente de incluir en esta lección o en la lección Otras normas y recomendaciones:
Estos son algunos grupos de trabajo, recomendaciones, borradores y notas de trabajo que tengo pendiente de incluir en esta lección o en la lección Otras normas y recomendaciones: