XHTML 2.0: El futuro de la web y "que no nos pase ná"

Autor: Armonth | El viernes 25 de agosto del 2006 @ 10:00.

Recién hemos salido del cascaron de la guerra de los navegadores, los desarrolladores empiezan a entender las ventajas de un desarrollo utilizando las recomendaciones del W3C, y ahora es cuando se empieza a tomar en serio el XHTML como sustituto del antediluviano HTML 4.01.

Pero la verdad es que el W3C no descansa: el XHTML 1.1 fue publicado el 31 de Mayo del 2001 y desde entonces han estado lanzando continuamente borradores del futuro XHTML 2.0. A los que no les apetezca la idea de tener un nuevo estándar que revisar no se alarmen: el camino a recorrer todavía es largo y en lo personal creo que pueden pasar 3 años más hasta que sea una recomendación y no un simple borrador, los navegadores lo implementen junto a CSS 3.0, etc., (si se trata del IE cambiad 3 años por 10) y soy optimista.

También faltan mínimo 3 años más para que sesudos blogstars empiecen a hablar de las bondades del XHTML 2.0 y del CSS 3.0 para ser el blogger del universo... bromas aparte: El último borrador es de finales de Julio del 2006 y se empiezan a notar algunas diferencias abismales respecto al XHTML 1.0/1.1. Dada su extensión, os ofrezco un índice :)

Resumen / Índice

Compatibilidad hacía atrás

HTML ha sido de los estándares más grandes y liosos: por tener que mantener una compatibilidad hacía atrás, inserción de etiquetas de determinados navegadores y también por mantener "tres ramas" (por así decirlo) del estándar:

  • Versión del estándar estricta (Strict).
  • Versión del estándar para marcos (frameset).
  • Versión para webs en transición (Transitional).

Cuando apareció XHTML 1.1 vimos una ruptura en ese tradicional esquema: XHTML 1.1 no tiene dichas ramas, XHTML 1.1 es solamente uno y siempre es considerado Strict. Como curiosidad decir que en el 99 y tanto % de sitios a validar el único cambio que encontré entre XHTML 1.0 Transitional y XHTML 1.1 fue que lang="" desaparece en favor de xml:lang="".

En XHTML 2.0 se rompe la compatibilidad para atrás lo cual puede ser un gran handicap para su rápida expansión (la migración a XHTML 2.0 sera lenta, eso seguro). Con esta ruptura el estándar sera mucho más pequeño, conciso y especifico, tendrá tendencia a ser más estructurado como XML, eliminará etiquetas de navegadores y se abstrae de ellos para servir mejor en dispositivos alternativos como PDA's.

Validación XML obligatoria

Un punto en que actualmente hay mucha polémica es que con XHTML 2.0 ya no sera trivial hacer una web: Si el XML no valida no hay tú tía. Esto por un lado es bueno: obliga que las webs sean en formato estándar y elimina muchas barreras para el acceso a la información. Por el otro lado, obliga a tener unos conocimientos un poco más avanzados (tampoco se crean, a simple vistazo se entiende).

Artnau comenta que desde XHTML 1.1 los navegadores si no valida se quejan y es cierto pero al poder ponerle de Content-Type: text/html y que no haya quejas (ni navegadores, ni validadores) es poco útil e ideal que sea subsanable en 2.0 para que sea obligatorio "a ser posible sin trucos"...

Adiós Hx y DIV, hola SECTION y H

Los encabezados (<h1>, <h2>, <h3>, <h4>, <h5> y <h6>) son una limitación: ¿Qué pasa si necesitamos más niveles?. Ahora mediante <section> se amplia en forma de árbol de contenidos hasta el infinito y por ello se sustituye por <h> (tal cual, sin número), por ejemplo:

<section>
  <h>Encabezado de primer nivel</h>

  <section>
    <h>Encabezado de segundo nivel</h>
  </section>
</section>

De la misma forma los <div> son sustituidos por <section> aunque todavía no está claro si se podrán seguir usando o no.

Role: Un presunto sustituto de ID

Cuando tengamos una parte de la web que no pertenece al contenido -- por ejemplo: una lista de enlaces de navegación -- podremos utilizar el atributo role:

<ul role="EnlacesNavegacion">
  <li>...</li>
</ul>

Aquí hay una diferencia y si lo he entendido bien es que se usara como si fuera un selector de CSS2, por lo que el CSS sería:

ul [role="EnlacesNavegacion"] {
  list-style: none;
}

Los ID de momento siguen dando guerra pero es otro elemento que se desconoce si desaparecerá o se desaconsejará su uso. Artnau comenta que role más que un sustituto de ID (ya tenía mis dudas, por eso lo de presunto) role es un sustituto de rel.

XFrames: Vuelven los marcos (¡¡arghh!!)

"Malas noticias" (dependerá de implementación), vuelven los frames, por lo que parece está nueva implementación soluciona el problema de las URLs inconsistentes pero aun así me parece que ahí se equivocan y he leído muchas criticas hacía este tema, solamente el tiempo lo dirá.

Toda la información de los Xframes está disponible en el W3C (en inglés).

HREF extendido: Todo puede ser un enlace

El atributo href ya no forma parte únicamente de la etiqueta <a> por lo que puede usarse en cualquier etiqueta, las posibilidades que se me ocurren son muchas por ejemplo las listas de enlaces, pasan de:

<ul>
  <li><a href="link-1">texto del enlace</a></li>
  <li><a href="link-2">texto del enlace</a></li>
</ul>

A:

<ul>
  <li href="link-1">texto del enlace</li>
  <li href="link-2">texto del enlace</li>
</ul>

XML includes

Está me gusta: Se puede incluir contenido mediante ficheros XML sin necesidad de usar el include() de PHP, SSI (Server Site Includes ¿todavía alguien usa esto?), ASP o similares. Un ejemplo es la web de w3future.com donde podemos ver una web con estructura simple en XHTML 2.0, el código de esa web es muy corto y en él se ve:

<section id="navigation">
  <xi:include href="http://w3future.com/w3f/sections.xml" />
</section>

Con la segunda línea (xi:include) podemos añadir includes XML sin necesidad de usar un lenguaje de programación del lado servidor. Todo un lujo para hacer sistemas de plantillas, modificar menús (o cualquier otro contenido que se repita) en múltiples páginas, etcétera.

OBJECT a la palestra

Actualmente es un poco lioso la puesta en escena de distintos contenidos "multimedia":

  • <style> se usa para mostrar ficheros CSS.
  • <img> se usa para mostrar imágenes.
  • <applet> para applets (y dios sabe qué más).
  • <object> para mostrar objetos (habitualmente Flash).

Pues bien, podemos tachar los tres primeros, object se utilizará para todo aunque yo encuentro un poco coñazo la posibilidad de tener que especificar el "MIME" de forma obligatoria. Veamos un par de ejemplos de distintos elementos a mostrar, el código ha sido simplificado ya que por ejemplo al CSS le falta el media="screen":

<object src="screen.css" srctype="text/css"></object>
<object src="foto.jpg" srctype="image/jpeg"></object>
<object src="peli.avi" srctype="video/x-msvideo"></object>

Esperemos pues que el MIME al final no sea obligatorio y por lo tanto se encarguen los navegadores (o el servidor web) de detectarlo. Por cierto, el atributo ALT de las imágenes desaparece y se puede especificar dentro del contenido ya que cualquier etiqueta puede tener el atributo "src=", por ejemplo:

<p src="mifoto.jpg" type="image/jpeg">Está es mi foto.</p>
<object src="mifoto.jpg">Mi foto <em>salgo horrible</em></object>

Poder relacionar una imagen a un texto directamente nos ahorra el atributo ALT, el LONGDESC y añade semantica a la imagen, supongo que esto también ayudará a los motores de búsqueda a darle una mejor relevancía a las imagenes.

Cambios en HR y BR

El salto de línea <br /> parece que va a desaparecer en favor de <line /> y <hr /> en favor de <separator />.

Referencias

Hay otras novedades cómo blockcode para mostrar código (tal y cómo ahora usamos PRE), los XForms sustitutos de los antiguos formularios y eventos en XML para los formularios (me suena a AJAX ¿casualidad o son imaginaciones mías?) pero para ser un resumen no está mal

Comentarios