javascript - ¿Qué problemas con el navegador cruzado has enfrentado?
css dom (18)
Al desarrollar múltiples juegos de navegadores, ¿qué problemas ha enfrentado durante el desarrollo debido a las diferencias en la implementación del navegador?
Para comenzar, estoy enumerando algunos de los que tuve que enfrentar:
- Un nodo de texto en Firefox solo permite 4K de datos. Por lo tanto, una respuesta XML Ajax se divide en varios nodos secundarios de texto en lugar de un solo nodo. Está bien en Internet Explorer. Para Firefox, para obtener la información completa, debe usar node.normalize antes de llamar a node.firstChild o usar node.textContent, ambos son métodos específicos de Mozilla.
- Internet Explorer no reemplaza
o el código HTML 160, debe reemplazar su equivalente Unicode / u00a0 - En Firefox, un campo de entrada creado dinámicamente dentro de un formulario (creado con document.createElement) no pasa su valor en el envío de formularios.
- document.getElementById en Internet Explorer devolverá un elemento incluso si el nombre del elemento coincide. Mozilla solo devuelve elemento si coincide con id.
- En Internet Explorer si un cuadro de selección tiene un valor no representado por ninguna de las opciones, se mostrará en blanco, Firefox muestra la primera opción.
Para Firefox, para obtener la información completa, debe usar node.normalize antes de llamar a node.firstChild o usar node.textContent, ambos son métodos específicos de Mozilla.
En realidad, todos estos son métodos W3C DOM compatibles con la gran mayoría de los navegadores. Creo que encontrarás que también funcionan en IE.
Mi mayor problema con los navegadores cruzados es que todavía hay personas usando IE.
El segundo más grande es que incluso en los navegadores que siguen los estándares, hacer algunas cosas en CSS sigue siendo imposible; por ejemplo, tbody {overflow:auto}
no hace nada útil en nada excepto en Gecko, e incluso allí tiene errores.
¿El mayor problema del navegador cruzado? - ¡ Internet Explorer !
<start_grumpy>
IE es el único responsable de "retener la Web": los desarrolladores de EE. UU. No pueden crear sitios increíbles con HTML5, SVG o XFORMS o CANVAS ... no por Firefox, Safari o Chrome, sino porque 2 / 3s del Internet todavía está atascado en IE. Sin mencionar que ~ 20% de la web todavía está atascado en IE6! IE8 es la primera versión de IE que intenta al menos ser compatible con los estándares (los estándares de 2001), lo que significa que será al menos 2018 antes de que podamos comenzar a descartar todo el soporte para IE7.
</ start_grumpy>
De lo contrario, nombre un método DOM que IE sea totalmente compatible ... el hecho de que esta es una pregunta difícil de responder es mi mayor problema con CrossBrowser.
getElementById() - badly broken
getElementsByName() - buggy
getElementsByTagName() - buggy
getAttribute() - buggy
setAttribute() - majorly broken
createElement() - buggy
appendChild() - buggy
incluso las cosas que inventaron IE están en mal estado ...
innerHTML (getting) - returns the worst markup possible
innerHTML (setting) - doesn''t work on the elements you''d want to dump a bunch of data into (e.g. Tables and Selects)
Al desarrollar un marco de pruebas del sistema para una aplicación web, tuvimos que simular varios eventos, como clics. Recuerdo que no pudimos encontrar ninguna forma normal de hacerlo en IE y FF y tuvimos que implementarlo de dos maneras diferentes con mucho vudú.
No recuerdo los detalles, pero recuerdo que fue realmente molesto.
El único que realmente me entiende:
- IE6 todavía es usado por ~ 18% de la web , es casi 1 de cada 5, y abordar sus problemas es lento, hackoso y frustrante. ;) Los issues son realmente demasiado numerosos para enumerarlos aquí.
Si le interesan los problemas en sí, QuirksMode.org es un recurso increíble que utilicé todos los días antes de dar el salto a las bibliotecas del lado del cliente. También vea la presentación de The DOM de John Resig en Messenger, yahoo, que brinda mucha teoría acerca de cómo tratar los temas de navegadores cruzados de manera eficiente.
Sin embargo, si le interesa simplemente resolverlos, su pregunta es un excelente ejemplo de por qué muchos consideran usar bibliotecas del lado del cliente como jQuery , YahooUI , MooTools , Dojo , etc. Con una comunidad próspera, personas talentosas y proyectos de respaldo corporativo al igual que los que le permiten centrarse en su aplicación en lugar de estos problemas.
Aquí hay algunos ejemplos de jQuery que evitan gran parte de la frustración entre navegadores y realmente pueden hacer que todo esto ... sea divertido.
Enlace de clic de mouse entre navegadores
$(''#select anything + you[want=using] ~ css:selectors'').click(
function(){
alert(''hi'');
}
);
Inyección de HTML entre navegadores
$(''#anElementWithThisId'').html(''<span>anything you want</span>'');
Cross-browser Ajax (todos los objetos de solicitud todavía están disponibles para usted)
$(''p.message'').load(''/folder/file.html'');
Y lo que realmente me impresiona, cargar un subconjunto de datos con selectores (ver el manual para más detalles)
$(''p.message'').load(''/folder/file.html body p:first-child'');
Ahora, cómo todo esto empieza a divertirse: encadenar métodos juntos
$(''ul.menu a'').click( // bind click event to all matched objects
function(evt){ // stnd event object is the first parameter
evt.preventDefault(); // method is cross-browser thx to jquery
$(this) // this = the clicked ''a'' tag, like raw js
.addClass(''selected'') // add a ''selected'' css class to it
.closest(''ul.menu'') // climb the dom tree back up to the ul
.find(''a.selected'') // find any existing selected dom children
.not(this) // filter out this element from matches
.removeClass(''selected''); // remove ''selected'' css class
}
)
Me recuerda a Joel''s Can Your Programming Language Hacer esto? artículo.
Tomando todo esto a un nivel teórico, el verdadero avance no proviene de lo que puedes hacer con pensamiento y esfuerzo consciente, sino más bien lo que puedes hacer automáticamente (sin pensar ni esforzarse). Joel tiene un segmento sobre esto en Smart And Gets Things Done sobre preguntas de entrevistas y desarrolladores inteligentes, cambió por completo mi enfoque de programación.
Similar a un pianista que puede simplemente ''tocar'' la música porque conoce todas las teclas, su avance no proviene de hacer más cosas que requieren pensamiento, sino de más cosas que no requieren reflexión. El objetivo luego se convierte en hacer que todo lo básico sea fácil ... natural ... subconsciente ... para que todos podamos enfrentarnos a nuestros objetivos de mayor nivel.
Las bibliotecas del lado del cliente, de alguna manera, nos ayudan a hacer justamente eso. ;)
En IE, no puede ocultar elementos de opción seleccionados, solo el elemento de selección en sí. Esto hace que sea difícil cambiar dinámicamente los contenidos de las opciones de selección usando Javascript.
Este problema también existe en Safari y Chrome.
Hay muchos otros problemas con IE, pero este me ha causado la mayor frustración recientemente.
En Internet Explorer (nota: versiones anteriores de IE, no necesariamente versiones 9/10 +), si crea elementos de formulario utilizando document.createElement
, el campo no se enviará con el formulario. La única solución es usar
element.innerHTML = "<input type=''text'' value="+val+" name="+name+">";
Estaba trabajando en el diseño de CSS escrito por alguien que pensaba que el tamaño dado a un elemento es size + padding + border como en IE5 y no solo el cuadro de contenido como se explica en la especificación oficial. Fue escrito hace solo unos meses, así que hizo sucks sucios para que se vea bien en IE7. Me llevó varias horas con FireBug rastrear el origen del problema y para cuando me di cuenta estaba realmente molesto.
Si abres el sitio con CSS "flotante" escrito para IE5 en Firefox, las cajas no tienen espacio suficiente para caber en la página. Si lo abres en IE7 se ve bien, ya que IE7 deja que los bordes se superpongan para que luzca casi correcto. Para alguien tan inexperto como yo, era difícil de notar.
Firefox y IE tienen diferentes configuraciones de tablas en el DOM, en una, todos los hermanos de una celda son las otras celdas, mientras que la otra tiene elementos entre las celdas. No puedo recordar qué camino tomar, pero me dio un verdadero dolor de cabeza en una sola aplicación.
He estado haciendo esto demasiado tiempo para tener muchos problemas, pero todavía me vuelve loco que tengo que hackear IE no es compatible con cosas de CSS como display: table,: last-child y: flotar fuera de los anclajes.
Todas las cosas de IE siguen siendo locos, pero ahora es solo locura de fondo :)
IE6? Meh. Ustedes lo tienen fácil ! ¿Nunca ha tenido que hacer que el diseño de CSS funcione en Netscape 4 (sin bloquear todo el navegador)? ¿Nunca tuvo que escribir para navegadores de dispositivos que no admiten tablas? ¿Nunca tuvo que escribir para IE Mobile ?
no hay soporte para manejadores de eventos asignados por JavaScript; solo puede escribir un controlador de eventos configurando "onclick =" somestring "" en innerHTML;
las propiedades más básicas DOM Nivel 1 (por ejemplo, nodeName, nodeType, nodeValue, firstChild, lastChild, nextSibling, previousSibling, data, value, HTMLElement.getElementsByTagName, todos los miembros HTMLTableElement, la mayoría de los miembros de CSSStyleDeclaration) simplemente no existen;
la mayoría de las propiedades de diseño de CSS no funcionan; muchas propiedades simples de CSS como ''ancho'' no funcionan en algunos elementos como campos de formulario;
configurar muchas otras propiedades de CSS en elementos como tablas y campos de formulario hace que se cuelgue el navegador al instante, lo que significa que, dado que Windows Mobile no tiene un administrador de tareas incorporado, debe reiniciar suavemente el dispositivo;
oh, y poner cualquier cosa que no sea texto dentro de un <botón> es insta-crash también;
enormes pedazos de métodos básicos de JavaScript y métodos "DOM Level 0" que se remontan tan lejos como Netscape 2 (!) faltan.
Y esta es la versión más actualizada del navegador emblemático Windows Mobile de Microsoft en 2009.
Claro, es compatible con XMLHttpRequest, pero escribir código AJAX en un navegador cuyo CSS y script es inferior a IE3 (!) Es extrañamente esquizofrénico, como si estuviera trabajando con una extraña amalgama de tecnologías del siglo XXI y del siglo XIX.
No lo recomendaría.
Inconsistencias en el modelo de caja de CSS cuando se trata de formularios. En particular, es irritante cómo maneja cada navegador el cuadro <seleccionar>
La mayoría de los problemas que tengo son con IE, específicamente IE6. Los problemas con los que personalmente me he enfrentado han dejado una impresión memorable (sin ningún orden en particular):
Tener que usar frameworks para hacer cosas básicas porque cada navegador implementa el DOM de forma un poco diferente. Esto es especialmente atroz con IE y AJAX, que necesita múltiples bloques if para que la llamada comience. En un mundo ideal, podría trabajar en JavaScript sin el marco para hacer cosas básicas.
onChange on select en IE se implementan incorrectamente, y se dispara antes de que la selección pierda el foco (lo cual es incorrecto). Esto significa que nunca puede usar onChange con selecciones debido a IE, ya que los usuarios que solo usan el teclado quedarán paralizados por este problema de implementación.
Usted lo mencionó en su publicación, pero es un gran dolor cuando IE toma un elemento por nombre cuando usa getElementBy Id ().
Cuando se encuentra en un entorno RTL (árabe, hebreo, etc.), Firefox implementa "text-align: right;" incorrectamente. Si el contenedor se desborda por alguna razón, el texto se alinea con el lado derecho del contenedor visible, en lugar del lado derecho del contenedor (incluso si hace que una parte sea invisible).
Los diferentes navegadores tienen diferentes niveles de pickiness con respecto a cómo finaliza arrays y objetos. Por ejemplo, Firefox está más que de acuerdo con una matriz como esta: [item0, item1,] ". Sin embargo, este mismo código hará que Opera pierda porque odia la coma final. IE hará que la matriz sea una matriz de tres elementos, con el tercer elemento indefinido! Esto es un código malo, seguro, pero ha habido javascript generado dinámicamente en el que he trabajado que fue un gran dolor para reescribir, hubiera sido bueno si esto hubiera funcionado.
Todo lo que tiene que ver con hasLayout . Tanto dolor terrible ha girado en torno a este atributo, especialmente cuando no sabía que existía. Tantos problemas solucionados mediante el uso de hacks para agregar hasLayout. Tantos problemas más creados como resultado de los hacks.
Los flotantes en IE raramente funcionan de la manera que esperas que lo hagan. También tienden a ser molestos en otros navegadores, pero al menos se ajustan a un comportamiento particular. ;)
IE agregar espacio en blanco adicional entre los elementos de la lista me ha causado gran dolor, ya que YUI usa listas para crear sus menús. (Para entender completamente el problema, debe ver ese enlace en IE y otro navegador uno al lado del otro).
Tengo muchos problemas para que el texto no se envuelva en contenedores en IE. Otros navegadores escuchan "white-space: nowrap" mucho mejor. Esto ha sido un problema con una interfaz de usuario en la que trabajé que tiene una barra lateral redimensionable; en IE, los elementos de la barra lateral comenzarán a ajustarse si lo cambia demasiado.
La falta de muchos tipos de selector CSS en IE6 significa que debe clasificar su DOM más de lo necesario. Por ejemplo, la falta de +,: hover,: primer hijo.
Los diferentes navegadores tratan los nodos de texto vacíos de forma diferente. Específicamente, al atravesar el DOM con Opera, tengo que preocuparme por los nodos de texto vacíos cuando navego por los elementos secundarios de un nodo. Esto no es un problema si está buscando un artículo en particular, pero lo es si está escribiendo un código que espera una entrada particular y la forma en que el navegador ve esa entrada es diferente.
En IE6, cuando genera dinámicamente un iframe a través de javascript, el iframe a veces no llena su contenedor automáticamente (incluso con ancho y alto establecidos en max). Todavía no sé cómo resolver este problema, y he estado pensando en publicar una pregunta al respecto.
En IE, no puede establecer el desbordamiento de CSS en el elemento <tbody>. Esto significa que las tablas desplazables (con un concrete <thead> y <tfoot>) son imposibles de hacer de una manera simple.
Probablemente añadiré más a esta lista más adelante, ya que (para mí) la peor parte del desarrollo web son los problemas entre navegadores. Además, dudo que alguna vez edite el "Probablemente añadiré más a esta lista más adelante", ya que estos problemas son interminables. :)
Las restricciones de IE sobre el uso de manipulaciones de DOM en las tablas me obligaron a adoptar un enfoque completamente diferente de algo. Muy frustrante al principio, pero lo positivo era que el segundo enfoque era mejor, así que supongo que debería estar agradecido con IE. ;)
Mi mayor problema son los fabricantes de navegadores. Pequeño arrogante * ^ &% s. Quiero decir, no se puede vender un navegador a nadie, sin embargo, todos están en su pequeña esquina intentando hacerse unos a otros, creando divisiones. Oh y Chrome. Chrome todavía no sabe lo que quiere ser, Safari o Firefox. Aparte de su truco de salón, es prácticamente inútil. Les echo la culpa a todos ustedes que siguieron buscando en Google solo porque odian los monopolios. Adivina qué, ahora son el monopolio. Ahora todos podemos disfrutar de software de segunda clase lanzado prematuramente.
Esto se debe principalmente a un error * que tuve en Chrome hoy, nunca me di cuenta de que debía consultar el navegador. Tanto Safari como Chrome fallaban, así que pensé que, una vez que solucioné el problema de Safari, Chrome se arreglaría automáticamente, pero no, no. El Sr. "Ejecuto pestañas en procesos separados". AKA "Sr. Sin pantalla completa" solo tuvo que mantenerme en el bloqueo de lagarto con su implementación alucinante.
También detesto a Firefox. No puedo decir si tengo una infestación de virus o Firebug en ejecución. Ahora, hasta que Adobe decida lanzar un navegador que haga que Flash sea práctico para otras cosas que no sean clips de película, voy a tener algo de lo que quejarme durante mucho tiempo. Y todos sabemos que de eso se trata la vida.
Además, solo disfruto de la programación cuando encuentro errores ridículos que hacen que mis jugos cerebrales corran.
Para eliminar bordes iframe en Internet Explorer, debe especificar el atributo frameborder como formato camelCase, que no es compatible con xhtml.
<iframe frameBorder="0"/>
Una forma fácil de ayudar con los molestos problemas de visualización de IE es usar Firebug, Yep enen en IE 6/7/8. Simplemente use Firebug Lite.
Si agrega lo siguiente como un marcador y lo coloca en su barra de herramientas, Firebug Lite se desactivará de cualquier página web con un solo clic. (solo verifica esto en IE y funciona bien)
javascript:var%20firebug=document.createElement(''script'');firebug.setAttribute(''src'',''http://getfirebug.com/releases/lite/1.2/firebug-lite-compressed.js'');document.body.appendChild(firebug);(function(){if(window.firebug.version){firebug.init();}else{setTimeout(arguments.callee);}})();void(firebug);
mi única pesadilla es IE6, siempre deberías buscar hacks, pero cada vez que te enfrentas a un problema hay alguien que se encontró con esto antes que tú y escribiste en el blog sobre eso (y nunca nos alejaremos de él)
This , básicamente.
Los marcos de JavaScript modernos (jQuery, prototype, etc.) han hecho maravillas para que el código funcione en muchos navegadores a la vez.
El mayor problema que tengo ahora es el hecho de que cualquier tipo de comportamiento rico en UI se ejecuta sorprendentemente lento. IE7 es malo. IE6 es peor. IE8 tiene errores, está medio terminado, y realmente no es mejor que IE7.
Lo peor es que no creo que alguna vez estemos libres de IE6. Era tan ubicuo, y tan malditamente peculiar. Muchas aplicaciones ''empresariales'' (y me refiero a grandes aplicaciones web creadas por una gran empresa para otra gran empresa) usaron Javascript altamente específico de IE6 que ni siquiera funciona en IE7, sin importar nada más.
Las empresas no pueden darse el lujo de reemplazar completamente estas aplicaciones, estamos tratando de venderlas nuevas y eso significa que el soporte de IE6 es obligatorio. Tal como está ahora, con compañías que reducen el costo, creo que seguiremos apoyando IE6 en 2015 :-(