Desarrolla para Firefox, hackea para Explorer

Desde que baso mi trabajo en los Estándares Web CSS, HTML y Javascript, he mantenido que es mejor hacer todo el proceso de diseño y desarrollo sobre navegadores con buen soporte de esos estándares como Firefox, y arreglar las incompatibilidades con Internet Explorer sólo una vez que el proyecto está terminado y funcional.

La razón es simple: actualmente hay muchos navegadores con buen soporte de estándares en uso (puse Firefox en el título porque es el más conocido, pero bien podría ser Opera, Konqueror o el excelente Camino para Mac). Si desarrollas para uno de ellos primero y sigues los estándares, te aseguras buenos resultados en todo ese universo de programas de una sola vez. Explorer*1, por otro lado, no sólo soporta esos estándares deficientemente, sino que además define sus propios comportamientos y es conocido por una cantidad considerable de bugs que hacen el trabajo muy tedioso. Es cierto que, una vez te acostumbras a las mañas propias de Explorer, es perfectamente posible construir interfaces de calidad para el navegador de Microsoft, pero entonces luego tendrías que corregir uno por uno los demás navegadores y, lo que es peor, estarías aprendiendo la interpretación de los estándares particular de una versión de IE en lugar de aprender la forma correcta de una vez por todas (IE7 apunta, de a poco,a los estándares como deben ser).

Ese es el argumento práctico, pero hay otro un poco más esotérico.

El proceso de desarrollo de interfaces para la web tiene varios pasos: generalmente se empieza con bocetos o wireframes, luego se trabaja el diseño visual de los bocetos con herramientas gráficas, luego se construye el HTML y CSS necesarios para visualizar las interfaces en un navegador y se agregan los comportamientos Javascript necesarios. Generalmente estos pasos van en paralelo, y se vuelve atrás si en el transcurso del trabajo surgen nuevos problemas, pero el punto es que son muchos los procedimientos que median entre la idea del proyecto y su estado final.

Desarrollar sobre software que soporta los estándares nos permite un flujo más o menos inmediato entre la idea y el resultado. Esto ayuda a mantener el foco sobre lo esencial del proyecto web y evita distraerse con minucias del código. No hay sorpresas.

Explorer, sin embargo, debido a su soporte deficiente requiere contínuos parches y rodeos que distraen, quitan tiempo, desmotivan (no hay nada peor que trabajar sin motivación!) y ensucian el código. Esto último no lo digo sólo por purista: código rebuscado y difícil de entender es código inmantenible y una puerta abierta para los bugs.

Cierto. Siguiendo ciertas directrices -no uses más de dos floats consecutivos, olvídate de position: fixed, normaliza los márgenes y paddings y sólo utiliza los métodos estándares del DOM- es posible llevar un proyecto a buen término sin demasiadas complicaciones en cualquier navegador moderno, pero en muchos casos nuestro proyecto incluye técnicas triviales en la mayoría de los navegadores (¿alguien dijo position: absolute?) que en IE pueden tomar horas (o días… Ejem, me ha pasado) de investigación, pruebas y hacks para resolver. Esas mismas horas en que aún contabas con ese empuje vital para realizar cualquier proyecto de calidad: la motivación y los objetivos claros.

Así pues, aunque sólo valga como humilde consejo, desarrolla para Firefox primero, hackea para Explorer después.