Las innovaciones de Internet Explorer I

  • Por
Hace tiempo, antes de que Internet Explorer llegara a ser el navegador que logró transformar el amor en odio, fue la fuerza conductora de la innovación en Internet.

A veces es difícil recordar todas las bondades que Internet Explorer otorgó antes de que Internet Explorer 6 se convirtiera en el flagelo de los desarrolladores web del mundo. Lo creas o no, Internet Explorer 4-6 es altamente responsable del diseño web tal y como lo conocemos hoy en día. Bastantes características propias del navegador se convirtieron de facto en estándares, e incluso llegaron a alcanzar el nivel de especificaciones HTML 5. Podría ser difícil de creer el que Internet Explorer sea amigable con un montón de características que asumimos ya como garantizadas en la navegación web, pero un vistazo rápido nos enseñará que así es.

 

DOM

Si Internet Explorer es el navegador con el que todo el mundo ha pasado del amor al odio, el Document Object Model (DOM) es la API a la que le ha ocurrido lo mismo. Puedes decir que el DOM es demasiado difuso, inadecuado para Javascript, y algo absurdo, y tendrías toda la razón. Sin embargo, el DOM da a los desarrolladores acceso a cada parte de la página web a través de Javascript. Hubo un tiempo en que podías acceder sólo a ciertos elementos de la página. Internet Explorer 3 y Netscape 3 sólo permitían acceso con programación a elementos de formulario, imágenes y enlaces. Netscape 4 mejoró la situación expandiendo los accesos con programación al elemento propietario vía document.capa. Internet Explorer 4 llegó más lejos permitiendo el acceso a cada elemento de la página vía document.all.

En muchos aspectos, document.all fue la primera versión de document.getElementById(). Todavía se usa el acceso a la ID de un elemento, tanto a través de document.all, como de document.all.miCapa o document.all["miCapa"]. La principal diferencia fue que Internet Explorer solía usar la función, la cual se relacionó con todos los demás métodos de acceso, como por ejemplo document.images y document.forms.

Internet Explorer 4 fue también el primer navegador en introducir la habilidad de obtener una lista de elementos por nombre de etiqueta vía document.all.tags(). Se mire como se mire, ésta fue la primera versión de document.getElementsByTagName()y trabajó exactamente de la misma manera. Si quieres obtener todos los elementos <div>, usas document.all.tags("div"). Aún en Internet Explorer 9, este método todavía existe y es un alias de document.getElementsByTagName().

Internet Explorer 4 también nos introdujo la que quizás es la más popular extensión propietaria del DOM de todos los tiempos: innerHTML. Parece que los chicos de Microsoft descubrieron el camino de la iluminación al montar un acceso directo con programación al DOM, como con outerHTML. En cuanto se comprobó su usabilidad, fueron estandarizados en el HTML5. El uso del texto plano era suficientemente importante como para que se introdujera textContent[2], que actúa de manera similar a innerText.

De la misma forma, Internet Explorer 4 introdujo insertAdjacentHTML(), otra vía para insertar texto HTML en un documento. Aunque este método era un poco más largo, también fue codificado para HTML5 y es ahora extensamente soportado por los navegadores.

 

Eventos

Al comienzo, no había sistema de eventos para JavaScript. Netscape y Microsoft lo apuñalaron presentando cada uno distintos modelos. Netscape nos trajo la captura de eventos, la idea de que un evento es primero desarrollado en la ventana, luego en el documento, para finalmente alcanzar el objetivo señalado. Las versiones de Netscape anteriores a la 6 soportaron únicamente la captura de eventos.

Microsoft por el contrario presentó el flujo de eventos. Ellos creyeron que el evento debería empezar en el objetivo actual para después extenderse a sus parientes. Las versiones de Internet Explorer anteriores a la 9 sólo soportaron el flujo de eventos. Aunque la especificación oficial de eventos del DOM evoluciona para incluir ambos métodos, la captura y el flujo de eventos, la mayoría de desarrolladores usa el flujo de eventos exclusivamente, con la captura de eventos siendo reservada para unos cuantos apaños y trucos enterrados profundamente en las entrañas de las bibliotecas de Javascript.

Además de crear el flujo de eventos, Microsoft también creó un manojo de eventos adicionales que llegaron a ser estandarizados:

  • contextmenu – se activa cuando usas el botón secundario del ratón en un elemento. Primero apareció en Internet Explorer 5 y después fue codificado como parte de HTML5. Ahora es soportado completamente por los más importantes navegadores.
  • beforeunload – se activa antes del evento unload y permite bloquear la descarga de la página. Originalmente se introdujo en Internet Explorer 4 y es ahora parte de HTML5. También está soportado en la mayoría de los navegadores.
  • mousewheel – se activa con la rueda del ratón (o servicio similar). El primer navegador en soportar este evento fue Internet Explorer 6. Justo como los demás, es ahora parte de HMLT5. El único gran navegador que no soporta este evento es Firefox (el cual no soporta una alternativa al evento DOMMouseScroll).
  • mouseenter – una no-flujo versión de mouseover, introducida por Microsoft en Internet Explorer 5 para ayudar a combatir los problemas al usar "mouseover". Este evento llegó a ser formalizado como Eventos del Nivel 3 del DOM. También soportado en Firefox y Opera, pero no en Safari o Chrome (¿aún?).
  • mouseleave – una no-flujo versión del "mouseout" para relacionarlo con "mouseenter". Introducido en Internet Explorer 5 y también estandarizado en los Eventos de Nivel 3 del DOM. Mismo nivel de soporto que mouseenter.
  • focusin – una versión de flujo del "focus" para ayudar más fácilmente a administrar el “focus” en una página. Originalmente introducido en Internet Explorer 6 y ahora parte de los Eventos de Nivel 3 del DOM. No está actualmente demasiado bien soportado, aunque Firefox tiene un debate abierto sobre su implementación.
  • focusout – Como el anterior.
 

XML y Ajax

Aunque XML es usado apenas en la web de hoy, Internet Explorer también ayudó al soporte de XML. Fue el primer navegador en soportar el análisis del lado del cliente de XML y la transformación de XSLT en JavaScript. Desafortunadamente, se hizo a través de objetos ActiveX representando documentos XML y procesadores XSLT. Los chicos de Mozilla pensaron que había algo interesante ahí porque inventaron una funcionalidad similar en los formularios de DOMParser, XMLSerializer, y XSLTProcessor. Los dos primeros son ahora parte de HTML5. Aunque los estándares en el manejo de XML a través de Javascript son muy diferentes a la versión de Internet Explorer, fue indudablemente influido por IE.

El manejo en el lado del cliente de XML fue parte de la original implementación de Internet Explorer de XMLHttpRequest, introducida primero como un objeto ActiveX en Internet Explorer 5. La idea era habilitar la recuperación de documentos XML del servidor en una web y permitir a JavaScript ese XML como un DOM. Las versiones de Internet Explorer requieren que uses un nuevo ActiveXObject("MSXML2.XMLHttp"), produciendo una versión dependiente que requería que los desarrolladores tuvieran que hacer piruetas para testear y usar la más reciente versión. De nuevo una vez más, Firefox limpió el estropicio creando XMLHttpRequest, que duplicaba exactamente la versión de la interfaz de Internet Explorer. Otros navegadores copiaron la implementación de Firefox, otorgando el liderazgo al fin a Internet Explorer 7 creando una versión gratuita de ActiveX. Por supuesto, XMLHttpRequest fue la fuerza conductora detrás de la revolución de Ajax con la que todo el mundo se animó a lanzarse sobre Javascript.

Fuente: www.nczonline.net/blog
 

Autor

OldMith

Desarrollador Web. jQuery. Responsive Design. Wordpress. Friki por naturaleza.

Compartir