Desmitificando HTML5

Cliente: [...] y quiero que la web corporativa se haga en HTML5.
Desarrollador: ¿Necesita algún elemento nuevo de HTML5 en concreto?
Cliente: Uh... Esto... Bueno, quiero que tenga vídeo, gráficas interactivas, todo lo que trae HTML5.
Desarrollador: Sin problema, pero el precio del desarrollo subirá. Los gráficos en HTML5 hay que programarlos igualmente, lo único que en vez de Flash utilizaremos Canvas. Si queremos que el vídeo se vea en todos los navegadores, habrá que hacer diferentes codificaciones: necesitaremos más almacenamiento y hardware más potente para la codificación si hay mucho volumen de vídeos.
Cliente:¿Pero eso no viene ya de serie con el HTML5 ése?
Desarrollador: No, hay que hacerlo igualmente.

Reconozco que esta esta conversación ficticia está un poco traída por los pelos, pretende ser más satírica que otra cosa, pero ilustra un poco la sensación que tengo respecto al HTML5: parece que es la panacea y la solución a todo, la tecnología que finalmente hará de la web un lugar idílico, normalizado y estandarizado,... pero sigue haciendo falta alguien que programe.

Hay muchas novedades y aportaciones en HTML5 que ya han analizado en multitud de sitios, así que no voy a decir nada nuevo. Lo que quiero transmitir con este artículo es que HTML5 no es un milagro tecnológico ni nada similar (se oye demasiado a menudo "¡... y está hecho con HTML5...!", como si fuese lo más de lo más de la innovación y la solución a todos los problemas). Es una evolución (con muchos aciertos y posiblemente, limitaciones) del HTML y así es como los técnicos debemos verla. No nos dejemos llevar por el "hype" de las siglas y de los departamentos de Marketing ;-)

Algunas cosas que me parecen interesantes (en la Wikipedia viene un buen resumen):

• Mejoras semánticas (en mi opinión, casi la novedad más importante). En versiones anteriores, cada bloque en una página no tenía sentido semántico. Es decir, la cabecera, menú, pie de página, etc... eran siempre un
  . Con HTML5 tenemos , , , ...
  Esto parece una tontería, pero es muy importante y tiene muchas aplicaciones:
• Los buscadores pueden identificar rápidamente qué partes de la página son relevantes.
• Los agentes de usuario (navegadores) pueden presentar la página de acuerdo a las instrucciones que le de el usuario, por ejemplo: "ocultar la barra de menús" o "destacar el contenido del artículo", etc.
  Imaginemos un navegador/lector para personas con problemas de visión: cada vez que pasen de página no les leerá el interminable menú de navegación, ni la cabecera, etc. Directamente les leerá el contenido del artículo.
• Se facilita enormemente el intercambio de contenidos entre sitios web (y el "robo" también, todo hay que decirlo). Nuestros scripts ya sabrán qué hay que recoger en una página y qué no.
  
• Por fin se puede mostrar vídeo en el navegador sin necesidad de utilizar un plugin (típicamente, Flash). El problema está en los navegadores: cada uno soporta un formato/codec diferente. Si queremos garantizar que todos los navegadores podrán tratar con nuestro vídeo, hay que preparar múltiples fuentes.
  Ejemplo (c&p de la Wiki ;-)
  
  

  <video poster="movie.jpg" controls>
  <source src='movie.webm' type='video/webm; codecs="vp8.0, vorbis"'/>
  <source src='movie.ogv' type='video/ogg; codecs="theora, vorbis"'/>
  <source src='movie.mp4' type='video/mp4; codecs="avc1.4D401E, mp4a.40.2"'/>
  <p>This is fallback content</p>
  </video>
  
  Si queremos dar soporte a navegadores antiguos que no entiendan el tag , debemos preparar un mecanismo para mostrarles el vídeo a través de un plugin.
  
  

• Lo mismo es aplicable para el audio. Cada navegador funciona diferente.
  
• Gráficos 2D: se estandariza el tag y su API. Un bloque canvas sólo define una región que puede ser "pintada" a través de un script (típicamente Javascript). Nada más (y nada menos).
  Últimamente se ven algunas maravillas como juegos, pruebas de concepto, etc, "programados en HTML5". Error de concepto: están programados en Javascript y se muestran en una página HTML5.
  Hacer cosas en un no es una tarea trivial. En la especificación se definen funciones o métodos de bajo nivel y nada más. Existen bastantes "librerías" de Javascript que facilitan la tarea, pero no son parte de la especificación.
  
• Por fin se simplifican los DOCTYPE (se queda un simple ) y los atributos del tag .

Recuperemos el denostado tag "blink"

Con lo bonito que era el parpadeo de las webs que había en Geocities...

<html>
<head>
<title>¡¡¡Blink!!!</title>
http://ajax.googleapis.com/ajax/libs/jquery/1.6.1/jquery.min.js

function blinkear() {
var blink = $('blink');
    if (blink) blink.toggle();
}
$(document).ready(function () {
    setInterval(blinkear, 700);
});

<style>
blink {color: lime; font-size: 22px;
       font-family: "Comic Sans MS";
       font-weight: bold;}
</style>
</head>
<body>
<blink>El parpadeo es divertido...</blink>
</body>
</html>

 

Conversiones entre "encodings" sin pérdidas

Hace un tiempo comentaba los problemas que surgían cuando se trabaja con diferentes "encoding".
Lo más seguro hoy en día es trabajar con el mismo "encoding" en todas las capas y sistemas: bases de datos, ficheros php, plantillas html, ficheros js, configuración del servidor web, ...
Lo malo es que no siempre esto es posible. Muchas veces tenemos que integrar contenidos o hacer que dos sistemas diferentes interaccionen y cada uno puede estar configurado de diferente manera.
Para estas tareas de conversión, existen muchas herramientas y funciones. Por ejemplo, en PHP tenemos la función iconv(). Es muy sencilla de utilizar:

string iconv ( string $in_charset , string $out_charset , string $str )

El problema que surge a menudo es cuando estamos pasando de un encoding más "rico" (p. ej., UTF-8) a otro más restringido en caracteres (p. ej., ISO-8859-1). Si se aplica la función sin más, se nos puede cortar la cadena que estamos convirtiendo cuando se encuentra con un carácter extraño al "encoding" de destino (las famosas "comillas tipográficas" de los procesadores de texto, por ejemplo, dan muchos problemas).
Afortunadamente, la función iconv() está preparada para estos casos. Si se utiliza el parámetro $out_charset con la cadena //TRANSLIT, los caracteres problemáticos pueden ser convertidos a un carácter similar en el "encoding" final:

$txtFinal = iconv("UTF-8", "ISO-8859-1//TRANSLIT", $txtOriginal);

Enlaces y "popups" accesibles

A veces nos surge la necesidad de forzar que un enlace se abra en una ventana nueva o "popup". El problema es que debemos mantener el HTML válido para que estos enlaces sean seguidos por motores de búsqueda o puedan ser utilizados por navegadores sin Javascript.

En todos los sitios se ve el típico tutorial que dice "... utiliza el window.open() de Javascript ...". Efectivamente, hay que usarlo, pero sin obstruir ni hacer HTML chapucillas.

Vamos a presentar 3 formas de abrir un "popup", una "mala" y dos mejores.

1. Con HTML "guarrete":
   

       onclick="window.open('http://davidasorey.net',
           'popup1', 
           'height=800,width=600,resizable=1,scrolling=1')">Enlace 1

   
   Fatal. El destino de este enlace está "falseado". A veces también nos podemos encontrar algo como:
   

   <a href="void(0)">

   Esta forma de hacer los "popups" puede ser aceptable sólo si explícitamente queremos que este enlace no se siga.
   
   
2. Un poco mejor, dejando un href correcto:
   
   

   <a href="http://davidasorey.net/" target="popup2"
       onclick="window.open('', 
           'popup2', 
           'height=800,width=600,resizable=1,scrolling=1')">Enlace 2</a>
   
   

   Aquí jugamos con el atributo "target". El evento "click" abre una ventana "vacía" pero con un identificador "popup2". Cuando el navegador va a abrir el enlace, ya encuentra una ventana con este identificador y abre el enlace en esta nueva ventana.
   Es una mejora, desde luego: el enlace ya es un enlace "real" e indexable.
   
   
3. Una solución sin Javascript "inline":
   
   

   <a class="popup3" href="http://davidasorey.net/">Enlace 3</a>

   
   Obviamente, esta es la solución más limpia, pero requiere un poco más de trabajo adicional.
   Con jQuery (se puede hacer con cualquier otra librería o "framework") hay que "capturar" todos los enlaces con la clase "popup3" y alterar su comportamiento:
   

   $(document).ready(function (d) {
    $('a.popup3').click(function (e) {
     e.preventDefault();
     var href = $(this).attr('href');
     window.open(href, 
                'popup3', 
                'height=800,width=600,resizable=1,scrolling=1');
    });
   });

   
   En pocas líneas alteramos el comportamiento de todos los enlaces con la clase 'popup3'. Nos ahorramos andar escribiendo el código Javascript en el evento onclick y todo el código y control de este comportamiento está en un sólo punto.

Internet Explorer 8: problemas en clase

El nuevo IE8 lleva unos días disponible en su versión definitiva, y, en la mejor tradición de los navegadores de Microsoft, ya nos está dando quebraderos de cabeza a los diseñadores y desarrolladores web.

Ésta es la página web de Público (www.publico.es) vista en algunos navegadores:

Mozilla Firefox	Opera	Apple Safari
Google Chrome	Konqueror	MS Internet Explorer 6

Como pueden ver, la "cajita" con las previsiones metereológicas se ve bien, tres elementos que internamente son una lista que se crea dinámicamente con JavaScript y a los que se les ha dado estilo con CSS, alineándolos usando la propiedad float y eliminando el "bolo" que suelen tener las listas por defecto.

Todos los navegadores en los que hemos probado hasta ahora muestran este módulo correctamente, incluido el vetusto Internet Explorer 6.

Al probar la página en el nuevo IE8, nos hemos llevado una pequeña sorpresa:

La caja en las que se muestran las previsiones meteorológicas es como si no entendiese los estilos: los elementos de la lista no se muestran alineados horizontalmente y cada uno de ellos muestra el "bolo" típico de las listas. Podría pensarse que es un problema de los diseñadores, que no han sabido maquetar estos elementos correctamente, pero las reglas que han aplicado en este módulo son correctas.

Sin embargo, si activamos el botón de "Vista de compatibilidad", la página se muestra correctamente, como con los demás navegadores, incluido el predecesor, IE7.

Según la página web de Microsoft, "no todos los sitios web están preparados para IE8" -- el original es éste:

"Internet Explorer 8 is a new release and some websites may not yet be ready for Internet Explorer 8".

Tras una breve investigación, al final Rodrigo y Daniel encontraron el problema: IE8 parece que tiene algunas incompatibilidades con una de las librerías de JavaScript más usadas (Prototype), el atributo HTML "class" y la propiedad DOM "className".
Los demás navegadores trabajan bien con el mismo código JavaScript, IE8 no. ¿Quién lo está haciendo bien y quién lo está haciendo mal?

Hasta ahora teníamos que hacer los desarrollos y diseños con tres navegadores: IE6, IE7 y el  resto de navegadores. Ahora tendremos que incorporar otro. Por fortuna, ya hay trucos para forzar a IE8 para que se comporte como su antecesor.

Cada uno a su bola

Escribíamos hace unas semanas sobre lo difícil que es para un diseñador de páginas web conseguir que el mismo diseño se vea igual de bien en todos los navegadores. Hoy ahondamos un poco más en la cuestión.

Para formatear y dar estilo a las páginas web actualmente se utiliza una tecnología llamada CSS (Cascading Style Sheets u Hojas de Estilo en Cascada).
La CSS permite que los elementos de una página web se vean de una forma u otra sin necesidad de tocar el contenido. Esto es una práctica muy aconsejable, puesto que conseguimos separar e independizar por un lado el texto o contenido de la página y por otro la presentación.

Hasta hace unos años, las páginas web se maquetaban y se les daba estilo con etiquetas HTML dentro del texto que no aportaban contenido, si no formato. Afortunadamente, casi nadie trabaja así actualmente.

El problema es que cada navegador interpreta un poco a su aire estas reglas CSS, con lo que surge el problema que comentábamos en la entrada anterior: los diseñadores tienen que saberse un montón de "trucos" para conseguir que la misma CSS sirva para todos los navegadores.

Existe una organización llamada "Web Standards Project" que promueve el uso de estándares y tecnologías compatibles en las páginas web. Se les conoce sobre todo porque han preparado una serie de pruebas para ver si un navegador es compatible e implementa correctamente las especificaciones de los distintos estándares (CSS, HTML, etc).
Esta prueba se llama "Acid Test" y tiene varias versiones, la que se supone que deberían pasar los navegadores actuales es la versión 2 (la versión 1 de la prueba la pasan los 5 navegadores más utilizados (Firerox, Explorer 6 y 7, Opera y Safari).

Vean la prueba Acid 2 en estos cinco navegadores. Lo que el navegador debería mostrar es una carita como ésta:



Y así la muestran ...

Internet Explorer 6


Internet Explorer 7:


Mozilla Firefox:


Opera:


Safari:


La prueba Acid tiene detractores, pero para el propósito de esta entrada nos vale: es sorprendente comprobar cómo los distintos navegadores interpretan las mismas reglas. También es sorprendente cómo los navegadores menos usados (Opera y Safari) son los que mejor implementan las tecnologías web.

Resumen: la próxima vez que Ud. visite una página web en la que se vea algo extraño o descolocado, verifique (si tiene tiempo y ganas, claro) cómo se ve la página con otro navegador, especialmente si usa alguna versión de Internet Explorer.

La pesadilla de los “encoding” (2ª parte)

Decíamos en la anterior entrada que cuando un fichero puede codificarse con UTF-8. Existen dos variantes del formato UTF-8: con BOM y sin BOM. BOM son dos bytes (FE FF) al principio de un fichero que, simplificando mucho, indican el orden de los bytes.
Guárdese un fichero codificado en UTF-8 con el BOM y tendrá problemas con la mayoría de sus scripts en PHP o ficheros XML, ya que el fichero realmente no comenzará como "<?php" o "<?xml".

Imaginen ahora el siguiente entorno de trabajo: un servidor web más o menos moderno que sirve los documentos por defecto con la codificación UTF-8, un desarrollador con una estación de trabajo Windows o Linux y un diseñador con la estación de trabajo Mac. Si el desarrollador y el diseñador no vigilan el "encoding" con el que guardan sus ficheros habrá problemas con seguridad. Muchas herramientas de desarrollo y/o diseño Web guardan por defecto los ficheros codificados con ISO-8859-1, otras lo guardan en UTF-8 con BOM.

Por supuesto, existen soluciones, a nivel servidor (ficheros .htaccess con la directiva AddDefaultCharset) y a nivel estación de trabajo utilizando herramientas competentes que puedan lidiar con las diferentes codificaciones.

Esta es la típica página que se ve mal porque el servidor sirve en ISO-8859-1 y el fichero está codificado como UTF-8:

Se puede ver cómo los caracteres acentuados (ocupan 2 bytes en Unicode) son interpretados como 2 caracteres sencillos.

En el blog de Juque hay más ejemplos y se amplía más la información.

La conclusión final que obtengo es la siguiente: si no se puede garantizar una uniformidad en las plataformas de trabajo (que todo el mundo trabaje con el mismo "encoding"), lo más seguro es utilizar las entidades HTML de toda la vida (á en vez de á, ñ en vez de ñ, ...)

La pesadilla de los “encoding”

Estamos en el año 2007. Internet forma parte de las vidas de muchas personas. Pues, por increíble que parezca, algun@s todavía tenemos que lidiar con problemas cuyo origen se remonta a varias décadas atrás.

Antecedentes: en los años 60 se aprobó un código estándard para la codificación de caracteres alfanuméricos. Era una buena idea, puesto que hasta el momento, cada fabricante usaba más o menos el código que le daba la gana. Con este código, ASCII, se consiguió una cierta estandarización.

La idea era utilizar 7 bits (lo que nos da 2^7 = 128 códigos diferentes) para representar los caracteres y símbolos del lenguaje escrito. Por ejemplo, el 65 (0100 0001 en binario) representaba la letra A (en mayúscula), el 32 (0010 0000 en binario) representaba el espacio en blanco, etc.

Magnífica ocurrencia, si tu idioma es inglés. En seguida l@s europe@s nos dimos cuenta de que este sistema no era muy válido: muchos caracteres no tenían representación: eñes, cedillas (ç), vocales con diversos acentos (á, à, â, ä, ...)

La solución que se encontró fue rápida: ya que un byte tiene 8 bits y el ASCII sólo utiliza 7 (el octavo bit se destinó para control de errores), se decidió utilizar ese octavo bit para ampliar el rango de caracteres disponibles (2^8 = 256). Surgía la codificación ISO-8859.

También parecía una buena idea, pero no resultó ser tan idónea: algunos idiomas necesitaban una ñ, por ejemplo, pero otros necesitaban una ç. Algunos idiomas europeos sólo necesitaban un tipo de acentos, pero otros utilizaban más. El resultado de estas necesidades diferentes fue que no se llegó a una única codificación utilizando 8 bits. La codificación ISO-8859-1 (también llamada Latin-1) sirve para casi todos los idiomas de Europa Occidental, la ISO-8859-15 es una revisión de ésta que incluye el símbolo del euro (€). La codificación ISO-8859-16 (Latin-2) se adapta a idiomas de Europa Oriental.

Por otra parte, otros fabricantes decidieron hacer lo que les pareció con el 8º bit no utilizado. Añadieron nuevos símbolos o caracteres extraños al ASCII estándar. Surgen así diversos "codepages" parcialmente compatibles entre ellos (CP437, Windows-1252, ...) y con ISO-8859

Estas codificaciones extendidas supusieron una mejora, pero no fueron el remedio definitivo. Además de mantenerse ciertas incompatibilidades, no servían para codificar algunos idiomas no alfabéticos (idiomas fonéticos o ideográficos).

La siguiente idea fue Unicode: utilizar 2 byte completos (o más) para representar los caracteres o símbolos. Con 2 bytes (2^16) ya tenemos 65.536 posibilidades o símbolos diferentes. Unicode consigue representar y asignar un código único a prácticamente cualquier símbolo escrito en cualquier idioma humano. Además, mantiene la compatibilidad con ASCII y Latin-1: los 128 primeros caracteres de Unicode se corresponden con la codificación ASCII, y los 128 siguientes (hasta 256) se corresponden con Latin-1.

El problema de Unicode es la transmisión de los datos: es absurdo reservar siempre dos bytes para un carácter cuando la mayor parte de los caracteres Unicode que se pueden transmitir en un momento dado "caben" en un byte. Las diferentes formas de transmitir e interpretar los caracteres Unicode son los famosos UTF, siendo los más utilizados UTF-8 y UTF-16.

Seguiremos con el tema.