Una traducción: CSS cross-browsing

dentro de un anchor (ancla)?) y por cualquier tipo de cosas extrañas que hayas tipeado. Te entregan información sobre cada error que encuentren y links a los lugares donde ellos aparecen. Sólo clickealos y estás en camino de aprender algo.

La Validación es el más simple de los trucos que uso para asegurar que todo está yendo bien. Existen validadores tanto para (X)HTML como para CSS. ¡Usa los! Cualquier error que te aparezca puede ser un potencial problema de “cross-browsing” y si decides ignorarlos debes estar muy seguro de lo que estás haciendo. Los validadores tienen sus razones para mostrarte los errores que tengas. Por esto: Valida. Arregla. Valida. Arregla.

Mantente en “standards mode”

Este truco no es tan obvio como el anterior. Los browsers modernos tienen dos maneras de renderizar el modo en que muestran los sitios web: Standars mode y Quirks mode. El primero está hecho para trabajar lo más de acuerdo posible a las especificaciones del W3C y el segundo es más cercano en su funcionamiento a los bugs (errores) propios de los browsers más antiguos. ¿Por qué hacer una modalidad que se base en errores? -te preguntarás. La respuesta es muy simple: es el modo que tienen los fabricantes de browsers de mantener a sus clientes felices. Si se hicieran cambios demasiado grandes en los motores de render de los browsers muchos sitios “viejos” corren el riesgo de desarmarse por completo. Algunos, inclusive, pueden pensar que esto está bien. ¿Por qué estos sitios mal codificados debieran funcionar bien, después de todo? Si tu eres uno de los que piensa así, entonces has olvidado para qué es la web. La web no es un sitio “For Experts Only”. Existe para todos los tipos de usuarios, o sea, para cualquiera que tenga un browser.

Entonces, si se libera un nuevo browser con un motor de render más apegado a los estándares, muchas páginas y sitios simplemente dejarían de funcionar como debieran. Eso sería tremendo para los usuarios. Es por esto que los fabricantes de browsers los construyen de modo tal que, primero identifiquen las páginas que han tratado de seguir los estándares y, si estas lo hacen, se cambian al modo mejorado de renderizar páginas web (Standards Mode). Ahora probablemente entenderás por qué sugiero el uso de la modalidad estandar. Todos los browsers tratan de renderizar lo más cercano posible a las especificaciones de los estándares cuando están en esta modalidad. Cuando están en la modalidad “Quirk” mantienen su viejos bugs (errores) sólo para ayudar a los usuarios cuyos sitios no cumplan con las especificaciones antes mencionadas.

Pero ¿cómo saben los browsers qué sitios siguen los estándares y cuáles no? Para esto usan el doctype. Si no estás muy interiorizado con los doctypes, no te preocupes, son muy fáciles de aprender. El doctype es un tag que se encuentra en la primera línea de código de cualquier página web y que le dice al browser que tipo de “lenguaje de marcas” (markup language) usarás en tu sitio. Existen, básicamente, dos tipos de doctypes entre los cuales deberías escoger:

HTML 4.01 Strict (el que recomiendo):

< !DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN">

XHTML 1.0 Strict (sin < ?xml …> en la línea anterior)

< !DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "https://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

Al usar cualquiera de estos dos te aseguras que tu browser se cambiará a “standards mode” y tu diseño no arrojará errores. Usar el “doctype strict” significa que harás tu mejor esfuerzo por mantener separadas la estructura del diseño, y los validadores, de los que hablábamos al principio, tratarán de detectar errores en esas áreas. ¡Esto es muy útil! (Nota pequeña: el XHTML Transitional también puede cambiarse a “Standards Mode” pero mientras uses el Transitional como base no vas a obtener buenos chequeos de validación. Así que no los uses no más)

Hay un último punto del que es necesario hablar cuando de doctypes y standards mode se trata: el doctype necesita ser el primer tag en todo documento web. Si colocas cualquier otro elemento HTML (comentarios o caracteres extraños) antes que él, IE se volverá loco y se cambiará automáticamente a “Quirks Mode”. Hacer esto le ha traído incontables horas de dolor de cabeza a más de algún desarrollador web. Entonces: no lo hagas.

Elimina los estilos por defecto en los elementos

Otra de las causas de encontrarse con desarrolladores web gritando a las 3 de la mañana es el CSS que por defecto los browsers aplican a los elementos que muestran. Aún cuando no colocáramos ningún estilo CSS en nuestras páginas, los elementos de esta conservarían cierto look. Los headers serían más grandes que el texto de los párrafos y los blockquotes conservarían su padding. El tamaño de los textos es algo que funciona de manera relativamente similar en todos los browsers, pero no ocurre lo mismo con los paadings y margins.

Aquí va un ejemplo:

Un

sin estilos se muestra con padding en Firefox pero margin en IE. ¿Y qué solución hay para eso? Colocarle margin o padding igual a cero y al otro colocarle el indent necesario para que ocupe la posición que queremos. O sea, de alguna manera hay que eliminar los estilos que por defecto el browser coloca para conseguir que se muestren por igual en todos ellos.

Este tipo de problemas pueden consumir una buena cantidad del tiempo de desarrollo si no son manejados con cuidado. “¿La definición de listas (

) en el Opera tiene margin o padding?” “¿Qué pasa con los headers de segundo nivel en IE6?”. Hasta ahora existen dos métodos principales para manejar estos problemas. La primera de ellas plantea que desde el principio hay que “resetear” todos los margins a cero en el archivo CSS que estemos usando. Esto se puede hacer muy fácilmente escribiendo lo siguiente en el principio de nuestro CSS:

* {

margin: 0;

padding: 0;

}

En este caso, el * funciona como un Selector Universal y aplica la misma regla para todos los elementos de la página.

Problema resuelto, ¿cierto?

Es aquí donde el segundo método aparece. Este método plantea que usando el método del *, se resetean demasiados margins. ¿Por qué deberíamos complicarnos con los margins de, por ej., los form fields si para poder usarlos vamos a tener que crear nuevos valores en nuestro CSS? En vez de esto, deberíamos resetear a cero sólo aquellos elementos que vayan a tener cierta diferencia en el modo en que los browsers los muestran, y dejar tranquilos el resto. El asunto es que para conseguir esto se requiere de bastante trabajo y por ello Faruk Ate? construyó su “starting css” template que puede ser fácilmente incluida en el de nuestros documentos. Personalmente, prefiero el método del * pero prueba ambos y decide por ti mismo.

Los bugs de los browsers

Esta es el área donde el CSS se pone difícil. A pesar de que los fabricantes de browsers hacen su mejor esfuerzo para seguir los estándares, muchas veces no lo consiguen. Esto nos deja a nosotros, los desarrolladores, lidiando con un montón de bugs que, si logramos solucionar, sólo es para activar otros nuevos bugs tanto en el mismo browser como en cualquier otro. O sea, las cosas se pueden complicar muy fácilmente.

Uno de los peores browsers existentes (y que es ampliamente usado) es el Microsoft Internet Explorer versión 6. Muchos dicen que al ser ocupado por cerca del 80% del mercado no es un browser que uno pueda ignorar y punto. IE fue un buen browser en sus primeras versiones pero bajo los estándares de hoy día, ciertamente no lo es. Ningún otro browser me provocó tantos dolores de cabeza cuando estaba desarrollando este mismo sitio. Y realmente se comporta de manera terrible cuando se trata de renderear layouts CSS muy complejos.

Entonces, ¿qué hacer con estos bugs? El método más fácil (y más rápido) es no tratar de solucionar los problemas por uno mismo. Buscar y leer las soluciones que ya mucha gente ha encontrado. “Holly ‘n John” ha juntado los bugs más frecuentes en su página Explorer Exposed!. Ahí encontrarás ejemplos de cómo detectar un bug, cómo funciona y (a veces) por qué. Y lo más importante: cómo solucionarlo. A veces la solución es tan simple como setear position:relative; o display:inline en algunos elementos. Otras veces hay que manejar códigos un poquito más extraños y difíciles. El punto aquí es que si encuentras algún bug en tu página no pierdas el tiempo tratando de descubrir qué pasa y cómo solucionarlo. Busca respuestas y las encontrarás (en esa lista y en otras muchas que hay esperando por ti en el web)

Pero ¿qué hacer si “mi” bug no parece en esa lista?

Obviamente: usa Google para encontrar una solución. Él se va a demorar un par de minutos en traerte lo que necesitas. Esto es nada comparado con la hora que vas a perder tratando de encontrar una solución por ti mismo. No menosprecies este paso.

Si definitivamente no logras encontrar ninguna solución, entonces vas a tener que encontrarla por ti mismo. Para hacer esto, has una copia de tu página y elimina la mayor cantidad posible de código pero mantén el bug. Descubre cuál o cuales son las líneas de código que lo provocan y, finalmente, trata de encontrar otras maneras de hacer lo que ya tenías pero sin repetir aquellas que provocaban el bug. Esto es mucho más fácil que empezar a meter hacks en tu código, te permite mantenerlo y vas a aprender mucho más que si empiezas a meter código inentendible desde el principio.

Si por alguna razón esta técnica tampoco te ayuda a solucionar tus bugs, tienes dos caminos: o re-piensas los que has hecho o echas mano a tu arsenal de hacks. Asegúrate que tus hacks validan bien. El que yo uso para IE cuando nada más me resulta es el hack “* html”. Tu también puedes usarlo, pero escribiéndolo de este modo:

* html #element { code; }

Este selector opera sobre todos los tags que tienen el child #element. Pero como el “html” es un elemento superior en la jerarquía, no se selecciona nada a menos que IE así lo decida. Por lo tanto este código sólo se aplica en IE. Es importante señalar que este hack es CSS perfectamente válido. Tan sólo que no selecciona nada. Recuerda: Los hacks son la última de las opciones que deberías usar. Echales mano cuando nada más te dé resultado.

Update: 18 de Enero:

En los comentarios, Richard señala que también se pueden usar comentarios condicionales para manejar ciertos