CSS | Good manners vs hacks para navegadores específicos

Hoy me gustaría compartir una reflexión con todos ustedes acerca de las buenas formas para crear una hoja de estilos en contra punto al uso de hacks e ideas estrambóticas que pueden hacer de una hoja de estilos algo ilegible y que te dan ganas de tirar a la basura.

Uso de hacks

Los hacks en CSS son “trucos” para que determinados navegadores interpreten las hojas de estilo de forma diferente y generalmente se usaban para corregir la mala interpretación que hacían a determinadas propiedades. Se popularizaron durante la etapa en la que la versión del navegador de Microsoft era Internet Explorer 6 (IE6) que, debido a su “errónea” “especial” interpretación del modelo de caja (ancho/alto, padding y margen), hacía del diseño de páginas web una tarea dura. No era extraño ver diseñadores web que renegaban del navegador más popular que debían instalarse programas que renderizaban sus webs en N navegadores diferentes para poder ver las diferencias y así poder ir ajustando la visualización de las mismas de forma menos lenta. Una prueba que dejaba en gran evidencia estos problemas era la nota que obtenían los diferentes navegadores en “Acid Test”.

Con la llegada de Internet Explorer 7 (IE7) parecía que podía morir toda esta serie de trucos, pero aún había que usarlos en determinadas ocasiones, aunque ya se reducía a los sitios que querían seguir manteniendo el soporte para IE6 o sitios con “plantilas muy complejas”. Lo entrecomillo porque la complejidad de una plantilla depende más de una planificación del diseñador, de una mala distribución o de un mal uso de las propiedades CSS.

Finalmente, la cosa cambió mucho con la llegada de Internet Explorer 8 (IE8), momento en el que los motores de los navegadores más populares ya realizaban una interpretación de las hojas de estilo de forma muy similar y se comenzó a imponer un único modelo de caja para todos ellos.

Así pues, un diseñador web vivía con cosas como esta:

   1: .mydiv {

   2:     height: 15px; /* Para todos los Browsers */

   3:     #height: 20px; /*Para Internet Explorer */

   4:     height: 20px9; /*Para Internet Explorer 8 o inferior */

   5:     *height: 20px; /*Para Internet Explorer 7 o inferior */

   6:     _height: 25px; /* Para Internet Explorer 6 */

   7: }

Pero, ¿era bueno hacer uso de estos hacks ? ¿eran realmente necesarios? ¿Influían en el posicionamiento de nuestras webs? ¿Son necesarios en la actualidad?

Ventajas de uso de los hacks

Ventajas hay, pero no todas porque hay algunas desventajas preocupantes como veremos en la influencia en el posicionamiento. No obstante, un sitio web debe tener una identidad que debe quedar claramente plasmada en todos los navegadores y en la calidad con la que se vea. Por lo tanto, si queríamos mantener una identidad de marca tal y como se diseñaba, necesitábamos imperiosamente usar algunos trucos para que el sitio web se visualizara de la misma forma en todos lo navegadores y que, de esa forma, los usuarios siempre identificaran el sitio web con la marca y la interacción fuera la misma independientemente del navegador que usaran. Pero, ¿son los hacks la solución?

Necesidad de uso de los hacks

Relacionado con el punto anterior, si queremos mantener una identidad de marca, ¿se hace necesario el uso de hacks? La respuesta es NO, un NO tan rotundo como que si no se respira se muere. Entonces, ¿cómo se debía resolver los problemas de visualización de las páginas en los diferentes navegadores? Pues es muy fácil, el uso de “Comentarios condionales” o “Bloques condicionales” como me gusta llamarlos a mi.

<!--[if IE]>


According to the conditional comment this is IE

<![endif]-->
<!--[if IE 6]>


According to the conditional comment this is IE 6

<![endif]-->
<!--[if IE 7]>


According to the conditional comment this is IE 7

<![endif]-->
<!--[if IE 8]>


According to the conditional comment this is IE 8

<![endif]-->
<!--[if IE 9]>


According to the conditional comment this is IE 9

<![endif]-->
<!--[if gte IE 8]>


According to the conditional comment this is IE 8 or higher

<![endif]-->
<!--[if lt IE 9]>


According to the conditional comment this is IE lower than 9

<![endif]-->
<!--[if lte IE 7]>


According to the conditional comment this is IE lower or equal to 7

<![endif]-->
<!--[if gt IE 6]>


According to the conditional comment this is IE greater than 6

<![endif]-->
<!--[if !IE]> -->

According to the conditional comment this is not IE

<!-- <![endif]-->
 
Con estos “bloques condicionales” podemos indicar a los navegadores que sólo deben interpretar el código específico para ellos, con lo que podemos cargar hojas de estilo específicas dependiendo del navegador, o mostrar bloques de HTML diferentes.
 
Influencia en el posicionamiento
Muchos “diseñadores” defendían que daba igual que una hoja de estilos estuviera incorrecta a los ojos del validador de CSS de W3C por el uso de estos hacks. Pero lo cierto es que Google, Bing, Ask, Yahoo,… penalizaban en mayor o menor medida los sitios web que contienen HTML o CSS inválidos por lo que, si queremos posicionarnos en los buscadores, deberíamos tener como objetivo que el código HTML de nuestro sitio y las Hojas de Estilo asociadas cumplan con los estándares. Por lo tanto, se puede afirmar que el uso de hacks en las hojas de estilo tiene una influencia relativamente grande y negativa en cuanto penaliza en el posicionamiento o SEO como se ha puesto de moda.
Actualidad
En la actualidad no es necesario el uso de hacks , aunque siempre he defendido y sigo defendiendo que nunca lo han sido. En estos momentos los navegadores renderizan las páginas web de una forma prácticamente idéntica (salvo excepciones puntuales) y que, salvo mal uso de las propiedades en las hojas de estilo, nuestras hojas de estilos serán válidas para todos los navegadores.
No obstante, si hacemos uso de CSS3, veremos cómo a menudo tenemos que colocar los prefijos –ms, -webkit, –opera,… , que son hacks a medias ya que están aceptados, para asegurarnos que todos los navegadores interpretan una propiedad específica y que se corresponde con CSS3. Esto es debido a que no todos los navegadores han adoptado las especificaciones de HTML5 / CSS3 definidas por la W3C y, aquí se produce una sorpresa que pocos conocen y que muchos querrán discutir, INTERNET EXPLORER 10 es el navegador que CUMPLE MÁS ESTÁNDARES DE HTML5 / CSS3. Esto se debe a que en Microsoft se han esforzado en que todas y cada una de las especificaciones aprobadas estén soportadas por Internet Explorer.
Complicar las cosas
Cambiemos un poco de contexto aunque quiero que mantengáis en la memoria que los hacks no deberían ser usados y que bien podrían estar en esta sección del artículo. 
Como buen diseñador, me gusta analizar hojas de estilo de sitios populares, complejos o que simplemente me llaman la atención. Lo hago casi todos los días con el afán de aprender cosas nuevas, algún truquillo para realizar algo que haya visto y mantenerme siempre “entrenado” ante las posibles situaciones que me pueda encontrar en el futuro. Esto me permite encontrar casi siempre el mal uso de propiedades, redundancia, excesivas sobreescrituras, florituras innecesarias,… que me hacen pensar que o yo soy muy perfeccionista o hay demasiados diseñadores que no entienden el concepto de las hojas de estilo, que no tienen los conocimientos necesarios del ámbito tecnológico o que simplemente son desarrolladores que hacen sus pinitos de diseño.
Cualquiera que sea el caso, he llegado a encontrar un código html como este
<strong>Texto que debería ir en negrita</strong>
y después en CSS lo siguiente
strong {

    font-weight: normal;

}
Otro ejemplo es el uso de elementos flotantes a “cascoporro”, como los float son gratis… pues hala, todos son float. En este sentido me he encontrado páginas como:

En las que el cuerpo entero de la página es flotante y después tienen que hacer cosas complicadas para centrarlo o le ponen un margen a la izquierda fijo.

Un sólo elemento no debe flotar y así se centraría fácilmente


División de columnas en las que todos los elementos son flotantes.

Si son 2 columnas, debería flotar sólo uno de los elementos con un ancho fijo y el otro elemento tener un margen que deje el hueco del elemento flotante
Tres columnas, podrían flotar los laterales y el del centro mantenerse fijo con márgenes a ambos lados por ejemplo. También se podrían agrupar y así siempre mantener un elemento flotante y otro fijo.


Elementos flotantes con posiciones absolutas

A ver, si un elemento tiene posición absoluta, es lógico pensar que lo ubicaremos controlando las coordenadas left y top por ejemplo con lo que se anula el efecto flotante, pero el navegador puede complicarnos la vida intentando interpretarlo.


…


 
Puede que en algunos casos se queden propiedades residuales como resultado de la modificación del diseño durante la etapa de desarrollo, pero aún así, son demasiados casos que provocan que las hojas de estilo sean difíciles de mantener y que si algún día tenemos que modificar la visualización de algún elemento tengamos que llamar a Tom Cruise para que ruede una nueva entrega de Misión Imposible junto con nosotros. Para que todos lo vean más claro, pondré un ejemplo con código C#.
Veamos una asignación de valor a una variable dependiendo de una condición booleana.
if (condition) 

{

    myVar = valorTrue;

} 

else 

{

    myVar = valorFalse;

}
 
Este pedazo de código es tan simple que cualquiera lo entiende pero, también lo podemos hacer en una línea.
myVar = (condition) ? (valorTrue) : (valorFale);
 
Muy bonito, pero… en un método con varias líneas de código no es tan legible y, si añadimos más métodos, por ejemplo en la funcionalidad de una clase, con más instrucciones en línea como esta… empieza a ser algo complicado de ver y, por lo tanto difícil de mantener. Luego, los grandes programadores suelen recomendar que estas instrucciones sólo se usen en funciones que no tengan más líneas de código para que así sea fácilmente legible.
Por lo tanto, ¿qué podemos sacar en claro de esto? Que generalmente vale más hacer las cosas claras y limpias antes que ahorrarnos un par de líneas de código.
 
Recomendaciones para tener hojas de estilo simples y claras
Una hoja de estilos es algo simple, muy simple, basada en un concepto más simple aún y, por lo tanto, debe de ser absolutamente legible. Así que me gustaría dar algunas recomendaciones

Antes de empezar a escribir una hoja de estilos usa bocetos en papel o a partir del diseño original en algún programa de edición de imágenes para determinar los bloques de las páginas. De esta forma, se podrá determinar si hay elementos flotantes, cuáles son, las dimensiones de los mismos, el número de divs,…
En el HTML nunca debería haber modificadores de estilos dentro de los elementos a no ser que sea absolutamente necesario. Las modificaciones de estilos se deben hacer en las Hojas de Estilos CSS siempre.
No escatimes el uso de bloques. Los elementos se deben agrupar en bloques sin temor a pensar que se usan muchos porque al final serán más fácilmente manejables y modificables.
Usa clases o id’s siempre que puedas porque todos los elementos deberían ser fácilmente identificables para su posterior tratamiento en las hojas de estilo.
NO USES HACKS. Los hacks ya eran innecesarios en el pasado pero en la actualidad son absolutamente nefastos. Deberías pensar que si tienes que usar un hack es que estás haciendo algo mal.
Si quieres soportar navegadores antiguos o usas HTML5 / CSS3, incluye en tu sitio web una referencia a Modernizr o algún sistema de retrocompatibilidad similar.
LAS TABLAS SON SÓLO PARA TABULAR DATOS Y NO PARA DISEÑAR. Lo pongo en mayúsculas porque aún, hoy en día, todavía hay quien las usa para diseñar y eso un error muy grave que al final provoca dolores de cabeza porque las tablas no se interpretan igual en todos los navegadores y porque, como son para mostrar datos, al final resultan más complejas de manejar.
Ante la duda, busca siempre las especificaciones de la W3C para tratar de entender las propiedades que quieres modificar en un elemento.
Si se te complica un diseño, es mejor abstraerse y volver a determinar los bloques que tienes que ubicar y cómo los tienes que modificar.