¡Ah!, se siente tan bien poder olvidarse de las largas líneas de Javascript, perdón, ECMAscript, y jugar con jQuery y el DOM. Bueno, al menos hasta que nos topamos con aquel navegador que ignora todos los estándares web: Internet Explorer, lamentablemente aún usado por muchos ingenuos que no conocen otras excelentes opciones.

Este semana tuve que modificar mucho código jQuery para que funcione con el desastroso navegador de Redmond, lo que es mucho más dificil sin una herramienta tan valiosa como Firebug. Internet Explorer solo se limita a dar números de línea, muchas veces sin decir en qué archivo, y crípticos mensajes de error cuando algo no marcha. Me niego a instalar más aplicaciones de Microsoft solo para encontrar errores en su código, es más efectivo pensar un poco, hacer algunos cambios y determinar dónde está el problema si los números de línea cambian. Debugging cavernario, sí, pero efectivo.

Un problema con el que me topé muchas veces al trabajar con Internet Explorer y jQuery fue al usar el método html() para modificar el contenido de cierto elemento, a veces fue necesario hacer cambios mayores en un elemento parent() o incluso usar remove() y luego append() o after() (ver documentación de jQuery). No he podido encontrar la lógica para estos problemas, en algunos casos html() funciona y en otros genera run time errors.

También, al utilizar tablas, como en un calendario que diseñé usando jQuery para pasar los meses, es importante ser estricto con el uso de elementos como thead y tbody.

Hacer que tu aplicación funcione con Internet Explorer no es imposible pero si que quita mucho tiempo y puede generar tendencias suicidas, tanto así que muchos desarrolladores web pensamos seriamente en aumentar nuestras tarifas cuando se trate de crear código para Internet Explorer, y lo digo en serio.

Soy usuario de Campaign Monitor desde hace mucho y hace poco empecé a trabajar con ellos en mejorar el módulo para Drupal que escribí meses atrás.

Creo que David Greiner y todo el equipo en Campaign Monitor están haciendo un gran trabajo, en especial cuando se trata de promover el uso de estándares web para correo electrónico, y ese es el motivo de este artículo, generar conciencia entre los desarrolladores web y en las compañías que crean clientes de correo electrónico para que podamos utilizar HTML y CSS estándar sin importar que cliente se utilice.

Desde 456 Berea St. Roger Johansson apoya la idea y creo que todos los que estamos involucrados profesionalmente en el desarrollo de proyectos Internet debemos hacerlo.

No esperes más y participa de la iniciativa de Campaign Monitor ayudando a definir los requisitos para usar estándares web en correo electrónico.