W3C mobileOK Checker

mobileOK Checker es una herramienta excelente con la que podemos chequear la versión móvil de nuestro sitio web. Al igual que las otras herramientas hermanas de la W3C (Markup validation, CSS Validation) nos indica los errores y las alertas del código web. Por cierto, alertas bastante restrictivas debido al XHTML Basic.

También te indicará cuando la página tiene un peso excesivo, no recomendado para los dispositivos móviles.

Conversor de (X)HTML a XHTML Basic

Convert (X)HTML to XHTML Basic nos permite convertir cualquier tipo de documento HTML o XHTML en la versión básica de XHTML. La cual guarda númerosas diferencias con la versión estricta.

En XHTML Basic se pierde cierta semántica, no pudiendo usar por ejemplo elementos como tbody, thead, etc.

XHTML Basic 1.1 doctype

Por último tenemos Mobile Tests, mas que una herramienta se trata de un sitio web con una lista de ejemplos muy interesantes para la adaptación móvil.

Para entender este problema del Internet Explorer 6 (y versiones anteriores) podemos imaginarnos un menú de navegación como el siguiente:

<ul id="navlist">
	<li><a id="current" class="i1" href="#">Item one</a></li>
	<li><a class="i2" href="#">Item two</a></li>
	<li><a class="i3" href="#">Item three</a></li>
</ul>

Lo correcto (sobre todo en términos semánticos) es indicar el atributo id="current" para el enlace que se corresponda a la página activa.

Acceder a este elemento por CSS y poner el enlace en azul sería fácil usando el selector de id:

#current { color: blue; }

Hasta aquí ningún problema, todo sencillo, pero resulta que queremos actuar de forma diferente en cada elemento activo. Por ejemplo poner un color diferente dependiendo de la página activa.
Para esto podemos apoyarnos en las clases de cada elemento creando un selector que combine el ID #current y cada clase .i1, .i2, i3.

#current.i1 { color: blue; }
#current.i2 { color: pink; }
#current.i3 { color: red; }

Todo funciona perfecto… MENOS EN IE 6! (que no lleva nada bien las combinaciones).

Para solucionar esto llevo años usando una técnica que al mismo tiempo mejora el código XHTML.
Se trata de marcar con un ID el elemento que contiene la sección activa id="active".

<ul id="navlist">
	<li id="active"><a id="current" class="i1" href="#">>Item one</a></li>
	<li><a class="i2" href="#">Item two</a></li>
	<li><a class="i3" href="#">Item three</a></li>
</ul>

Y ahora por CSS en vez de combinar ID y clase en un mismo selector, podemos usar el selector #active y cada clase (cascada):

#active .i1 { color: blue; }
#active .i2 { color: pink; }
#active .i3 { color: red; }

El resultado es válido en todos los navegadores y aportamos más semántica al contenido web.

Tipo de documento estricto (Strict Doctype)

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

Hace años yo era de los que apoyaban firmemente la versión transicional (transitional) de XHTML. En aquella época la versión estricta (strict) me parecía algo lejano y que su implementación daba como resultado múltiples y complejos problemas de compatibilidad entre navegadores (que no hacían caso de estándares). Aventurarse en aquellos tiempos con el strict era sinónimo de llegar a menor audiencia y con más problemas.

Ha pasado los años y en la actualidad ya diría que es OBLIGADO implementar la versión estricta. El tiempo ha corrido y las heridas por parte de los navegadores se han curado (parcialmente en algunos casos).

Ventajas de XHTML Strict

  • La versión estricta hace posible una separación completa de la estructura, presentación y comportamiento de un sitio web.
  • Transición hacia un marcado más avanzado y aprovechamiento de las características intrínsecas del lenguaje XML.
  • Strict mejora la accesibilidad web.
  • Aseguramos la compatibilidad con navegadores y dispositivos futuros debido al uso estricto de estándares web.
  • Genera un marcado más elegante, lógico y simple. Lo cual también repercute en un mejor mantenimiento del mismo.

Es increible lo que algunos programadores son capaces de hacer con la librería jQuery. En este caso Damian Wielgosik nos sorprende con Drawter, una potente herramienta (muy bien pensada y diseñada) con la que podemos crear nuestros layouts y obtener el código XHTML & CSS sin escribir ni una sola línea de código, puesto que todo es gráfico y bastante intuitivo.

Continue reading «Diseñar con Drawter (XHTML y CSS)»

Los primeros navegadores MOSAIC y Netscape ofrecieron a los diseñadores la posibilidad de incluir imágenes en las páginas web, así fue como nació la etiqueta <img>.

El W3C opino al respecto y fue en contra de esta iniciativa, ellos promovían el uso de la etiqueta <object> para cualquier elemento (objeto) multimedia.

Posteriormente al elemento IMG llego la tecnológica Future Splas (lo que hoy conocemos como Flash) y varios soportes de vídeo (Quicktime, Real, etc).

Fue entonces cuando la W3C volvió a plantear el uso del elemento OBJECT, pero Netscape hizo oídos sordos y retomo la guerra de los navegadores (ahora contra Internet Explorer) y se saco de la manga el elemento EMBED.

La W3C decía:

  • Para incrustar imágenes, usar <object>
  • Para incrustar flash, usar <object>
  • Para incrustar vídeo, usar <object>

La verdad es que suena más lógico el planteamiento del W3C, pero en la realidad el elemento IMG, EMBED y diferentes soporte propietarios ya se había propagado a millones de sitios web impulsados por diseñadores web ávidos de hacer una red mucho más estética y multimedia (y con razón).

Al final las recomendaciones de la W3C eran totalmente ignoradas, pero esta siguió su ritmo con paso firme, haciendo que las especificaciones no contemplasen el elemento EMBED y que los documentos web en su versión HTML 3.2 (o superior) y XHTML no puedan ser validados correctamente si incluyen este elemento.

Ahora años después y pensándolo en frió, el uso del elemento EMBED carece de sentido. Es un elemento propietario, esta desaconsejado por la W3C y hasta su nacimiento fue absurdo.

Por otro lado no comprendo la razón que tienen buenas plataformas de blogs como WordPress para presentar el elemento EMBED en sus códigos (¿compatibilidad inversa? a estas alturas…). Por suerte contamos con varias técnicas para incrustar vídeo y seguir validando en XHTML.

Por último recordar que también existe el elemento NOEMBED que se encarga de proporcionar un contenido alternativo y accesible a EMBED.

wsp

Me confieso yo era un ex-alumno de la vieja escuela, de esa que te enseñaba a diseñar bonitos efectos, animaciones, botones personalizados, etc. Para luego maquetar ese diseño empleando etiquetas y atributos propietarios, applets de java y tablas complejamente anidadas. Pero sobre todo innumerables horas “perdidas” delante del ordenador.

Continue reading «Breve historia de los estándares web»

Cartel de fundamentos web 2008Recientemente he asistido al congreso fundamentos web 2008, en Gijón (Asturias).

Se trata de un evento organizado por la Fundación CTIC, la oficina española del consorcio W3C, y subvencionado por el Gobierno del Principado de Asturias.

Este evento ha conseguido tras varias ediciones una enorme relevancia internacional, incorporando en sus actos a ponentes de primera fila.

A continuación voy a destacar lo que me ha parecido más interesante.

Continue reading «Fundamentos web 2008»

Los estándares web son una serie de recomendaciones (previamente borradores) dadas por el consorcio W3C y otras organizaciones internacionales como ECMA.

El objetivo que se persigue con ello coincide con el slogan del W3C:

Guiar la web hacia su máximo potencial.

Lo que se traduce en una mejor accesibilidad y usabilidad.

Ya de forma mas personal opino que los estándares web nos abren las puertas al futuro de forma más inteligente y regulada, permitiendo también crear sitios web válidos en cualquier plataforma o agente de navegación.

La trinidad de los estándares web

  1. Estructura
    • HTML
    • XHTML
    • XML
  2. Presentación
    • CSS 1
    • CSS 2
    • CSS 3
  3. Comportamiento
    • ECMAScript
    • DOM

Enlaces relacionados