Historia de la Web: Normas y recomendaciones

La World Wide Web, el W3C y el WHATWG

Fechas de creación de distintos organismos internacionales 1970 1975 1980 1985 1990 1995 2000 2005 2010 2015 2020 2025 IANA IETF Web W3C WHATWG

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.


Enlaces de interés:

Notas:

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.

En elaboración Vigente Obsoleto ED First WD WD CR PR WGN REC O/R/S

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:

Se puede consultar el listado de recomendaciones retiradas. 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:

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)

Fechas de publicación de RFC relacionadas con las URL 1980 1985 1990 1995 2000 2005 2010 2015 2020 2025 DNS URL URI IDNA IRI

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).

El Sistema de Nombres de Dominios (DNS) permite convertir los nombres de dominio (escrito con caracteres) en direcciones IP (numéricas).

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:

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)

Fechas de publicación RFC versiones HTTP 1990 1995 2000 2005 2010 2015 2020 2025 HTTP 1.0 HTTP 1.1 HTTP 1.0 rev HTTP 1.1 rev HTTP 1.1 rev HTTP 2 HTTP 3

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:

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).


Fechas de publicación RFC versiones HTTPS 1990 1995 2000 2005 2010 2015 2020 2025 SSL 1.0 SSL 2.0 SSL 3.0 TLS 1.0 TLS 1.1 TLS 1.2 TLS 1.3

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 (junio de 2023), algo más del 80% 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:

HTML (HyperText Markup Language = Lenguaje de Marcas de HiperTexto)

Grupo de trabajo HTML en el WHATWG: Repositorio

Grupo de trabajo HTML en el W3C: Homepage - Charter: 2019-2022 - 2022-2024

Antiguo Grupo de trabajo Web Platform en el W3C (cerrado): Homepage - Charter: 2014 [archive.org] - 2015-2016 - 2016-2017 - 2017-2019

Fechas de publicación recomendaciones HTML 1990 1995 2000 2005 2010 2015 2020 2025 HTML inicial HTML 2 HTML 3.2 HTML 4.0 HTML 4.01 XHTML 1.0 XHTML 1.01 HTML 5 5.1 5.2 HTML 2020-01

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.

Finalmente, el 28 de octubre de 2014 se publicó la recomendación HTML5: Vocabulario y APIs asociadas para HTML y XHTML. En diciembre de 2014 se publicó la nota diferencias entre HTML4 y HTML5.

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í:

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.

CSS (Cascading Style Sheets = Hojas de estilo en cascada)

Grupo de trabajo CSS en el W3C: Homepage - Charter: 2002-2005 - 2006-2008 - 2008-2011 - 2011-2013 - 2014-2016 - 2016-2019 - 2019-2022 - 2023-2025 (los charters anteriores a 2002 no eran públicos [ref])


Fechas de publicación recomendaciones CSS 1990 1995 2000 2005 2010 2015 2020 2025 CSS 1.0 CSS 2.0 CSS 1.0 rev CSS 2.0 rev CSS 2.1 Snapshot 2015 Snapshot 2017 Snapshot 2018 Snapshot 2020 Snapshot 2021 Snapshot 2022 Snapshot 2023

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

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):

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 (diciembre de 2023) continuamente se publican nuevos borradores de trabajo de las futuras recomendaciones CSS 3 (y algunas CSS nivel 4 e incluso 5), 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

Fechas de publicación normas ECMAScript 1990 1995 2000 2005 2010 2015 2020 2025 JS 1 JS 2 JS 3 E4X 1ª ed E4X 2ª ed JS 5 JS 5.1 JS 6 JS 7 JS 8 JS 9 JS 10 WASM 1.0 JS 11 JS 12 JS 13 JS 14

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 2023: ECMAScript (versión 14) - html - pdf
  • junio de 2023: ECMAScript Internationalization API (10ª 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.


Grupo de trabajo WebAssembly en el W3C: Homepage - Charter: 2017-2020 - 2020-2023 - 2023-2025

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:

Borradores:


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 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, ha publicado 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)

Grupo de trabajo DOM en el WHATWG: Repositorio

Antiguo Grupo de trabajo Web Platform en el W3C (cerrado): Homepage - Charter: 2014 [archive.org] - 2015-2016 - 2016-2017 - 2017-2019

Fechas de publicación recomendaciones DOM 1990 1995 2000 2005 2010 2015 2020 2025 DOM 1 DOM 2 Core DOM 3 Core DOM 4 DOM 2019-06 DOM 2020-06

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.

Por otro lado, el W3C parece mantener el trabajo sobre las recomendaciones UI Events y DOM Parsing and Serialization.

APIs (Application Programming Interface = Interfaz de programación de aplicaciones)

Grupo de trabajo Web Applications en el W3C: Homepage - Charter: 2010-2012 - 2012-2014 - 2019-2022 - 2022-2024

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):

Actualmente (junio de 2023) se están preparando las siguientes recomendaciones (se muestran únicamente las que se encuentran en fase de candidatas (CR) o propuestas definitivas (PR)):


Por su parte, el WHATG se encarga del desarrollo de algunas APIs.

Algunas APIs forman parte de la norma HTML del WHATWG (Repositorio de la norma HTML):

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)

DHTML (Dynamic HTML = HTML Dinámico)

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

Algunos de ellos se siguen desarrollando:

Pero otros se han dejado de desarrollar:

SVG (Scalable Vector Graphics = Gráficos Vectoriales Escalables)

Grupo de trabajo SVG en el W3C: Homepage - Charter: 1998-2000 - 2001-2003 - 2004-2006 - 2008-2010 - 2012-2014 - 2014-2016 - 2017-2018 - 2019-2022 - 2022-2024

Fechas de publicación recomendaciones SVG 1990 1995 2000 2005 2010 2015 2020 2025 SVG 1.0 SVG 1.1 SVG 1.2 Tiny SVG 1.1 (2ª ed) ¿SVG 2?

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 (junio de 2023), 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.

También están disponibles varias recomendaciones auxiliares, muchas de ellas preparadas conjuntamente con el grupo de trabajo de CSS, pero su desarrollo parece abandonado: SVG Parameters 1.0, Part 1: Primer, SVG Parameters 1.0, Part 2: Language, SVG Integration, SVG Markers. Los proyectos de recomendación SVG Color 1.2 (partes Introducción y Lenguaje) parecen abandonados, puesto que hace años que no actualizan los borradores.

Los proyectos de recomendación SVG 1.2 Full, SVG Print 1.2 (partes Requisitos, Introducción y Lenguaje), dirigida a entornos de impresión, fueron retirados.

Se puede consultar más información sobre SVG en la lección sobre SVG.

MathML (Lenguaje de Marcas Matemático)

Grupo de trabajo MathML en el W3C: Homepage - Charter: 1997-1998 - 1998-2000 - 2001-2003 - 2004-2005 - 2006-2016 - 2021-2023 - 2023-2025

Fechas de publicación recomendaciones MathML 1990 1995 2000 2005 2010 2015 2020 2025 MathML 1 MathML 1.01 MathML 2.0 MathML 2.0 (2ª ed) MathML 3.0 MathML 3.0 (2ª ed)

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.

Reflexiones sobre el fracaso de MathML (marzo de 2016): MathML is a failed web standard, de Peter Krautzberger y respuesta de Paul Topping.

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:

Actualmente (junio de 2023), el grupo de trabajo MathML está trabajando en los siguientes borradores:

  • MathML 4.0, editada por David Carlisle.
  • MathML Core, editada por David Carlisle y Frédéric Wang. MathML Core es un subconjunto de MathML pensado para ser implementado en los navegadores.

TTML (Timed Text Markup Language)

Grupo de trabajo Timed Text en el W3C: Homepage - Charter: 2002-2007 - 2008-2011 - 2012-2014 - 2014-2016 - 2016-2018 - 2018-2020 - 2020-2023 - 2023-2025

Fechas de publicación recomendaciones TTML 1990 1995 2000 2005 2010 2015 2020 2025 TTML 1.0 TTML 1.0 (2ª ed) IMSC 1 TTML 2 TTML 1.0 (3ª ed) IMSC 1.2

TTML es un lenguaje de marcas dirigido a la creación de subtítulos.

El grupo de trabajo Timed Text se creó en enero de 2003.

Las versiones actuales de las normas publicadas por el grupo son las siguientes:

El grupo mantiene también la nota del grupo de trabajo siguiente:

Actualmente (junio de 2023), el grupo de trabajo está preparando la recomendación:

Estándares gráficos

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.

PNG

Grupo de trabajo PNG en el W3C: Homepage - Charter: 2021-2023 - 2023-2025 -

Fechas de publicación recomendaciones PNG 1990 1995 2000 2005 2010 2015 2020 2025 PNG 1.0 PNG 1.0 (2ª ed) ¿PNG 1.0 (3ª ed)?

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.

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 (junio de 2023), el grupo de trabajo está preparando la recomendación:

SVG

Véase el apartado SVG en la sección "Otros lenguajes de marcas".

Otros grupos de trabajo

Estos son algunos de los otros grupos de trabajo del W3C:

Web Fonts (Fuentes Web)

Grupo de trabajo Web Fonts en el W3C: Homepage - Charter: 2009-2012 - 2012-2018 - 2018-2022 - 2018-2023 - 2023-2025

Fechas de publicación recomendaciones WOFF 1990 1995 2000 2005 2010 2015 2020 2025 WOFF 1.0 WOFF 2.0 WOFF 2.0

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 reduce el tamaño de las fuentes a la cuarta parte, aumenta la velocidad de descompresión y reduce los requisitos de memoria. En julio de 2021 se publicó una versión corregida de WOFF File Format 2.0

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.

Actualmente (junio de 2023), el grupo de trabajo está preparando las recomendaciones:

Estas recomendaciones pretenden resolver el problema del gran tamaño de las fuentes que cubren 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.

Accesibilidad

Iniciativa Web Accessibility en el W3C: Homepage

Fechas de publicación recomendaciones Accesibilidad 1990 1995 2000 2005 2010 2015 2020 2025 WCAG 1.0 ATAG 1.0 WCAG 2.0 WAI-ARIA 1.0 ATAG 2.0 WAI-ARIA 1.1 WCAG 2.1 WAI-ARIA 1.2 WCAG 2.2

La iniciativa Web Accessibility está dividida en varios grupos de trabajo.

Grupo de trabajo Accessibility Guidelines

Grupo de trabajo Accessibility Guidelines en el W3C: Homepage - Charter: 1997-2000 - 2001-2005 - 2005-2010 - 2010-2015 - 2015-2018 - 2017-2019 - 2019-2023 - 2023-2025

Grupo de trabajo Accessible Platform

Grupo de trabajo Accessible Platform en el W3C: Homepage - Charter: 2015-2018 - 2018-2021 - 2021-2023 - 2023-2025

Grupo de trabajo Accessible Rich Internet Applications (ARIA)

Grupo de trabajo Accessible Rich Internet Applications (ARIA) en el W3C: Homepage - Charter: 2015-2018 - 2018-2022 - 2022-2024

Grupo de trabajo Education and Outreach

Grupo de trabajo Education and Outreach en el W3C: Homepage - Charter: 1998-2001 - 2001-2003 - 2004 - 2005-2008 - 2008-2015 - 2015-2017 - 2017-2020 - 2020-2024


Las últimas versiones de las recomendaciones publicadas son las siguientes:

Notas de los grupos de trabajo:

Actualmente (enero de 2024), los grupos de trabajo están trabajando en los siguientes borradores:

JSON - Linked Data (JSON-LD)

Grupo de trabajo JSON-LD en el W3C: Homepage - Charter: 2018-2020 - 2020-2022 - 2023-2025

El grupo de trabajo JSON-LD se creó en junio de 2018. Actualmente (junio de 2023) es uno de los dos únicos grupos de trabajo relacionados con el XML o la Web Semántica que siguen abiertos en el W3C.

El grupo de trabajo JSON-LD estará dedicado a la actualización de las normas JSON-LD 1.1 A JSON-based Serialization for Linked Data, JSON-LD 1.1 API, JSON-LD 1.1 Framing).

El grupo de trabajo JSON-LD ha publicado las siguientes recomendaciones:

El grupo de trabajo JSON-LD ha publicado la siguiente nota del grupo de trabajo:

Publishing Maintenance (EPUB)

Grupo de trabajo Publishing Maintenance en el W3C: Homepage - Charter: 2023-2025

Antiguo Grupo de trabajo EPUB 3 en el W3C (cerrado): Homepage - Charter: 2017-22 (grupo comunitario) - 2020-2023

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:

Notas del grupo de trabajo:

Autenticación Web

Grupo de trabajo Web Authentication en el W3C: Homepage - Charter: 2016-2017 - 2017-2019 - 2019-2021 - 2022-2024

El grupo de trabajo Web Authentication se creó en febrero de 2016 y ha publicado la siguiente recomendación:

Web of Things

Grupo de trabajo Web of Things en el W3C: Homepage - Charter: 2016-2018 (extendida hasta 2020) - 2020-2022 - 2022-2023 - 2023-2025

El grupo de trabajo Web of Things se creó en febrero de 2016 y ha publicado las siguientes recomendaciones:

Actualmente (diciembre de 2023), el grupo de trabajo Web of Things está trabajando en los siguientes borradores:

Verifiable Claims Working Group

Grupo de trabajo Verifiable Claims en el W3C: Homepage - Charter: 2017-2019 - 2020-2022 - 2022-2024

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:

El grupo de trabajo Verifiable Claims ha publicado las siguientes notas del grupo de trabajo:

Restos

En construcciónEstos 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: