Los cinco errores más comunes en el uso de estándares

¿Por qué estándares? Ver más

Según nuestro estudio sobre las 3.000 webs españolas con más tráfico (basándonos en los resultados de Alexa) sólo el 25% de ellas cumple con los estándares web establecidos por el World Wide Web Consortium (W3C).

Descárgate la infografía del estudio aquí

¿Alguien tiene alguna duda sobre la importancia de los estándares web? ¿Es tan difícil cumplirlos todos? ¿En qué fallamos los desarrolladores españoles?

 

 

Lo curioso es que, estadística en mano, del 75% de las webs que no cumple los estándares, el 97% de ellas incumplen los mismos cinco tipos. Es decir, si todas las webs españolas corrigieran estos errores, tendríamos casi una red estándar, estable, accesible, automatizada, con una mayor capacidad de búsqueda y todas las demás ventajas que nos ofrece seguir los estándares web.

¿Qué cinco errores?

Bibliotecas y Frameworks de JavaScript desactualizados

Bibliotecas y Frameworks de JavaScript desactualizados:

Casi la tercera parte de las webs que no cumplen los estándares tiene alguna librería desactualizada.
Librerías de uso muy común, como jQuery, se actualizan frecuentemente para arreglar bugs que aparecen cuando se lanzan nuevas versiones de navegador.

Es decir, mantener librerías antiguas incrementa las posibilidades de que nuestra web no funcione bien en navegadores modernos.
De hecho, en nuestro análisis hemos encontrado que más del 57% de los sites que están usando JavaScript tiene problemas con los frameworks que se arreglarían simplemente utilizando nuevas versiones de la misma biblioteca.

Para saber si tu site tiene estos errores, puedes utilizar SiteScanner y ver si los frameworks JavaScript están anticuados.

La principal librería no actualizada es jQuery, aproximadamente la mitad de las webs tiene una versión en desuso, seguida por jQueryUI, Modernizr, etc…

La principal librería no actualizada es jQuery, aproximadamente la mitad de las webs tiene una versión en desuso, seguida por jQueryUI, Modernizr, etc…

Los prefijos CSS no son estándar

Los prefijos CSS no son estándar:

Los prefijos de vendor se añadieron a las propiedades CSS que usaban cada uno de los navegadores, pero no han sido, ni serán propiedades estándar.

Son una solución temporal y, en su momento, sirvieron a las compañías desarrolladoras de navegadores para implementar propiedades de un CSS3 experimental, bajo el riesgo de que ese código realmente no sirviera para nada y esas propiedades no pasaran al estándar.
Existe una gran variedad de prefijos: Opera tiene tres diferentes, Firefox, Internet Explorer, Safari, KHTML, cada uno el suyo.

Los programadores aún pueden usar las propiedades CSS con un prefijo de vendor, pero mientras que ciertas propiedades de CSS sí que han entrado en el estándar (sin prefijo, claro), muchas otras no, están en desuso y no son validadas como estándar.

Por ejemplo, una implementación específica de "hyphens" para que Internet Explorer separe las palabras entre dos líneas y ponga un espacio sería así:

 -ms-hyphens: auto;

Es muy común que a los sitios web les falten los prefijos específicos de proveedor en algunas características o que algunos estén y otros no. Más normal aún es que en su día se pusieran, y al convertirse en estándar estas propiedades (sin prefijo de vendor) ya no se necesiten y que aun así se sigan manteniendo. En breve esto provocará que se las páginas se vean mal en nuevos navegadores o versiones.

Además, los proveedores de navegadores están usando muchos menos prefijos, ya que los problemas de mantenimiento asociados a este uso son muchísimo mayores.

En definitiva, para seguir los estándares quita los prefijos CSS. Si necesitas y es absolutamente necesario retrocompatibilidad, puedes usar Grunt PostCSS para automatizar el mantenimiento de los CSS.

Detecta características, no el navegador

Detecta características, no el navegador.

El browser sniffing o la detección de navegador es una práctica muy común entre los desarrolladores web. Esto consiste en detectar sobre qué navegador estamos trabajando y en función de esto crear un código u otro.

Muchas veces conocemos exactamente qué navegadores implementan una funcionalidad, o soportan unas características y podemos estar tentados a hacer código como este:

var myNav = navigator.userAgent;

El principal problema de usar esto es que:

  1. De una versión a otra del navegador los comportamientos pueden variar.
  2. Requiere un mantenimiento constante ya que pueden salir más marcas de navegadores, más versiones y para cada uno necesitaríamos cambiar el código.

La técnica contraria y correcta para hacer esto consiste en detectar características y utilizar funciones nativas y objetos del navegador que el usuario está usando para visitar la página.

La forma más sencilla de hacer esto es usar una librería externa que nos aísle del problema. Por ejemplo: http://modernizr.com/
Si quieres ver las características que pueden ser detectadas usando Modernizr visita su documentación oficial. http://modernizr.com/docs/

Libérate de los plugins

Libérate de los plugins.

Al principio de los tiempos de la web, los plugins de los navegadores eran vitales para proporcionar contenido multimedia y funcionalidad compleja en aplicaciones web.

Sin embargo, tienen muchas desventajas, como que son aplicaciones que, dentro del navegador, consumen recursos adicionales y comprometen tu seguridad, ya que al ejecutarlos te expones a ataques.
Además, los plugins no están diseñados para dispositivos táctiles, son aplicaciones aisladas que nada tienen que ver con los cambios que los navegadores han experimentado últimamente y que hacen que las webs funcionen bien en modo táctil.

Así que hoy en día es recomendable hacer aplicaciones sin plugins, favoreciendo el uso de los estándares basados en tecnologías especificadas por la W3C que están soportados en navegadores modernos.

Según nuestro estudio, casi la mitad de las páginas que dan error en cuanto al uso de estándares por usar un plugin son páginas que reproducen un video.

Con esta sencilla línea podrían reproducir el video, funcionaría en todos los navegadores y, además, se adaptarían al estándar:

 <video id="promoVideo"  width="100%" controls 
src="
http://wams.edgesuite.net/media/SintelTrailer_MP4_from_WAME/sintel_trailer-1080p_3400.mp4
">
</video>

Si necesitas un poco más de información puedes visitar un post sobre tratar con HTML5 el contenido multimedia.

La directiva <!DOCTYPE>

La directiva <!DOCTYPE>

Cuando la directiva <!DOCTYPE> no se encuentra al principio del código de la web los navegadores actuales podrían no mostrar correctamente tu página. Esto se debe a que en los estándares HTML y XHTML esta directiva es la clave que indica al navegador cómo tiene que leer una web.

Usar una directiva Doctype, o no usar ninguna, hace que los navegadores hagan una lectura en modo "Quirks", es decir, asume que está escrita en un markup que es antiguo, no estándar y no válido (con normas de finales de los 90), y para dibujarlo, el navegador dibujará tus CSS y tu código como lo haría en Internet Explorer 4.

Básicamente, el estándar HTML5, hoy en día dicta que la directiva es <!DOCTYPE html>, sin más, y las opciones que fijan modos de compatibilidad, strict.dtd y todas estas directivas, están anticuadas.

Comprueba si tu sitio sigue los estándares

Después de esto, si finalmente quieres saber si tu sitio está configurado correctamente y cumple los estándares puedes usar la siguiente herramienta: el scanner modern.ie ejecuta un test simple para determinar si tu sitio web está configurado correctamente.

Sólo tienes que introducir la URL de tu página comprobar rápidamente si pasa los estándares.