Yo siempre sigo los estándares, ya que creo que los estándares sirven para mejorar la compatibilidad entre sistemas. Por lo general es así, pero existen ciertos casos en donde los estándares se convierten en un obstáculo para lograr esa compatibilidad. Y los estándares hay que seguirlos porque sirven para lograr compatibilidad, o conseguir una mayor seguridad, o lo que sea. No hay que seguir los estándares porque son un estándar... aún cuando no sirvan para nada.
En este artículo voy a mostrar algunos casos reales con los que me encuentro, en los que el estándar se convierte en una molestia.
Seguir a rajatabla una especificación resulta muy frustrante cuando uno mismo es el único que la sigue a rajatabla. Si nadie da soporte a un estándar en particular ¿Es un estándar? Uno siempre trata de que las cosas anden y sigan el estándar; pero ¿En qué orden? Si hay que elegir entre que un sistema cumpla los estándares o que funcione ¿Qué elegir?
El caso concreto que me pasó es con el XHTML, el formato que uso para esta página y todas las demás de mi sitio.
Si bien doy por sentado que estás leyendo esto, y por lo tanto puedo afirmar que mi XHTML 1.0 estricto (el cual es válido) es perfectamente funcional. Sin embargo, la especificación del XHTML dice que su MIME type no debe ser text/html, sino application/xhtml+xml. Claro que si uso ese MIME type esta página no se vería en Internet Explorer y probablemente tampoco en Netscape. Uso text/html para que funcione, y expertos (más expertos que yo) me dicen que esto anda de pedo.
De pronto, la especificación me molesta y me veo forzado a ignorarla porque me imposibilita lograr compatibilidad. Si uso application/xhtml+xml las páginas no se verían en los navegadores usados por el 99% de la gente. ¿Cuál es el sentido de ello?
Al desobedecer el estándar y usar text/html, se ve bien en el 100% de los navegadores, incluso en navegadores como Opera que respeta al pie de la letra todos los estándares de la web. El único caso de estudio en el que no funcionaría sería en un navegador experimental construido por algún psicópata en base a una API para XHTML muy nueva de altísimo nivel, en Python o lo que sea.
Cuando dos especificaciones dicen cosas distintas, ¿A cuál seguir? El fabricante dice algo, y el consorcio de la industria dice otra cosa. Es aún peor, ¿Qué pasa cuando siguiendo uno de los estándares el producto anda en algunos casos, y siguiendo el otro estándar anda en los otros casos?
El caso concreto esta vez fueron los applets Java. El HTML 4.0 (y posteriores) quitó la etiqueta propietaria (de Sun) <applet> y la reemplazó por <object>. Por ejemplo, si yo tengo un applet imaginario 'reloj.class' (y otras dependencias) empaquetadas en el archivo 'reloj.jar', en HTML 3.2 hacía esto:
<applet width="200" height="200" codebase="../applets/" archive="reloj.jar" code="reloj.class"> <param name="hora" value="6"> <param name="minuto" value="23"> <param name="segundo" value="47"> </applet>
Según la especificación del XHTML por el W3C debería ser:
<object width="200" height="200" codetype="application/java" codebase="../applets/" archive="reloj.jar" classid="java:reloj.class"> <param name="hora" value="6" /> <param name="minuto" value="23" /> <param name="segundo" value="47" /> </object>
Pero lo probé en Internet Explorer usando la JVM de Microsoft y no funcionaba. Así que luego de hacer muchas veces prueba y error, logré hacerlo funcionar repitiendo los atributos 'codebase' y 'archive' como parámetros del objeto:
<object width="200" height="200" codetype="application/java" codebase="../applets/" archive="reloj.jar" classid="java:reloj.class"> <param name="codebase" value="../applets/" /> <param name="archive" value="reloj.jar" /> <param name="hora" value="6" /> <param name="minuto" value="23" /> <param name="segundo" value="47" /> </object>
Perfecto, ya que funciona y respeta el estándar del XHTML, ya que los parámetros se ponen a discreción.
Pero cuando desinstalé la JVM de Microsoft e instalé la de Sun, me encontré con que estos applets no funcionaban en Internet Explorer, con el Java Plug-In, ¡Pero sí en Opera!
Leyendo la especificación del Java Plug-In me encuentro con otra forma de poner los applets como objeto, que se contrapone a la especificación del W3C. Según la especificación de Sun, los applets tendrían que ponerse más o menos así:
<object width="200" height="200" classid="clsid:CAFEEFAC-0014-0001-0000-ABCDEFFEDCBA" codebase="http://java.sun.com/products/plugin/autodl/jinstall-1_4-windows-i586.cab#Version=1,4,1,mn"> <param name="code" value="reloj.class" /> <param name="codebase" value="../applets/" /> <param name="archive" value="reloj.jar" /> <param name="type" value="application/x-java-applet;jpi-version=1.4.1" /> <param name="hora" value="6" /> <param name="minuto" value="23" /> <param name="segundo" value="47" /> </object>
¿Hace falta que diga que cada vez es más código? Como se ve claramente, esta forma no tiene nada que ver con la anterior. Y sólo funcionaría con el Java Plug-In, no con otra JVM. ¿No sería mejor que Sun siga la especificación del W3C en lugar de escribir una especificación propia? ¿Me tengo que volver loco por ello?
Una categoría aparte de la estupidez, es tener un estándar cuyas sucesivas versiones lo hagan incompatible consigo mismo. Sería el caso del Word si fuera un estándar 
.
Como ejemplo, voy a usar el RSS, el cual existen al menos 7 especificaciones de RSS incompatibles entre sí; pero no lo voy a desarrollar porque Mark Pilgrim ya lo hizo por mí. El artículo está en inglés.
Como se ve, existen algunos casos en los que el estándar se convierte en un elemento autoritario para molestar al desarrollador, y no reportan ninguna utilidad real, no vale la pena seguirlos al pie de la letra sino sólo crear un producto que sea conformante con las partes útiles de la especificación.
Si estás interesado en otra lectura sobre temas similares, te recomiendo esta (en inglés).
