HTML5 fail

A estas alturas, prácticamente todo el mundo ha oído ya hablar de HTML5: una serie de atractivas novedades en el mundo del diseño web que posibilitan la creación de aplicaciones (de navegador, móviles y hasta de escritorio) más potentes.

Al acercarse al lenguaje por primera vez, ya sea desde cero o desde HTML4, es habitual cometer ciertos errores. Espero que esta lista te ayude a no cometerlos tú tampoco (yo caí en varios de ellos, no hay por qué avergonzarse 😀 ).

Durante el resto del artículo me referiré a HTML5 con la acepción (bastante extendida) que engloba tanto HTML como CSS y JavaScript.

No usar HTML5 hasta que esté aprobado completamente

Este es uno de los más habituales. Muchos diseñadores afirman no querer usar HTML5 hasta que sea un estándar aprobado y soportado en su totalidad por los navegadores. Esta afirmación incluye versiones antiguas de Internet Explorer, por lo que hay que sumar unos 4-5 años a la fecha de dicha aprobación. Así a ojo, hasta 2025 más o menos.

Las causas de este error son dos: considerar HTML5 como un todo, y creer que una web va a “romperse” por usar una característica no soportada por el navegador.

HTML5 no se aprueba en bloque

El organismo encargado de aprobar las “normas de uso” del diseño web es el W3C. En su día, pretendieron aprobar dichas normas como un todo: se estudian, se debaten, se escriben y se aprueban. Parece lógico, salvo por el problema de que el proceso es tan lento (y el ritmo al que avanza internet tan rápido) que cuando acababan de redactar unas normas ya estaban obsoletas.

Sin embargo, en el caso del HTML5 se decidió adoptar una estrategia diferente e ir aprobando por partes: primero nos ponemos de acuerdo en cómo deben ser los degradados en CSS3 (por ejemplo) y luego ya nos ocuparemos de cómo deben ser las API para acceder a la cámara web del usuario (por ejemplo también).

El beneficio es doble: hay partes aprobadas más rápidamente y se pueden ir añadiendo partes nuevas en el futuro.

Por tanto, cuando alguien pregunta qué soporte tiene HTML5 hay que responder a lo gallego: depende. Depende de a qué característica específica de HTML5 te refieras, hay algunas que se pueden usar perfectamente en cualquier navegador (y esto incluye IE ¡6! en algunos casos) y otras que no se deberían usar más que para hacer pruebas. Para saber el estado de cada una, caniuse.com es de obligada visita.

Tu web no va a explotar por usar HTML5

(Al menos en principio 😛 ). La segunda parte de este error es el miedo a que, por usar una característica no soportada, tu web no va a funcionar en absoluto. En la gran mayoría de casos, esto no es así.

¿De dónde viene este miedo? Quizá de cómo se ve una web cuando hay un error en el código.

Un página "rota" por un error en CSS

Este es el resultado de un error en CSS

Una coma mal puesta en CSS o JavaScript o una etiqueta o una comilla mal cerradas en HTML pueden resultar en una página completamente “rota”. Al pensar en propiedades CSS no soportadas por X navegador, esta imagen viene a nuestra mente.

Sin embargo, HTML5 fue creado con una enorme precaución por ser retrocompatible. En la gran mayoría de los casos, cuando una propiedad no es soportada, el navegador la ignora. ¿Qué pasa si usas la propiedad border-radius en IE7? Nada. Absolutamente nada. Sigues teniendo las mismas esquinas rectangulares que tenías hasta ahora; tu página no se ve al 100% como estaba pensada pero sigue viéndose de forma aceptable.

Lógicamente, el diseño no será exactamente el mismo en los navegadores modernos y en los antiguos, pero todos deberíamos saber ya la respuesta a si las páginas necesitan verse igual en todos los navegadores.

Otro ejemplo de esto son los nuevos tipos de input para formulario (URL, email, number…). Resulta que los navegadores interpretan los input como text por defecto, por lo que si no reconocen un tipo de input lo tratarán como uno de texto. Ya puedes crear un input de tipo olakase que no pasará nada más que la aparición de un input de texto en el navegador.

Esto se traduce en que, donde hasta ahora ponías un input de tipo text para que el usuario introdujera una URL, ahora puedes poner directamente un input de tipo URL. Si el navegador de usuario soporta dicho tipo, tendrá ciertos añadidos (cambio del tipo de teclado en móviles, por ejemplo) y si no seguirá como hasta ahora. Todos contentos y sin nada roto.

Los placeholders o los atributos de validación en formularios son elementos que antes había que crear con JavaScript y ahora se pueden integrar directamente en el HTML. Si el navegador del usuario no los soporta seguirá como hasta ahora… y como ventaja, puedes aprovecharte de ellos en tu código JavaScript y hacerlo más limpio: aunque el navegador no sepa qué hacer con dichos atributos, JavaScript puede acceder a ellos igualmente para saber cómo tiene que validar.

A la hora de aprender sobre un nuevo elemento de HTML5 (ya sea de HTML propiamente, CSS3 o JavaScript) debemos estudiar y comprobar cómo se comporta en navegadores antiguos para saber qué problemas puede dar. En muchos casos los beneficios superan con creces los problemas (si es que hay alguno), por lo que compensa usarlos a día de hoy.

Los prefijos CSS no son propietarios ni se deben a una guerra de navegadores

O, al menos, no exactamente.

Quien haya querido insertar alguna propiedad más o menos novedosa de CSS3 en un sitio web se habrá encontrado con la necesidad de incluir varias veces el mismo código para que funcione en los diferentes navegadores:

background: #7abcff;
background: -moz-linear-gradient(top, #7abcff 0%, #60abf8 44%, #4096ee 100%);
background: -webkit-gradient(linear, left top, left bottom, color-stop(0%,#7abcff), color-stop(44%,#60abf8), color-stop(100%,#4096ee));
background: -webkit-linear-gradient(top, #7abcff 0%,#60abf8 44%,#4096ee 100%);
background: -o-linear-gradient(top, #7abcff 0%,#60abf8 44%,#4096ee 100%);
background: -ms-linear-gradient(top, #7abcff 0%,#60abf8 44%,#4096ee 100%);
background: linear-gradient(to bottom, #7abcff 0%,#60abf8 44%,#4096ee 100%);
Ejemplo de código con prefijos para degradados

Nota1: Para hacer más cómoda la edición de todo ese bloque, puedes usar cosas como los preprocesadores de CSS.
Nota2: Si eres de los que sólo pones el prefijo de webkit (como hacen en muchos tutoriales) lo estás haciendo mal y contribuyes a un lío mayúsculo creado por culpa de esta práctica.

Alguna gente piensa que estos prefijos son debido a una guerra de navegadores (similar a la vivida entre Internet Explorer y Netscape) y que son propietarios y/o privativos. No sé si es por estar relacionado con el mundo de Linux, pero lo que yo entiendo por propietario es “esto es mío, funciona como me da la gana y no me lo copies o te demando”.

En principio, las razones de estos prefijos son otras: hacer más fácil el desarrollo de la especificación CSS3 a base de que cada navegador pueda proponer su sintaxis y los diseñadores puedan comprobar cual funciona mejor o atajar un bug en un navegador en concreto.

Aunque haya excepciones, en la mayoría de casos las propiedades que llevan prefijo acaban proponiéndose como estándar al W3C y son implementadas por el resto de navegadores (con prefijo o sin él, dependiendo de cada uno). Por tanto, la idea es que todos lo copien y no al revés.

Los degradados con CSS3 son un gran ejemplo de esto: la propuesta inicial de webkit (-webkit-gradient en el ejemplo anterior) era un lío, mozilla (creo recordar) propuso una alternativa y al final todo el mundo usa esa. La utilidad principal de los prefijos es posibilitar esas mejoras, no crear a propósito incompatibilidades entre navegadores como en el caso de IE vs Netscape.

Cambiar todas las etiquetas div por section o article

Este fallo es comprensible, dado que a veces cuesta entender el uso más adecuado de las etiquetas nuevas. Yo sigo dándole vueltas a veces 😛

Mucha gente, al “pasarse” a HTML5 cambia TODAS las etiquetas que hasta entonces ponía como div por section o article (especialmente la primera). Esto no siempre es correcto.

La etiqueta div sigue siendo perfectamente válida en HTML5, no hay que dejar de usarla. Las nuevas etiquetas, section y article, tienen un valor semántico y de sección del contenido : section es para secciones de un documento relacionadas entre sí y article es, a grandes rasgos, para elementos con significado propio (una noticia, un producto en una tienda, etc). Si el elemento que vas a crear no tiene dicho valor semántico, usa un div.

El ejemplo que siempre se pone en estos casos es el de un div id="container", div id="page" o similar. Estos suelen ser puramente presentacionales, por lo que NO debes cambiarlos por section.

Imágenes dentro de figure

Un ejemplo parecido al anterior es meter todas las imágenes dentro de la etiqueta figure. Esto tampoco tiene por qué ser siempre así, ya que la etiqueta figure es para incluir contenido que podría ir en un apéndice.

Piensa en un libro de texto sobre anatomía en el que hay una figura adjunta sobre un esqueleto humano, o un artículo de periódico en el que viene una encuesta. Dichos elementos (porque no tienen por qué sólo ser imágenes, pueden ser trozos de código, vídeos, tablas…) podrían ser incluidos en un apéndice en lugar de aparecer en su posición, y este es el criterio principal para usar figure o no: en muchísimos casos las imágenes incluidas en una web no lo cumplen en absoluto, por lo que deberían ir incluidas en img (o con un div alrededor) como hasta ahora. WordPress no incluye las imágenes en figure (ni siquiera cuando van con un “pie de foto”) precisamente por esto.

Incluir la etiqueta meta viewport por error

Quizá no hay más gente a la que le pasara, pero yo cometí este fallo. Uno de los puntos de partida más habituales al empezar a usar HTML5 es HTML5 boilerplate. Entre el código incluido viene esta etiqueta:

<meta name="viewport" content="width=device-width" />

Si no vas a crear una web responsive, quítala.

Los navegadores móviles, por defecto, reducen el tamaño de las webs hasta que encajen en la pantalla. Esto estaba pensado para las webs más habituales cuando aparecieron los primeros smartphone, con un ancho fijo de (habitualmente) alrededor de 1000px, mucho más de lo disponible en los móviles (hasta hace poco).

Sin embargo, las webs responsive se adaptan ellas mismas a la pantalla del dispositivo, por lo que esta etiqueta se creó para “bloquear” ese comportamiento por defecto. El problema es que, si la incluyes en una web de ancho fijo, no se reduce adecuadamente.

Conclusión

Esta es mi lista de fallos con HTML5, espero que pueda ayudar a alguien que se esté iniciando, o incluso que ya lleve un tiempo. Si no estás de acuerdo, o quieres añadir más, te invito a dejar un comentario.

2 thoughts on “HTML5 y CSS3: Errores comunes

  1. gracias por el trabajo, ¿seria muy absurdo decir que usar html5 – css3 seria indicado en las paginas que obligatoriamente por la animacion(videos ventanas moviendose etc) se hacen en flash y que para una web mas estatita no haria alta?

    1. Según de qué animaciones estemos hablando, Flash aún sigue siendo mejor opción que HTML en algunos casos, por compatibilidad y por rendimiento. De todos modos, pocas páginas se hacen ya en Flash… y las que se hacen, son tan complejas que sigue ganando.

      Para una web más estática puede que no haga falta pero, como mínimo, tampoco implica desventajas en la gran mayoría de casos. Los atributos de formulario (placeholder, type=”url”, validación, etc), por ejemplo, no tienen ningún inconveniente y sí muchas ventajas, por lo que no veo razón para no usarlos.

Deja un comentario

Facebook