Document.all sigue vivo… lamentablemente

Es ironico que cuando se pide a los usuarios abandonar y actualizar su Internet Explorer 6, ya que como comenta uno de los responsables de la remodelacion de Libertad Digital dicho browser impide el visionado correcto de los sites modernos, aun debamos de toparnos con sites programados con tecnologias antiguas y no compatibles.

Todo empezo hace unos dias, tenia que efectuar una compra por Internet, y como parte final del pago, debia validar mi tarjeta de credito mediante una pasarela conectada con mi banco, todo bien, pero al llegar a la pantalla de validacion el boton para hacer el paso siguiente no funcionaba, malo malo, se veia el boton pero ignoraba mis clics, entonces procedi a ver los mensajes que tenia la consola del Firefox, y ahi estaba, el sitio hacia una llamada en JavaScript al temido document.all, como se puede ver:

Para quien no lo recuerda, document.all fue una especie de “llave maestra” que se introdujo en Internet Explorer 3, a fin de “facilitar” de manera directa un acceso directo a los diversos elementos DOM que conforman una pagina HTML (especialmente los elementos de un formulario), esta caracteristica junto con otras como los behaviours no fueron implementadas por los demas browsers, lo que me hizo en algunos proyectos retocar bastante JavaScript a fin de evitar que la pagina solo fuera usable en las versiones de Internet Explorer.

Es que soluciones hay, y en su momento la solucion era usar un acceso totalmente cualificado como “form1.combo1….”, pero la solucion standard soportada tanto por Opera, Firefox e Internet Explorer es getElementById, por lo que sorprende que algo tan conocido no sea usado en un site de tanta importancia como una pasarela de pago electronico, esta claro que al final tuve que deshacer todo lo avanzado y utilizar una sesion de IE 8 para poder hacer la operacion, con la consiguiente perdida de mi tiempo como usuario, todo por una mala decision de los programadores de 4B que optaron por usar algo no standard.

Y claro, no habra quien me diga que si me quejo por esto y no reclamo a los fabricantes como en el caso de ShowModalWindow por no incluir dicha funcionalidad, en vez de quejarme con los progamadores del sitio, muy simple: en el caso de ShowModalWindow el problema era (ya no, pues Firefox 3 ya soporta ShowModalWindow 🙂 )que habia una funcionalidad de IExplorer sin ningun mecanismo alterno de implementacion en los otros browsers, mientras que en el caso de document.all se trata del hecho de usar una manera no estandar de acceder a un recurso, ya existiendo mecanismos comunes y compatibles para lograr el resultado.

Espero que cada vez sean menos los desarrolladores web que hace uso del infame document.all.

En defensa de showModalWindow

Probablemente la epoca en que era mas complicado desarrollar aplicaciones Web fue entre el 98 y el 2001, la guerra de los browsers estaba en su apogeo y las tecnologias para desarrollar salian a cada instante: ASP, ColdFusion, Servlets, PHP, Intrabuilder….

Era una epoca compleja, IE4 habia salido con fuerza introduciendo muchas novedades en cuanto al HTML, y claro infinidad de ejemplos de como usar esa nueva funcionalidad, de entre todas las palabras de moda entonces una sonaba con fuerza DHTML, entonces todos a desarrollar paginas dinamicas, con grandes efectos (mira!! sin usar Flash!), y por lo mismo herramientas especializadas para ello como el DreamWeaver.

Claro… con tanta novedad los problemas de compatiblidad que hubo en la epoca del Mosaic y Netscape (recuerdan el blink) pasaron a ser cosas de niños, muchas cosas que se veian bien bonito en IExplorer, se veian fatal o simplemente no se veian en Netscape, las causas: la manera laxa en que IExplorer validaba el cierre de tags, el infame document.all para acceder a los objetos de la pagina mediante JavaScript (de golpe casi todas las paginas lo utilizaban), atributos y propiedades que nunca serian aprobadas por el W3C…. Dicho esto Netscape no se libra de haber hecho sus propias incompatibilidades, recuerdan los layers?.

En esa epoca tenia la politica de que si se desarrollaba una pagina para Netscape (recordemos que con ASP Clasico uno tenia que renderizar todo) los ajustes (de ser necesarios) para que la pagina se viera en IExplorer serian minimos (con suerte el estilo CSS te lo podria controlar), siendo que el caso contrario no era cierto.

Eventualmente las cosas han mejorado, el crecimiento del Firefox, la estabilidad de las nuevas herramientas de desarrollo (VS.NET te permite generar un HTML bastante aceptable en Firefox) y la tendencia al uso de Flash para las cosas dinamicas, y el surgimiento del Ajax entre otras cosas, han configurado un escenario en el cual el caos se ha reducido de manera razonable, mas aun… los desarrolladores (en parte gracias a las herramientas) tienden a evitar esas “innovaciones” propietarias (como los behaviours introducidos en IE5) para sus webs publicas, en el caso de Intranets la cosa cambia pues puedes controlar que todos tus usuarios usen un unico browser.

Asi pues la mayoria de las innovaciones de IExplorer tratan de ser evitadas, las pruebas te ayudan a detectarlas, no se si W3C habra aceptado algunas, pero con la mayoria de ellas creo que la cosa no ha sido asi, pero… a veces se necesita una mayor amplitud de criterios, y reconocer que dentro de todo el ruido generado por sus innovaciones propietarias habia algo que deberia quedarse y ser admitida como standard, y es la funcion showModalWindow.

Como usuarios de aplicaciones Windows, nos hemos topado siempre con estas ventanas que saltan pidiendote que ingreses un dato, de tal manera que a menos que des el dato o canceles la operacion, no podras proseguir. Esto permite al que diseña la aplicacion un control del flujo de uso de manera total, lamentablemente trasladar esta ventaja al desarrollo de Aplicaciones Web tiene sus problemas, pues dicha funcionalidad no es parte del standard W3C por lo cual Firefox u Opera no tienen porque implementarla.

Se podria decir que para eso existe el “window.open”, pero la solucion no nos sirve pues al abrir una ventana nueva, ahora tenemos dos ventanas, pudiendo el usuario moverse a la primera sin haber cerrado las acciones que se suponian debiamos hacer en la ventana nueva, y hacer sobre eso ajustes en JavaScript para “simular” un comportamiento modal no es eficiente ni replica totalmente la funcionalidad deseada.

Parches hay muchos, pero nada que produzca la sencilla funcionalidad de una ventana modal, por lo que toca preguntarse si a estas alturas se justifica la cerrazon de no incluir algo de veras util como la funcion showModalWindow?.