Recomendaciones de Google cuando se va a programar en HTML

Google genera mucho contenido de código abierto, y entre este se encuentra muchísmo código de programación. Pues existen una serie de guías en las que se recomiendan determinadas formas de trabajar que pueden ser interesantes, principalmente (al menos a mi) las que hacen referencia al HTML. Me gustaría destacar algunas de las recomendaciones… que no significa que yo las use o que esté de acuerdo, pero creo que son mencionables.

Uso del protocolo

No se recomienda indicar el uso del protocolo en cuestión cuandos e llama a un objeto. A mi me gusta ponerlo, y aunque sé que en el RFC se dice que no es necesario…

<!-- No recomendado -->
<script src="http://www.example.com/example.js"></script>
<!-- Sí recomendado -->
<script src="//www.example.com/example.js"></script>

Indentación

Algo que yo suelo hacer… que el código esté bien ordenado. Para ello las “tabulaciones” se indicarán con 2 espacios (se recomienda no usar tabulaciones, aunque yo es lo que uso).

<ul>
  <li>Fantastic</li>
  <li>Great</li>
</ul>

Mayúsculas/Minúsculas

Se recomienda que todo el HTML esté en minúculas:

<!-- No recomendado -->
<A HREF="/">Home</A>
<!-- Sí recomendado -->
<img src="example.png" alt="Google">

Espacios en blanco

Es mejor no dejar espacios en blanco si no son necesarios.

<!-- No recomendado -->
<p>¿Qué? </p>
<!-- Sí recomendado -->
<p>Gracias</p>

Codificación

Esto es muy sencillo… se recomienda el uso de UTF-8 (sin BOM). Además, en las plantillas HTML se debe indicar la meta-etiqueta correspondiente:

<meta charset="utf-8">

HTML5

Se prefiere HTML5 en los documentos, con su cabecera correspondiente:

<!DOCTYPE html>

Esto también incluye el uso del MIME text/html y no de XHTML y, por ello, no hace falta cerrar las etiquetas o sea, es mejor <br> y no <br />.

Código HTML válidado

Algo de lo que siempre hay muchas discusiones… personalmente es lgo que me gusta cumplir, al menos cuando la web no tiene códigos de publicidad u otros elementos externos.

<!-- No recomendado -->
<title>Test</title>
<article>This is only a test.
<!-- Sí recomendado -->
<!DOCTYPE html>
<meta charset="utf-8">
<title>Test</title>
<article>This is only a test.</article>

Semántica

Hay que usar el HTML según su valor inicial, esdecir, un P es un párrafo, y un A un enlace.

<!-- No recomendado -->
<div onclick="visitarRecomendados();">Recomendados</div>
<!-- Sí recomendado -->
<a href="/recomendados/">Recomendados</a>

Multimedia

Hay que proveer de contenido alternativo en el caso de uso de elementos multimedia. Por ejemplo, las imágenes deberían llevar un texto alternativo.

<!-- No recomendado -->
<img src="example.png">
<!-- Sí recomendado -->
<img src="example.png" alt="Contenido de ejemplo.">

Inter dependencia

Hay que intentar mantener diferenciado y desvinculado el código de la página, de la estructura (markup) de la presentación (styling) del comportamiento con los mismos (scripting).

Evitar entidades

Gracias al UTF-8, es casi innecesario el uso de entidades HTML (por ejemplo el &eur para representar ). Sólo hay dos excepciones habituales que son el & y el < o >.

<!-- No recomendado -->
El símbolos del Euro es: &ldquo;&eur;&rdquo;.
<!-- Sí recomendado -->
El símbolos del Euro es: “€”.

Etiquetas opcionales

Este es otro de esos puntos en los que no estoy 100% de acuerdo. Si bien es cierto qu una de las grandísimas ventajas del HTML5 es que no es necesario escribir todo el código estructurado como hasta ahora, no tengo muy claro que sea interesante de cara a la compatibilidad con todo.

<!-- No recomendado -->
<!DOCTYPE html>
<html>
  <head>
    <title>gastando bytes</title>
  </head>
  <body>
    <p>Mal.</p>
  </body>
</html>
<!-- Sí recomendado -->
<!DOCTYPE html>
<title>ahorrando bytes</title>
<p>Bien.

Atributo “type”

En cambio, esta sí que la considero del todo útil (ya que antes me arecía completamente inútil). En principio los ficheros externos a los que llamamos (por ejemplo .CC o .JS) no es necesarios indicarles el MIME al que mandamos (al fin y al cabo, los ficheros ya lo indican per sé).

<!-- No recomendado -->
<link rel="stylesheet" href="//www.google.com/css/maia.css" type="text/css">
<!-- Sí recomendado -->
<link rel="stylesheet" href="//www.google.com/css/maia.css">
<!-- No recomendado -->
<script src="//www.google.com/js/gweb/analytics/autotrack.js" type="text/javascript"></script>
<!-- Sí recomendado -->
<script src="//www.google.com/js/gweb/analytics/autotrack.js"></script>

Formateado general

Hay que usar un salto de línea para aquellos bloques, listas o tablas e indentar cada elemento hijo. Esta es otra de las recomendaciones que agradezco, porque veo programadores que han hecho mucho daño al HTML.

<blockquote>
  <p><em>prueba</em> de un texto cualquiera.</p>
</blockquote>
<ul>
  <li>José
  <li>María
  <li>Juan
</ul>
<table>
  <thead>
    <tr>
      <th scope="col">Ingresos
      <th scope="col">Gastos
  <tbody>
    <tr>
      <td>5,00 €
      <td>4,50 €
</table>

Uso de comillas

Se recomienda el uso de comillas dobles en vez de comilla simple para los atributos.

<!-- No recomendado -->
<a class='boton boton-alternativo'>Acceder</a>
<!-- Sí recomendado -->
<a class="boton boton-alternativo">Acceder</a>

También hay una serie de recomendaciones para las hojas de estilo CSS. A parte de que el CSS debería validar (algo lógico). Además, se recomeinda que el nombre de las clases sea corto y genérico. Por ejemplo, es más recomendable usar #nav que #navegacion o usar .aux que no .boton-verde.

Selectores

Además, por un tema de rendimiento (muy importante de cara al WPO) hay que intentar ir al elemento más concreto que incliur los generales. Yo principalmente lo veo claro con los ID, pero no siempre con las clases.

/* No recomendado */
ul#ejemplo {...}
div.error {...}
/* Sí recomendado */
#ejemplo {...}
.error {...}

Propiedades cortas

Algunos elementos permiten propiedades agregadas…

/* No recomendado */
border-top-style: none;
font-family: palatino, georgia, serif;
font-size: 100%;
line-height: 1.6;
padding-bottom: 2em;
padding-left: 1em;
padding-right: 1em;
padding-top: 0;
/* Sí recomendado */
border-top: 0;
font: 100%/1.6 palatino, georgia, serif;
padding: 0 1em 2em;

Valores 0

Los datos que son de valor 0 no requieren de unidades para acompañarlo. De la misma forma, si un vaor va entre -1 y 1, no es necesario indicar el 0.

margin: 0;
padding: 0;
font-size: .8em;

Hexadecimal

Hay que intentar usar los colores cuanto más cortos mejor. De esta forma, si hay colores que se pueden reducir a 3 caracteres, mejor.

/* No recomendado */
color: #eebbcc;
/* Sí recomendado */
color: #ebc;

Ordenar los elementos

Se recomienda ordenar los elementos de forma alfabética. Claro está dentro de cada elemento.

background: fuchsia;
border: 1px solid;
-moz-border-radius: 4px;
-webkit-border-radius: 4px;
border-radius: 4px;
color: black;
text-align: center;
text-indent: 2em;

Finalizar las declaraciones

Al final de cada uno de los elementos se recomienda finalizar con un punto y coma.

/* No recomendado */
.test {
  display: block;
  height: 100px
}
/* Sí recomendado */
.test {
  display: block;
  height: 100px;
}

Separar propiedades y valores

Siempre utilizar un espacio entre las distintas propiedades y sus valores, pero no entre el valor y el punto y coma final.

/* No recomendado */
h3 {
  font-weight:bold;
}
/* Sí recomendado */
h3 {
  font-weight: bold;
}

Selectores y declaraciones

Siempre separar cada selector en una línea distinta de otro selector. Además separara con un salto de línea cada regla.

/* No recomendado */
a:focus, a:active {
  position: relative; top: 1px;
}
/* Sí recomendado */
h1,
h2,
h3 {
  font-weight: normal;
  line-height: 1.2;
}
html {
  background: #fff;
}

body {
  margin: auto;
  width: 50%;
}

Comillas

A diferencia del HTML, en los CSS es mejor evitar las comillas, y en caso necesario (como en los nombres de tipos de letra) usar la comilla simple .

/* No recomendado */
@import url("//www.example.com/css/estilo.css");

html {
  font-family: "open sans", arial, sans-serif;
}
/* Sí recomendado */
@import url(//www.example.com/css/estilo.css);

html {
  font-family: 'open sans', arial, sans-serif;
}

En fin, son simples sugerencias de reglas, unas más aceptables que otras… pero las que Google utiliza internamente cuando tiene que liberar código al mundo mundial. Así que, si quieres ser un buen googler ya sabes lo que te toca hacer.

HTML5 download

En estas dos últimas semanas llevo revisando y revisando elementos del HTML5 que, como ya dije, me apasionan, porque básicamente han hecho mejoras muy impresionantes. Y por eso hoy os voy a hablar de una que me ha gustado muchísimo: el html5 download.

Voy a hacerlo sencillo… imaginad que tengo un fichero que se llama ejemplo123454321.txt. Si pulsáis veréis que es un texto normal y corriente que se abre (en principio) dentro del propio navegador al tratarse de un fichero de texto plano. El código fuente es sencillo:

<a href="ejemplo123454321.txt">ejemplo123454321.txt</a>

ejemplo123454321.txt

Pero, ¿por qué no forzar la descarga y además aprovechar el camino en cambiarle el nombre del fichero? Para ello ha aparecido un atributo en HTML5 que es el download que permite esto mismo… sin necesidad de cambiar nada en el servidor… El código sería algo tal que así:

<a href="ejemplo123454322.txt" download="cambiodenombre">ejemplo123454322</a>
(descárgalo como cambiodenombre.txt)

ejemplo123454322.txt (descárgalo como cambiodenombre.txt)

Un detalle importante es que este sistema únicamente funciona si el fichero está en el mismo hostname desde donde se hace la petición.

¿Cómo se te queda el cuerpo?

Rel-Canonical, duplicados y versiones móviles

Desde que apareció en escena el rel-canonical me he encontrado en una decena de situaciones distintas de las que, a base de palos, he ido aprendiendo. Hoy me gustaría compair algunas de estas casuísticas en las que me he visto.

Por norma general

Lo ideal del rel-canonical es ponerlo en todas las páginas de un sitio web. Al menos en las páginas públicas (las que los robot son capaces de encontrar). Si tu robots.txt tiene un Disallow de alguna sección, no está de más que estas páginas también lo incluyan. Repito, en general, siempre utilizar el rel-canonical.

El rel-canonical se puede usar de dos formas: vía HTML o vía Header. En el caso del HTML simplemente hemos de colocar la meta-etiqueta en la cabecera de la página:

<!DOCTYPE html>
<html>
<head>
  <meta charset="utf-8">
  <title>Javier Casares</title>
  <link rel="canonical" href="http://javiercasares.com/">
</head>

La otra posibilidad es la de la cabecera, en cuyo caso hemos de indicar algo tal que así (por ejemplo en PHP):

header("Link: <http://javiercasares.com/> rel=\"canonical\"");

Páginas noindex-ables

Cuando tenemos un meta-noindex y un rel-canonical comienzan algunos problemas. Las opciones son dos posibles; la primera de ellas es simplemente indicar el meta-noindex y no indicar el rel-canonical.

URL actual: http://javiercasares.com/?prueba=si

<!DOCTYPE html>
<html>
<head>
  <meta charset="utf-8">
  <title>Javier Casares</title>
  <meta name="robots" value="noindex">
</head>

Con esto simplemente esa dirección no se indexaría… porque aunque existe no queremos que se muestre… el problema de esto es que, aunque la dirección exista y no queremos que se indexe porque es exactamente igual que la página principal, se puede generar un ataque. Bing y Google aunque se les indica el “noindex” rastrean y almacenan la página, aunque no la muestran en los resultados de búsqueda, pero se tiene en cuenta, y si es mala, no mola nada.

La otra solución es la de simplemente indicar el rel-canonical…

URL actual: http://javiercasares.com/?prueba=si

<!DOCTYPE html>
<html>
<head>
  <meta charset="utf-8">
  <title>Javier Casares</title>
  <link rel="canonical" href="http://javiercasares.com/">
</head>

En este caso, esta página también se indexa pero cualquier enlace, fuerza o como se le quiera llamar pasa automáticamente a integrarse con la página principal. En principio la URL “maligna” no debería aparecer en los resultados de búsqueda.

Y os podéis preguntar: Javi, ¿y no sería mejor poner las dos cosas? ¡Miiic!, ¡error!. Si hacemos esto se produce un agujero negro en el espacio infinito que desindexa muchas cosas. Vosotros pensáis en algo tal que así:

URL actual: http://javiercasares.com/?prueba=si

<!DOCTYPE html>
<html>
<head>
  <meta charset="utf-8">
  <title>Javier Casares</title>
  <link rel="canonical" href="http://javiercasares.com/">
  <meta name="robots" value="noindex">
</head>

Si hacemos esto, se produce una paradoja extraña. Lo que ocurre es que el rel-canonical se prioriza sobre el meta-noindex. Esto significa que:

  1. El buscador toma la URL http://javiercasares.com/?prueba=si y la almacena como http://javiercasares.com/
  2. El buscador toma la URL http://javiercasares.com/ y le aplica el noindex.

¡Bien! Acabamos de desindexar de Google y Bing nuestra página principal. Sí, esto pasa… así que, niños, no pongáis nunca un rel-canonical con un meta-noindex… pero… ¿qué corre si el rel-canonical apunta a la URL correcta que ya tenía un meta-noindex anteriormente? Os explico la situación.

Imaginad que tenéis una página que, antes de pensar en ponerles el rel-canonical ya tenía puesto el meta-noindex. Es una URL correcta (o sea, la URL del navegador y la del rel-canonical coinciden) por lo que… ¿por qué no podemos aplicar el rel-canonical si Javi ha dicho al principio que recomienda ponerlo siempre? Pues, en este caso sí que tendría sentido ponerse.

URL actual: http://javiercasares.com/?pagina=5

<!DOCTYPE html>
<html>
<head>
  <meta charset="utf-8">
  <title>Javier Casares</title>
  <meta name="robots" value="noindex">
</head>

Imaginemos que la paginación de mi sitio funciona por parámetros, y que yo ya tenía el código anterior… esta página, tal y como está no se indexa, lo que es correcto porque yo lo he decidido así… ¿por qué no poner algo como esto?

URL actual: http://javiercasares.com/?pagina=5

<!DOCTYPE html>
<html>
<head>
  <meta charset="utf-8">
  <title>Javier Casares</title>
  <link rel="canonical" href="http://javiercasares.com/?pagina=5">
  <meta name="robots" value="noindex">
</head>

Pues, en este caso en principio el código sí que sería correcto.

Versiones móviles

Versiones, hoy en día, para dispositivos hay 3: escritorio (versión normal), móviles (los zapatófonos) y smartphones (los que soportan HTML5). También hay varias formas de afrontar este tipo de páginas… lo que se recomienda (aunque a mi hay detalles que no me convencen, aunque se pueden llegar a corregir con un poco de ingeniería) es que se utilice responsive web design. Esto significa que dependiendo de ciertas especificaciones se carga un CSS u otro. Pero hay otras opciones como que se carguen CSS distintos según el tipo de “navegador” o directamente que haya URLs separadas según el tipo de web.

El caso que voy a tratar es concretamente el tercero, o sea, el caso en el que las versiones de los distintos dispositivos tienen URL distintas. Por ejemplo, podemos tener estas 3 versiones:

URL versión escritorio: http://www.example.com/page-one/

<!DOCTYPE html>
<html>
<head>
  <meta charset="utf-8">
  <title>Example</title>
  <link rel="alternate" media="only screen and (max-width: 640px)" href="http://m.example.com/page-one/">
  <link rel="alternate" media="handheld" href="http://phone.example.com/page-one/">
  <link rel="canonical" href="http://www.example.com/page-one/">
</head>

En este caso indicamos una URL alternativa para dispositivos móviles http://m.example.com/page-one/ y otra URL para dispositivos inteligentes http://phone.example.com/page-one/. ¿Qué habría que indicar en cada una de estas versiones?

URL versión móvil: http://m.example.com/page-one/

<!DOCTYPE html>
<html>
<head>
  <meta charset="utf-8">
  <title>Example</title>
  <link rel="canonical" href="http://www.example.com/page-one/">
</head>
URL versión smartphone: http://phone.example.com/page-one/

<!DOCTYPE html>
<html>
<head>
  <meta charset="utf-8">
  <title>Example</title>
  <link rel="canonical" href="http://www.example.com/page-one/">
</head>

Y en principio hasta aquí todo lo que hay que saber sobre los rel-canonical… pero antes de acabar, un detalle sobre esto último que tiene que ver con los Sitemaps… y es que en los Sitemaps XML también se le puede indicar las direcciones URL alternativas para las versiones móviles…

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9" xmlns:xhtml="http://www.w3.org/1999/xhtml">
  <url>
    <loc>http://www.example.com/page-one/</loc>
    <xhtml:link rel="alternate" media="only screen and (max-width: 640px)" href="http://m.example.com/page-one/" />
    <xhtml:link rel="alternate" media="handheld" href="http://phone.example.com/page-one/" />
  </url>
</urlset>

¡Ala, ahí queda eso!

Sitios web más accesibles

Aunque no es la primera vez que hablo del HTML semántico he decidido darle un repaso a todo lo que ARIA implica en el desarrollo de un sitio web. WAI-ARIA (Web Accessibility Initiative – Accessible Rich Internet Applications) son unas mejoras del HTML para mejorar la accesibilidad de los sitios web. Como ya dije en su momento, básicamente le da algo más de inteligencia semántica a los sitios.

Pero no hemos de olvidar que el propio HTML5 a diferencia de sus versiones anteriores ha incorporado que prácticamente todas sus etiquetas ya llevan incorporados ciertos elementos semánticos. Por poner un ejemplo, la etiqueta H1 ya implica un header. La cuestión es… ¿cuándo y cómo hay que usar ARIA en HTML?

La primera de las normas es bastante sencilla. Si un elemento HTML ya incluye semántica ARIA integrada, no hace falta indicarla, a menos que la queramos cambiar.

La segunda de las normas también es sencilla, aunque a mi personalmente no me gusta mucho. Es recomendable no sobre escribir las reglas ARIA de los elementos. Por poner un ejemplo:

No se debe hacer así:

<h1 role="button">botón en la cabecera</h1>

Sería mejor hacerlo así:

<h1><span role="button">botón en la cabecera</span></h1>

Aunque si lo queremos hacer óptimo, podemos usar:

<h1><button>botón en la cabecera</button></h1>

¿Qué significa esto? Pues que si por ejemplo hacemos algo de este estilo:

<h1 role=button>texto</h1>

Realmente lo que tendríamos a nivel significado es esto:

<button>texto</button>

Otro ejemplo sería el siguiente:

<button role="heading" aria-level="1">texto</button>

Que nos dejaría con algo tan simple como esto:

<h1>texto</h1>

Vale, hasta aquí nos queda claro que es importante usar el significado que viene por defecto en los diferentes elementos o la oportunidad de sobre escribir el significado de los mismos, pero… ¿qué ocurre con todo ese código “de mierda” que metemos en las páginas que en principio llevan significado de por sí, pero que realmente sólo usamos para “dar formato” a lo que queremos? Pues para este tipo de código podemos utilizar un sistema que elimina cualquier significado: el role="presentation".

Un detalle de este parámetro es que se come el significado también de cualquier etiqueta hija que incluya. Para poner un ejemplo algo “complejo” os dejo este:

<table role="presentation">
  <tr>
    <td>
      <table>
        <tr>
          <td><abbr title="Application Programming Interface">API</abbr></td>
        <tr>
      </table>
    </td>
  </tr>
</table>

Realmente, su significado “real” quedaría mucho más reducido, a esto:

<>
  <>
    <>
      <table>
        <tr>
          <td><abbr title="Application Programming Interface">API</abbr></td>
        <tr>
      </table>
    </>
  </>
</>

Personalmente, desde el punto de vista SEO este último elemento debería tener todo el sentido del mundo ya que implicaría quitarle significado a toda la basura de código que muchas veces se genera en determinados sitios web. Aún así, Bing y Google tratan ARIA de formas muy distintas y dispersas y no queda claro su funcionamiento. Después de esto, mi pensamiento es que si se hace bien y se pone el código como se debe, mal no debe hacer.

¿Cómo se oculta información? Habitualmente usamos a través de CSS el display:none o el visibility:hidden, pero esto simplemente lo que hace es no mostrarlo, pero sigue siendo “visible” desde el punto de vista de la accesibilidad. ¿Cómo eliminarlo? Pues añadiendo el aria-hidden. Hay que tener tener en cuenta que una de las novedades en HTML5 es que todos los elementos del DOM incluyen el nuevo atributo hidden, lo que significa que otra forma de ocultar contenidos se puede aplicar con un pequeño JavaScript tal que así:

<script>
  function ocultar() {
    document.getElementById('prueba').hidden = true;
  }
</script>

Existen muchos roles en el sistema, y como ya he comentado al principio la mayoría de etiquetas del HTML ya incluyen su significado semántico… pero no todos los elementos disponen de sus propios roles.

  • Cualquier elemento: como ya he comentado antes, cualquier elemento podría usar el role="presentation".
  • address: podría incorporar en caso necesario el role="contentinfo" que amplia la información del documento actual.
  • article: los navegadores aún no indican su rol por defecto, así que habría que indicarlo expresamente con role="article".
  • details: como el anterior, aún no va de serie, así que hay que indicarle el role="group".
  • dialog: otro que debería y no lo lleva de serie, con el role="dialog".
  • div, p, pre y blockquote: no tienen un rol definido por defecto, así que les podemos asignar el que nos venga en gana según necesitemos.
  • footer: es curioso que este elemento no lleve un significado implícito, por lo que si en la página hay un pie “general”, a ese en concreto se le puede asignar el role="contentinfo".
  • header: al igual que el pie, este tampoco lleva implícito nada, por lo que podríamos utilizar por ejemplo el role="banner" si es la cabecera principal.
  • main: este elemento que se está planteando par el HTML5.1 debería ir acompañado siempre del role="main".
  • nav: indica una navegación por lo que debería ir acompañado del role="navigation".
  • span: el “tag inútil” tiene una gran ventaja… al igual que el div se le puede incorporar cualquier rol.
  • table: aunque no incopora ningún significado por defecto hay dos opciones que sí que se podrían utilizar; la primera es cuando se le da uso de “diseño”, por lo que es inútil y se debería eliminar cualquier significado con el role="presentation"; en el caso de que se le de un uso de tabla pura, se le podría dar el role="grid".

A parte de estos elementos que son principalmente contenedores tenemos otros como em, strong, small, s, cite, q, dfn, abbr, time, code, var, samp, kbd, sub, sup, i, b, u, mark, ruby, rt, rp, bdi, bdo, br, wbr… que como son utilizables para dar formato no incorporan ningún tipo de significado semántico. Se les puede dar el rol que se quiera, pero personalmente no creo que sea recomendable.

Hasta ahora he comentado varios de los posibles roles que se pueden utilizar, pero la lista de roles es bastante grande…

  • alert: Un mensaje importante y con una duración en el tiempo limitada.
  • alertdialog: Un bloque que incluye un mensaje de alerta.
  • application: Todo lo contrario a un “documento”. O sea, que no es una web.
  • article: Parte de un documento que se puede tratar como un elemento independiente.
  • banner: Bloque que suele contener contenido para todo el sitio.
  • button: Sistema que reacciona tras un clic o presión.
  • checkbox: Entrada que tiene 3 posibles estados: verdadero, falso o mixto.
  • columnheader: Celda que contiene la información de una columna.
  • combobox: Un listado en el que además se pueden añadir opciones.
  • complementary: Contenido complementario al contenido principal pero que a su vez tiene significado propio.
  • contentinfo: Información relacionada al contenido principal.
  • definition: Definición de un concepto.
  • dialog: Ventana que detiene el proceso actual a la espera de que el usuario introduzca información para continuar.
  • directory: Referencia a un grupo de elementos (como si fuera un índice).
  • document: Todo el contenido de una página web.
  • form: Un formulario (y todo lo que lo acompaña).
  • grid: Como una tabla, tiene filas y columnas con celdas.
  • gridcell: Una celda.
  • group: Una lista de objetos pero que no es un directorio.
  • heading: La cabecera del contenido de una página.
  • img: Colección de elementos que forma una imagen.
  • link: Referencia que, cuando se pulsa, hace que el navegador vaya a ese recurso.
  • list: Lista de elementos no interactivos.
  • listbox: Lista de elementos interactivos con el usuario.
  • listitem: Elemento de una lista o directorio.
  • log: Zona en la que se va añadiendo información nueva dejando paso de la anterior.
  • main: Contenido principal del documento.
  • marquee: Zona en la que la información (no esencial) va cambiando.
  • math: Expresión matemática.
  • menu: Lista de opciones para un usuario.
  • menubar: Menú habitualmente siempre visible y en horizontal.
  • menuitem: Opción dentro de un menú.
  • menuitemcheckbox: Opción de un menú que tiene 3 posibles estados: verdadero, falso o mixto.
  • menuitemradio: Opción de menú que sólo permite una posibilidad a la vez.
  • navigation: Elementos que permiten la navegación por páginas externas o internas.
  • note: Bloque que añade información puntual al documento principal.
  • option: Elemento seleccionable de una lista.
  • presentation: Elemento que no debe ser accesible.
  • progressbar: Barra de progreso.
  • radio: Elementos que sólo pueden ser seleccionables una vez.
  • radiogroup: Grupo de elementos que sólo pueden ser seleccionables una vez.
  • region: Agrupación de contenidos que podrían estar en un directorio.
  • row: Fila de celdas.
  • rowgroup: Grupo de filas de celdas.
  • rowheader: Celda que contiene la información de una fila de celdas.
  • scrollbar: Barra de navegación que controla el scroll de una zona.
  • search: Bloque que agrupa elementos que permiten realizar búsquedas.
  • separator: Separador de secciones en un contenido o grupos de menús.
  • slider: Lugar de selección entre valores de un determinado rango.
  • spinbutton: Rango de opciones en los que el usuario ha de elegir.
  • status: Bloque de información para el usuario no tan importante como una alerta.
  • tab: Etiquetas que permiten al usuario una ayuda sobre el contenido.
  • tablist: Lista de “tabs”.
  • tabpanel: Contenedor de “tablist”.
  • textbox: Texto libre.
  • timer: Contador de tiempo.
  • toolbar: Colección de botones.
  • tooltip: Contenido contextual de información de un elemento.
  • tree: Lista que permite extender o contraer sus elementos.
  • treegrid: Listas por filas que permiten expandir o contraer sus elementos.
  • treeitem: Elemento de un árbol.

Ahora que tenemos todo esto sobre la mesa… Cuando hablan de la Web 3.0 ¿se refieren a esto?

Adiós cookies, Hola localStorage

Sin duda las cookies han sido grandes aliadas a lo largo de la historia de la programación, y ya ni te cuento las bases de datos. Pero esto desde el lanzamiento semi oficial de HTML5 ha cambiado bastante ya que si queremos almacenar datos tenemos un nuevo aliado: el navegador.

Y es que entre las mejoras que incorporan las nuevas versiones de los navegadores nos encontramos con la posibilidad de almacenar datos en el navegador del usuario y poder recogerlos de nuevo mediante unos sencillos JavaScript.

Existen dos formas de almacenar información: la temporal y la permanente. La primera de ellas la encontramos con las funciones de sessionStorage, sólo se mantiene mientras está la misma sesión del navegador, o sea, podemos cerrar y abrir ventanas, pero no cerrar “el programa”; y la segunda con las de localStorage que, a diferencia del caso anterior, los datos se mantienen aunque el navegado se cierre, ya que la información se almacena en local siempre y cuando el usuario no la elimine.

Esto da pie a muchas mejoras sobretodo en lo que a Web Performance se refiere, ya que a diferencia de las cookies esta información no se transmite por HTTP. De todas formas, esto también tiene un inconveniente, y es que trabajar con los sistemas de cookies de los lenguajes de programación como ASP o PHP se complica.

¿Quieres ver un pequeño ejemplo del funcionamiento de esto? Pues te dejo con un par de pruebas de ambos sistemas en los que se puede ver en el código fuente el funcionamiento. El ejemplo que siempre se me viene a la cabeza es el del carrito de la compra

Cursos de Verano: HTML 5

Otra semana que empieza y otra semana con más cursos de formación… hoy ha tocado una pequeña introducción a algunos elementos interesantes de HTML 5 para hacer abrir boca a desarrolladores y parte de la gente de contenidos.

Básicamente me he centrado en comentar los nuevos elementos (los que he considerado más interesantes), en comentar los que desaparecen y otras cosas bastante estándar como son los meta-tags, los enlaces o las relaciones entre elementos.

En fin, como siempre, mejor dejo la descarga de la presentación y cualquier cosa comentáis.

HTML 5 en todos los navegadores

Hace ya un tiempo que no comento cosas de HTML 5, y ahora que se va acercando la fecha de su puesta en marcha ya muchos proyectos nuevos se plantean, al menos la estructura base, comenzarse en esta nueva versión del idioma de Internet. En su día comenté cómo conseguir que, mediante un pequeño script, funcionase HTML5 en Internet Explorer 8. El tema es ¿cómo hacer que funciona siempre?

La solución es bastante sencilla y a la vez también algo compleja, aunque en su día permitirá hacer una actualización bastante rápida del código con un simple “replace”. Como ya sabéis, HTML 5 es un markup, al igual que lo son el HTML, los XML, el RDFa, etc… de forma que, lo mismo que podemos cargar XML en el código HTML… ¿por qué no cargar HTML 5 de la misma manera?

La idea es que, aquellos nuevos elementos que pueden no funcionar en todos los navegadores de forma correcta podemos cargarlos de la siguiente manera:

<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml" xmlns:html5="http://www.w3.org/1999/xhtml">
<head>
  <meta charset="utf-8"/>
  <title>Demo HTML5</title>
  <style>
    html5\:section {
      display: block;
    }
  </style>
</head>
<body>
  <h1>Demo HTML5</h1>
  <html5:section>Este <strong>&lt;html5:section&gt;</strong> funciona incluso en Internet Explorer.</html5:section>
</body>
</html>

El día en que se vea que todos los usuarios usan un navegador “compatible”, se hace un simple “reemplazar” de <html5: por < y de </html5: por </ y ya está… ¡prueba superada!

Un buen punto de partida para aquellos que quieran comenzar a hacer sus primeros códigos y ver que cualquier usuario lo ve correctamente.

HTML5 Prefetch

Hace un tiempo, cuando comencé a hablar del HTML 5, hice una breve referencia a los distinto “rel-algo” que podemos encontrar en la nueva codificación. Entre estos hay uno que puede ser muy interesante si sabes cómo navegan los usuarios de tu sitio web y, aun no sabiéndolo, crees que puedes acelerar la velocidad de carga de la misma.

El link prefetching básicamente lo que permite es descargar las URL indicadas antes de que se vayan a visitar… y el HTML 5 incluye un sistema para avisarlo, ya de forma estándar (hasta ahora sólo Firefox le daba soporte).

El sistema es tan sencillo como poner en el <head> algo como:

<link rel="prefetch" href="http://sitio.web/url-siguiente/">

o algo como:

<link rel="prefetch" href="http://sitio.web/imagen-siguiente.png">

Otra posibilidad es la de acelerar la carga pero en URL concretas que se vayan cargando dentro del sitio… de forma que cualquier enlace interno quedaría de la siguiente forma:

<a rel="prefetch" href="http://sitio.web/url-siguiente/">

Un ejemplo de uso interesante es el que hace Yahoo! con su página principal. Cuando se carga, a priori no hace nada, pero una vez escribes la primera letra en el cajetín de búsqueda, comienza un proceso para precargar imágenes y CSS de la página de resultados de búsqueda, ya que se plantea que va a ser la siguiente en visitarse.

Reproductor HTML 5 para vídeo

Estamos muy mal acostumbrados a que nuestros vídeos se alojen en FLV en sitios como Youtube o Vimeo. Hoy en día teniendo en cuenta que el ancho de banda está tirado de precio, no entiendo porqué no se tiende a la calidad y a alojar la propia información si que otros decidan.

Con HTML 5 y su nuevo elemento <video> tenemos la posibilidad de incluir muchos formatos de vídeo con muchas opciones… y para hacerlo ya todo más sencillo, además de hacerlo compatible con versiones anteriores que no soportan los nuevos formatos, están apareciendo algunos sistemas que permiten estos reproductores de una forma “chula” y fácil.

Algunos de los que he encontrado son estos:

  • FlareVideo: Necesita de jQuery y el soporte es, a mi gusto, un poco reducido… hay que programar expresamente para ello.
  • MediaElementsJS: También necesita de jQuery, soporta todos los navegadores e incluso terminales móviles. Hay que incluir el nuevo tag <video> y unas pocas líneas más… Esto significa que cuando todos los navegadores den soporte, se quita y todo seguirá funcionando.
  • JW Player: La nueva versión de este tan utilizado reproductor ya es compatible con HTML 5. Necesita de jQuery y aun está en βeta.
  • VideoJS: No necesita de librerías externas y funciona gracias al elemento <video>, lo que, en principio, a mi me da mucha seguridad. Funciona con todos los navegadores y soporta los nuevos formatos.
  • SublimeVideo: Aunque aun no ha salido oficialmente, lo que se puede ver es parecido al VideoJS, es decir, que no necesita de librerías externas y funciona gracias al elemento <video>. En principio funciona con todos los navegadores, soporta la mayoría de formatos.

Presentaciones Tenerife Lan Party 2010

Hoy estoy en la Tenerife Lan Party haciendo un par de presentaciones, una de ellas sobre penalizaciones (principalmente de Google) y otra sobre HTML 5 (relacionada con temas más bien de SEO).

Y, aunque va a ser una entrada breve, os dejo con la descarga en PDF de ambas para quien quiera darles una ojeada:

Lástima estos días que Tenerife Norte está teniendo unos nubarrones bastante importantes y no he podido ni ir a la piscina ni a la playita, y ya mañana me vuelvo para Barcelona.