Diseño


12
Ago 09

Problemas con los microformatos

Leyendo recientemente un artículo de A List Apart sobre HTML 5 y sus nuevas capacidades semánticas, me encontré con el caso de la BBC donde decidió eliminar los microformatos de calendarios (hCalendar) de sus páginas de listado de programación. Y es curioso y alarmante el por qué.

El microformato hCalendar incrusta fechas y eventos basados en iCalendar. La BBC usaba además el patrón de diseño sobre el tag ABBR, para incluir información relevante para parsear automáticamente alrededor de información para humanos. Por ejemplo:

<p>Mi cumpleaños es el <abbr class="dtstart" title="20090814">14 de Agosto</abbr></p>

Lo anterior es un ejemplo de microformato hCalendar incrustado en un ABBR tal como usaba la BBC.

¿Por qué es malo esto y por eso dejó de usarlo la BBC?

Pues básicamente, y sorprendentemente, por cuestiones de usabilidad.

Resulta que los microformatos, al usar el atributo “title” para almacenar los metadatos, expone visiblemente los mismos al usuario como efecto secundario. El atributo “title” en algunos elementos es visible al pasar el ratón por encima en forma de “tooltip”. Por ejemplo en los enlaces <a title="Título visible">, etc. Además, resulta que los programas que leen la pantalla para personas discapacitadas como ciegos, etc, LEEN el contenido del tag title, con lo cual una persona que use un lector de pantalla a voz y pase por el ejemplo anterior diría “Mi cumpleaños es el veinte millones noventa mil ochocientos catorce catorce de agosto”.

El artículo de A List Apart es especialmente interesante porque cuestiona en cierta forma a HTML 5. Usa el caso de la BBC para exponer sus argumentos, que son los siguientes:

Semántica estricta en HTML 5

HTML 5 marca un hito en los estandares de la red, entre otros por añadir una semántica más estricta en los elementos. Aparecen tags del tipo section, nav, etc, que se pueden usar en lugar de div para añadir semántica al contenido. El artículo cuestiona dos aspectos con gran convicción:

  • La compatibilidad con navegadores antiguos.
  • La futura expansión semántica del lenguaje.

Es decir, se cuestiona el antes y el después de HTML 5. El problema con los navegadores antiguos es grave, aunque se limita a los navegadores de Microsoft éstos representan un amplio porcentaje de los clientes existentes.

Por ejemplo, Internet Explorer (en cualquier versión) no soporta los estilos sobre los nuevos elementos. Por ejemplo:

<style type="text/css">
    section { color: red; }
</style>
<section>
    <h1>Esto es la sección principal.</h1>
</section>

La cabecera anterior no saldrá en rojo en Internet Explorer, ya que no aplica los estilos a los elementos que no conoce. Ya hay una solución en JavaScript para esto, como no, pero evidentemente es un gran problema ¿cómo puede un estandard moderno introducir nuevos “hacks”? ¿No tenemos bastante con los hacks existentes para CSS en Explorer?

El otro punto de interés es la futura ampliación de la semántica. El autor se basa en que los elementos existentes no son suficientes para dar intención semántica en general, y el lenguaje no permite ampliar dichos elementos. Por ejemplo, HTML 5 introduce elementos como <section>, <header>, <aside>, <figure>, que amplían las posibilidades semánticas, pero el artículo se cuestiona con razón que quizá son pocos elementos y la amplitud que abarca esta apertura semántica es insuficiente.

Como ejemplo, el mismo autor plantea una posibilidad que sería ampliar la semántica del lenguaje en lugar de mediante los tags, por los atributos de éstos. Por ejemplo, mediante <ul navigation="main"> o algo por el estilo.

Os recomiento otros posts del mismo autor para saber más.


16
Ene 09

La misteriosa “degradación de color” en Photoshop

Hace tiempo que vengo dándole vueltas a un problema que se produce en Photoshop usando la opción “Grabar para Web”. Diseñando páginas web es una opción de Photoshop que uso cada dos por tres. Al guardar en JPG o GIF los trozos de la página se produce una degradación de color, o “color shift” como se dice en inglés. El resultado de esto es que en muchas imágenes el color no es ni parecido al original. Unas veces es más evidente, pero otras sólo lo observas cuando contrastas el GIF con el color puro en hexadecimal (Ej: #FFEE00) del fondo.

Esto es problema claramente del manejo de color de Adobe, para web deberíamos trabajar sin gestión de perfiles de color ya que se requieren valores absolutos al mezclarlo con el HTML. El ejemplo que he puesto arriba es claro, si exporto una imagen GIF que tiene que contrastar con un color de fondo tal que #FFEE00, todos los pixeles del borde del GIF tienen que tener exactamente ese valor, sino se notará un contraste.

Por fín encontré un post interesantísimo sobre este problema y una solución definitiva (que consiste en… o sorpresa… desactivar los perfiles de color) :-)

The Mysterious “Save for Web” Color Shift

Está en inglés, pero leedlo con atención quien esté involucrado en diseño web y haya experimentado este problema.