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 en respecto al XHTML 1.0/1.1. Dada su extensión, os ofrezco un índice :)
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:
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 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.
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).
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.
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 CSS 3, 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.
Malas noticias, 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).
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, de:
<ul>
<li><a href="link-1">texto del enlace</a></li>
<li><a href="link-2">texto del enlace</a></li>
</ul>
Podemos pasar a:
<ul>
<li href="link-1">texto del enlace</li>
<li href="link-2">texto del enlace</li>
</ul>
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.
Actualmente es un poco lioso la puesta en escena de distintos contenidos “multimedia”:
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”.
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 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 ayudara a los motores de búsqueda a darle una mejor relevancía a las imagenes.
El salto de línea <br /> parece que va a desaparecer en favor de <line /> y <hr> en favor de <separator />.
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
Redactor:
Héctor Delcourt
Sitio Web:
http://sigt.net/archivo/xhtml-20-el-futuro-de-la-web-y-que-no-nos-pase-na.xhtml
Versión Imprimible: Ver/Imprimir
Comentarios: Hay
0 opiniones
