¿Cuáles son las razones típicas por las que Javascript desarrollado en Firefox falla en IE? [cerrado]

108

Desarrollé algunas páginas mejoradas con javascript que funcionan bien en Firefox y Safari recientes. Me perdí de comprobar en Internet Explorer, y ahora encuentro que las páginas no funcionan en IE 6 y 7 (hasta ahora). Los scripts de alguna manera no se ejecutan, las páginas se muestran como si javascript no estuviera allí, aunque se ejecuta algo de javascript. Estoy usando bibliotecas propias con manipulación de dom, de YUI 2 uso YUI-Loader y XML-Http-Request, y en una página uso "psupload", que depende de JQuery.

Estoy instalando Microsoft Script Editor desde Office XP y ahora depuraré. También escribiré pruebas específicas ahora.

¿Cuáles son los puntos de falla típicos de IE? En qué dirección puedo mantener los ojos abiertos.

Encontré esta página, que muestra algunas diferencias. visita: Quirksmode

¿Puede, por su experiencia, nombrar algunas cosas típicas que debería buscar primero?

También haré más preguntas aquí para tareas específicas más adelante, pero por ahora estoy interesado en su experiencia por qué IE generalmente falla en scripts que funcionan bien en Firefox

Editar: ¡ Gracias por todas esas excelentes respuestas!

Mientras tanto, he adaptado todo el código para que también funcione con Internet Explorer. Integré jQuery y construí mis propias clases sobre él ahora. Este fue mi error básico, que no construí todas mis cosas en jQuery desde el principio. Ahora tengo.

También JSLint me ayudó mucho.

Y muchos de los problemas individuales de las diferentes respuestas ayudaron.

user89021
fuente
Hasta ahora no hay problemas con CSS o el estilo, ya que lo sabía por la codificación anterior. Solo problemas de JS - karlthorwald
user89021
1
Primero ejecutaré JSLint ahora en todos los archivos, hay algunos que nunca adapté.
user89021
7
"Este fue mi error básico, que no construí todas mis cosas en jQuery desde el principio". - no va a resolver mágicamente todos sus problemas entre navegadores. Busque stackoverflow para jQuery e IE, encontrará toneladas de problemas. Es mejor aprender a realizar scripts entre navegadores usted mismo, de modo que cuando jQuery o uno de sus miles de millones de complementos incompletos falle, podrá implementar una solución real entre navegadores y saber que funciona y por qué.
Dagg Nabbit
11
+1 en el comentario anterior de no. Es MUCHO mejor que evite jQuery por completo IFF, está aprendiendo javascript: jQuery es increíblemente útil si desea hacer algo complejo de manera rápida y fácil, pero si está aprendiendo, lo protegerá de las complejidades de comprender cómo javascript realmente funciona - demasiada gente parece conocer jQuery pero no tiene ni idea de cómo escribir javascript. No cometió un error al no construir en jQuery originalmente; ahora tiene una comprensión mucho mejor de su propio código de lo que lo haría si lo tuviera.
lucideer

Respuestas:

121

No dude en actualizar esta lista si ve algún error u omisión, etc.

Nota: IE9 corrige muchos de los siguientes problemas, por lo que gran parte de esto solo se aplica a IE8 y versiones anteriores y, hasta cierto punto, IE9 en modo peculiar. Por ejemplo, IE9 soporta SVG, <canvas>, <audio>y <video>de forma nativa, sin embargo se debe habilitar el modo de cumplimiento de normas para que estén disponibles.


General:

  • Problemas con documentos parcialmente cargados: es una buena idea agregar su JavaScript en un window.onloadevento o similar, ya que IE no admite muchas operaciones en documentos parcialmente cargados.

  • Atributos diferentes : en CSS, está elm.style.styleFloaten IE frente a elm.style.cssFloaten Firefox. En las <label>etiquetas, forse accede al atributo elm.htmlForen IE vs elm.foren Firefox. Tenga en cuenta que forestá reservado en IE, por elm['for']lo que probablemente sea una mejor idea evitar que IE genere una excepción.


Lenguaje base de JavaScript:

  • Acceder a caracteres en cadenas : 'string'[0]no es compatible con IE ya que no está en las especificaciones originales de JavaScript. Use 'string'.charAt(0)o 'string'.split('')[0]tenga en cuenta que acceder a elementos en matrices es significativamente más rápido que usar charAtcon cadenas en IE (aunque hay una sobrecarga inicial cuando splitse llama por primera vez).

  • Comas antes del final de los objetos: por ejemplo {'foo': 'bar',}, no se permiten en IE.


Problemas específicos del elemento:

  • Obteniendo el documentde un IFrame :

    • Firefox e IE8 +: IFrame.contentDocument (IE comenzó a admitir esto desde la versión 8 ).
    • ES DECIR: IFrame.contentWindow.document
    • (se IFrame.contentWindowrefiere a windowen ambos navegadores).

  • Canvas: las versiones de IE anteriores a IE9 no admiten el <canvas>elemento. IE admite VML, que es una tecnología similar, sin embargo, explorercanvas puede proporcionar un contenedor in situ para <canvas>elementos para muchas operaciones. Tenga en cuenta que IE8 en el modo de cumplimiento de estándares es muchas veces más lento y tiene muchos más fallos que en el modo de peculiaridades cuando se usa VML.

  • SVG: IE9 admite SVG de forma nativa. IE6-8 puede admitir SVG, pero solo con complementos externos y solo algunos de esos complementos admiten la manipulación de JavaScript.

  • <audio>y <video>: solo se admiten en IE9.

  • Creación dinámica de botones de document.createElementopción : IE <8 tiene un error que hace que los botones de opción creados con no se puedan marcar. Consulte también ¿Cómo se crea dinámicamente un botón de opción en Javascript que funcione en todos los navegadores? para una forma de evitar esto.

  • JavaScript incrustado en <a href>etiquetas y onbeforeunloadconflictos en IE: si hay JavaScript incrustado en la hrefparte de una aetiqueta (por ejemplo <a href="javascript: doStuff()">, IE siempre mostrará el mensaje devuelto a onbeforeunloadmenos que el onbeforeunloadcontrolador se elimine de antemano. Consulte también Solicitar confirmación al cerrar una pestaña .

  • <script>diferencias de evento de etiqueta: onsuccess y onerrorno son compatibles con IE y se reemplazan por un IE específico onreadystatechangeque se activa independientemente de si la descarga se realizó correctamente o no. Consulte también JavaScript Madness para obtener más información.


Tamaño / posición / desplazamiento del elemento y posición del mouse:

  • Obtener el tamaño / posición del elemento: el ancho / alto de los elementos a veces está elm.style.pixelHeight/Widthen IE en lugar de elm.offsetHeight/Width, pero ninguno es confiable en IE, especialmente en modo peculiar, y a veces uno da un mejor resultado que el otro.

    elm.offsetTopy a elm.offsetLeftmenudo se informan incorrectamente, lo que lleva a encontrar que las posiciones de los elementos son incorrectas, razón por la cual los elementos emergentes, etc., tienen algunos píxeles de diferencia en muchos casos.

    También tenga en cuenta que si un elemento (o un padre del elemento) tiene una displayde, noneentonces IE generará una excepción al acceder a los atributos de tamaño / posición en lugar de regresar 0como lo hace Firefox.

  • Obtenga el tamaño de la pantalla (obteniendo el área visible de la pantalla):

    • Firefox: window.innerWidth/innerHeight
    • Modo de estándares IE: document.documentElement.clientWidth/clientHeight
    • Modo de peculiaridades de IE: document.body.clientWidth/clientHeight

  • Posición de desplazamiento del documento / posición del mouse : este en realidad no está definido por el w3c, por lo que no es estándar ni siquiera en Firefox. Para encontrar el scrollLeft/ scrollTopde document:

    • Firefox e IE en modo peculiar: document.body.scrollLeft/scrollTop
    • IE en modo estándar: document.documentElement.scrollLeft/scrollTop
    • NOTA: Algunos otros navegadores también usan pageXOffset/ pageYOffset.

      function getDocScrollPos() {
       var x = document.body.scrollLeft ||
               document.documentElement.scrollLeft ||
               window.pageXOffset || 0,
           y = document.body.scrollTop ||
               document.documentElement.scrollTop ||
               window.pageYOffset || 0;
       return [x, y];
      };

    Para obtener la posición del cursor del mouse, evt.clientXy evt.clientYen los mousemoveeventos, dará la posición relativa al documento sin agregar la posición de desplazamiento, por lo que será necesario incorporar la función anterior:

    var mousepos = [0, 0];
    document.onmousemove = function(evt) {
     evt = evt || window.event;
     if (typeof evt.pageX != 'undefined') {
      // Firefox support
      mousepos = [evt.pageX, evt.pageY];
     } else {
      // IE support
      var scrollpos = getDocScrollPos();
      mousepos = [evt.clientX+scrollpos[0], evt.clientY+scrollpos[1]];
     };
    };

Selecciones / rangos:

  • <textarea> y <input> selecciones : selectionStarty selectionEndno están implementadas en IE, y hay un sistema de "rangos" propietario en su lugar, vea también la posición de Caret en textarea, en caracteres desde el principio .

  • Obtener el texto seleccionado actualmente en el documento:

    • Firefox: window.getSelection().toString()
    • ES DECIR: document.selection.createRange().text


Obtener elementos por ID:

  • document.getElementByIdtambién puede hacer referencia al nameatributo en formularios (dependiendo de cuál se defina primero en el documento) por lo que es mejor no tener diferentes elementos que tengan el mismo namey id. Esto se remonta a los días en que idno era un estándar de w3c. document.all( una propiedad patentada específica de IE ) es significativamente más rápido que document.getElementById, pero tiene otros problemas, ya que siempre prioriza nameantes id. Yo personalmente uso este código, retrocediendo con verificaciones adicionales solo para estar seguro:

    function getById(id) {
     var e;
     if (document.all) {
      e = document.all[id];
      if (e && e.tagName && e.id === id) {
       return e;
      };
     };
     e = document.getElementById(id);
     if (e && e.id === id) {
      return e;
     } else if (!e) {
      return null;
     } else {
      throw 'Element found by "name" instead of "id": ' + id;
     };
    };

Problemas con innerHTML de solo lectura:

  • IE no es compatible con el establecimiento de la innerHtml col, colGroup, frameSet, html, head, style, table, tBody, tFoot, tHead, title, y trelementos. Aquí hay una función que funciona en torno a eso para los elementos relacionados con la tabla:

    function setHTML(elm, html) {
     // Try innerHTML first
     try {
      elm.innerHTML = html;
     } catch (exc) {
      function getElm(html) {
       // Create a new element and return the first child
       var e = document.createElement('div');
       e.innerHTML = html;
       return e.firstChild;
      };
      function replace(elms) {
       // Remove the old elements from 'elm'
       while (elm.children.length) {
        elm.removeChild(elm.firstChild);
       }
       // Add the new elements from 'elms' to 'elm'
       for (var x=0; x<elms.children.length; x++) {
        elm.appendChild(elms.children[x]);
       };
      };
      // IE 6-8 don't support setting innerHTML for
      // TABLE, TBODY, TFOOT, THEAD, and TR directly
      var tn = elm.tagName.toLowerCase();
      if (tn === 'table') {
       replace(getElm('<table>' + html + '</table>'));
      } else if (['tbody', 'tfoot', 'thead'].indexOf(tn) != -1) {
       replace(getElm('<table><tbody>' + html + '</tbody></table>').firstChild);
      } else if (tn === 'tr') {
       replace(getElm('<table><tbody><tr>' + html + '</tr></tbody></table>').firstChild.firstChild);
      } else {
       throw exc;
      };
     };
    };

    También tenga en cuenta que IE requiere agregar a <tbody>a <table>antes de agregar <tr>s a ese <tbody>elemento al crear usando document.createElement, por ejemplo:

    var table = document.createElement('table');
    var tbody = document.createElement('tbody');
    var tr = document.createElement('tr');
    var td = document.createElement('td');
    table.appendChild(tbody);
    tbody.appendChild(tr);
    tr.appendChild(td);
    // and so on

Diferencias de eventos:

  • Obtener la eventvariable: los eventos DOM no se pasan a funciones en IE y son accesibles como window.event. Una forma común de obtener el evento es usar, por ejemplo,
    elm.onmouseover = function(evt) {evt = evt||window.event}
    el valor predeterminado window.eventsi evtno está definido.

  • Diferencias clave en el código de eventos: los códigos de eventos clave varían enormemente, aunque si nos fijamos en Quirksmode o JavaScript Madness , no es específico de IE, Safari y Opera son diferentes nuevamente.

  • Diferencias de eventos del mouse: el buttonatributo en IE es un indicador de bits que permite múltiples botones del mouse a la vez:

    • Izquierda: 1 ( var isLeft = evt.button & 1)
    • Derecha: 2 ( var isRight = evt.button & 2)
    • Centro: 4 ( var isCenter = evt.button & 4)

      El modelo W3C (compatible con Firefox) es menos flexible que el modelo IE, con solo un botón permitido a la vez con la izquierda como 0, la derecha como 2y el centro como 1. Tenga en cuenta que, como Peter-Paul Koch menciona , esto es muy contrario a la intuición, ya que 0por lo general significa 'ningún botón'.

      offsetXy offsetYson problemáticos y probablemente sea mejor evitarlos en IE. Una forma más confiable de obtener el offsetXy offsetYen IE sería obtener la posición del elemento relativamente posicionado y restarlo de clientXyclientY .

      También tenga en cuenta que en IE para conseguir un doble clic en un clickevento que había necesidad de registrar la vez una clicky dblclickeventos a una función. Firefox se dispara clickal igual que dblclickcuando se hace doble clic, por lo que se necesita una detección específica de IE para tener el mismo comportamiento.

  • Las diferencias en el caso de modelo de manipulación: Tanto el modelo propietario IE y el modelo de manipulación de soporte Firefox de eventos de la parte inferior hacia arriba, por ejemplo, si hay eventos en ambos elementos de <div><span></span></div>eventos luego se disparará en el span entonces ladiv lugar de la orden que están consolidado si elm.onclick = function(evt) {}se utilizó un ejemplo tradicional .

    Los eventos de "captura" generalmente solo son compatibles con Firefox, etc., lo que activará divlos spaneventos en un orden de arriba hacia abajo. IE tiene elm.setCapture()y elm.releaseCapture()para redirigir los eventos del mouse del documento al elemento ( elmen este caso) antes de procesar otros eventos, pero tienen una serie de problemas de rendimiento y otros, por lo que probablemente deberían evitarse.

    • Firefox:

      Adjuntar : elm.addEventListener(type, listener, useCapture [true/false])
      Separar : elm.removeEventListener(type, listener, useCapture)
      ( typepor ejemplo, 'mouseover'sin el on)

    • IE: solo se puede agregar un evento de un tipo determinado en un elemento en IE; se genera una excepción si se agrega más de un evento del mismo tipo. También tenga en cuenta que se thisrefiere al windowelemento enlazado en lugar del elemento enlazado en las funciones de evento (por lo que es menos útil):

      Adjuntar : elm.attachEvent(sEvent, fpNotify)
      Separar : elm.detachEvent(sEvent, fpNotify)
      ( sEventes por ejemplo 'onmouseover')

  • Diferencias de atributos de eventos:

    • Evitar que los eventos sean procesados ​​por otras funciones de escucha :

      Firefox: evt.stopPropagation()
      IE: evt.cancelBubble = true

    • Evite, por ejemplo, que los eventos clave inserten caracteres o impidan que las casillas de verificación se marquen:

      Firefox: evt.preventDefault()
      IE: evt.returnValue = false
      Nota: Sólo volviendo falseen keydown, keypress, mousedown, mouseup, clicky resettambién evitar un impago.

    • Obtenga el elemento que desencadenó el evento:

      Firefox: evt.target
      IE: evt.srcElement

    • Obtener el elemento del que se alejó el cursor del mouse: evt.fromElement en IE está evt.targeten Firefox si es un onmouseoutevento, de lo contrarioevt.relatedTarget

    • Obtener el elemento al que se movió el cursor del mouse: evt.toElement en IE está evt.relatedTargeten Firefox si en un onmouseoutevento, de lo contrarioevt.target

    • Nota: evt.currentTarget (el elemento al que estaba vinculado el evento) no tiene equivalente en IE.

crio
fuente
12
¡Muy, muy, muy buena lista! Gracias a todos los que contribuyeron :)
cwap
26

Compruebe también si hay comas como estas o similares si las hay en su código

var o={
'name1':'value1',
'name2':'value2',
} 

la última coma (después de value2) será tolerada por Firefox, pero no IE

Luca Rocchi
fuente
1
La mayoría de los buenos editores deberían captar este
SeanJA
1
+1, tuve este con demasiada frecuencia.
David V.
1
Te daría +10 si pudiera, esto me pasa todo el tiempo.
Josh
Ah, y para agregar al comentario de @ SeanJA: recientemente me cambié a NetBeans, que detecta esto.
Josh
Perdí tantas horas en esto las primeras veces que hice un trabajo de JS. ¡Ahora es lo primero que reviso! Maldice las expansiones de Textmate de mierda dejando comas alrededor.
Agos
12

Si sigues usando jQuery o YUI cuando tu publicación está etiquetada, deberías tener diferencias mínimas entre los navegadores ... para eso están los frameworks, para solucionar estas diferencias entre navegadores por ti.

Por ejemplo, mire la página de recorrido de DOM de quirksmode , según ella, IE no es compatible con la mayoría de las cosas ... aunque es cierto, los marcos sí, por ejemplo, IE no es compatible elem.childElementCount, pero en jQuery:$(elem).children().size() funciona para obtener este valor, en todos los navegadores. Encontrará que hay algo en la biblioteca para manejar el 99% de los casos no compatibles en todos los navegadores, al menos con un script ... con CSS, es posible que tenga que pasar a complementos para la biblioteca, un ejemplo común de esto es obtener esquinas redondeadas trabajando en IE ... ya que no tiene soporte CSS para tal.

Sin embargo, si empiezas a hacer las cosas directamente, document.XXX(thing)entonces no estás en la biblioteca, estás haciendo javascript directamente (todo es javascript, pero entiendes el punto :), y esto podría o no causar problemas, dependiendo de cómo borracho estaba el equipo de IE al implementar esa función en particular.

Con IE, es más probable que falle en el estilo que sale bien que en problemas de javascript sin procesar, animaciones con unos pocos píxeles de diferencia y ese tipo de cosas, mucho más en IE6, por supuesto.

Nick Craver
fuente
Ahora entiendo mejor. Sí, también hice esas cosas directamente. karlthorwald
user89021
1
Si está utilizando un IDE como Netbeans, puede configurar los navegadores de destino para su javascript y también le ayudará advirtiéndole cuando haga algo que no parece ser compatible.
SeanJA
10

getElementbyID también coincidirá con el atributo de nombre en IE, pero no con otros navegadores, e IE seleccionará el que encuentre primero.

ejemplo:

<script>
 var foo = document.getElementById('bar');
</script>

....
<input name="bar" type="text" />  //IE will get this element
<span id="bar"> Hello, World! </span>  //FF,Safari,Chrome will get this element
GSto
fuente
3
lo siento por ser grosero pero IE es realmente feo
user89021
12
document.getElementByIdOrNameIGuessWhateverMan (id);
JulianR
5

Hay muchas cosas, pero una trampa en la que solía caer era que muchos navegadores aceptan JSON sin nombres entre comillas, mientras que ie6 e ie7 no.

{ name: "Jakob" } // will often work, but not in ie6/ie7
{ "name": "Jakob" } // Better!

Editar : para aclarar, esto es solo un problema cuando se requiere JSON real, a diferencia de un objeto literal. JSON es un subconjunto de la sintaxis literal del objeto y está diseñado como un formato de intercambio de datos (como XML), por lo que está diseñado para ser más exigente.

Jakob
fuente
2
Tenga en cuenta que esto depende del contexto, un objeto literal está bien, JSON no ... pero, por ejemplo, jQuery no permite JSON no válido en su última versión.
Nick Craver
No es mi voto negativo ... pero deberías aclarar esto para los demás, luego +1 de mí.
Nick Craver
5

Diferentes compatibilidad con JavaScript

IE no admite (la mayoría de) las extensiones agregadas a JavaScript desde la 1.5.

Nuevo en 1.6

  • Métodos de matriz - indexOf(), lastIndexOf(), every(), filter(), forEach(), map(),some()
  • for each ... in - itera valores en lugar de nombres de propiedades.

Nuevo en 1.7

Nuevo en 1.8

  • Métodos de matriz - reduce(),reduceRight()
  • Atajos para definir funciones.

Algunas de estas cosas requieren que especifique un número de versión de JavaScript para ejecutar (que se romperá en IE), pero algunas cosas como [1,2,3].indexOf(2)pueden no parecer tan importantes, hasta que intente ejecutarlo en IE

gnarf
fuente
1
el JavaScript del que está hablando aquí es JavaScript (TM) de mozilla, no javascript en el sentido más genérico. No se debe esperar que todas las implementaciones de ECMAScript / motores javascript (MS JScript en este caso) sigan el JavaScript (TM) de mozilla. ECMAScript es el estándar, no JavaScript (TM), y JavaScript (TM) no es JavaScript. Espero que tenga sentido.
Dagg Nabbit
Tiene sentido para mí, pero en un hilo sobre la compatibilidad entre JavaScript y JScript, pensé que ya se entendería :)
gnarf
Cuando dice "IE no admite (la mayoría de) las extensiones agregadas a JavaScript desde la 1.5.", Parece que está diciendo que JavaScript (TM) de mozilla es un estándar al que debe adherirse IE, cuando por supuesto que no lo es. Podría al menos decir JavaScript de Mozilla o similar ... otro navegador no es compatible con todas las extensiones de mozilla para ECMAScript como asignaciones de desestructuración, etc. La pregunta era sobre las diferencias entre 'la mayoría' javascripty (la implementación específica) JScript, no las diferencias entre Mozilla JavaScript(TM)y JScript. Podría ser mejor mostrar dónde se desvía IE de ES.
Dagg Nabbit
3

Las principales diferencias entre JavaScript en IE y JavaScript en los navegadores modernos (por ejemplo, Firefox) se pueden atribuir a las mismas razones detrás de las diferencias en CSS / (X) HTML entre navegadores. En el pasado, no existía un estándar de facto; IE / Netscape / Opera pelearon una guerra territorial, implementando la mayoría de las especificaciones, pero también omitiendo algunas, así como haciendo especificaciones propietarias para obtener ventajas entre sí. Podría continuar, pero saltemos al lanzamiento de IE8: JavaScript se evitó / despreció durante años, y con el aumento de FF y el desprecio de webcomm, IE eligió centrarse principalmente en avanzar su CSS desde IE6 en adelante. Y básicamente dejó atrás el soporte DOM. El soporte DOM de IE8 bien podría ser el de IE6, que se lanzó en 2001 ... así que el soporte DOM de IE está casi una década por detrás de los navegadores modernos. Si tiene discrepancias de JavaScript específicas de un motor de diseño, lo mejor es atacarlo de la misma manera que abordamos los problemas de CSS; Apuntando a ese navegador. NO USE SNIFFING DEL NAVEGADOR, use la detección de funciones para olfatear su navegador / su nivel de soporte DOM.

JScript no es la propia implementación de IE de ECMAScript; JScript fue la respuesta de IE al JavaScript de Netscape, ambos existieron antes de ECMAScript.

En cuanto a los atributos de tipo en el elemento de script, type = "text / javascript" es el estándar predeterminado (al menos en HTML5), por lo que nunca necesitará un atributo de tipo a menos que su script no sea JavaScript.

En la medida en que IE no es compatible con innerHTML ... innerHTML fue inventado por IE y todavía hoy NO es un estándar DOM. Otros navegadores lo han adoptado porque es útil, por lo que puede usarlo en varios navegadores. En cuanto al cambio dinámico de tablas, MSDN dice "debido a la estructura específica requerida por las tablas, las propiedades innerText e innerHTML de la tabla y los objetos tr son de solo lectura". No sé cuánto de eso fue cierto inicialmente, pero claramente los navegadores modernos lo han descubierto al lidiar con las complejidades del diseño de tablas.

Recomiendo leer PPK en JavaScript Scripting DOM de Jeremy Keith, de Douglas Crockford : The Good Parts y JavaScript Beginning de Christian Hellman con Scripting DOM y Ajax para obtener una sólida comprensión de JavaScript.

En lo que respecta a Frameworks / Libraries, si aún no tiene un conocimiento sólido de JavaScript, debe evitarlos. Hace 2 años caí en la trampa de jQuery, y aunque pude realizar hazañas magníficas, nunca aprendí nada sobre codificar JavaScript correctamente. En retrospectiva, jQuery es un increíble juego de herramientas DOM, pero mi incapacidad para aprender los cierres adecuados, la herencia prototípica, etc., no solo hizo retroceder mi conocimiento personal, mi trabajo comenzó a tener grandes impactos de rendimiento porque no tenía ni idea de lo que estaba haciendo.

JavaScript es el idioma del navegador; Si usted es un ingeniero del lado del cliente / front-end, es de suma importancia que controle JavaScript. Node.js está trayendo JavaScript al máximo, veo inmensos avances a diario en su desarrollo; JavaScript del lado del servidor será un estándar en un futuro muy cercano. Menciono esto para enfatizar aún más cuán importante es JavaScript ahora y será.

JavaScript va a hacer más olas que Rails.

¡Feliz secuencia de comandos!

Albert
fuente
2
Buena respuesta, aunque no estoy de acuerdo con usar la detección de funciones para rastrear el navegador; solo use la detección de funciones para probar la compatibilidad con esas funciones. Consulte también los ejemplos en La detección de características no es detección de navegador .
Marcel Korpel
meh. Estoy completamente de acuerdo con tu desacuerdo. gracias por coger eso. Todavía soy un JavaScript n00b, pero no hay vergüenza en mi juego. "La detección del navegador basada en funciones es una práctica muy mala que debe evitarse a toda costa. La detección directa de funciones es una práctica recomendada y, en casi todos los casos, es exactamente lo que necesita".
albert
2

Algunos objetos nativos son de solo lectura sin que realmente parezcan serlo (puede escribir en ellos pero no tiene ningún efecto). Por ejemplo, un javascript avanzado común se basa en extender el Elementobjeto anulando los métodos del sistema, por ejemplo, cambiando Element.prototype.appendChild () para hacer más que agregar un nodo secundario, por ejemplo, inicializarlo con los datos de los padres. Esto fallará silenciosamente en IE6: el método original se invocará en los objetos nuevos en lugar del nuevo.

Algunos navegadores (no recuerdo cuál ahora) consideran las nuevas líneas entre las etiquetas HTML como nodos de texto, mientras que otros no lo hacen. Entonces childNodes (n), nextSibling (), firstChild () y similares se comportarán de manera muy diferente.

SF.
fuente
2

Las comas finales en matrices y objetos literales solían ser un problema, no se han verificado recientemente (es decir, IE8):

var a = [ 1, 2, 3, ];
var o = { a:1, b:2, c:3, };

Esto causaría algo de código adicional al generar dichas estructuras en el lado del servidor.

npup
fuente
2

Acabo de encontrar uno esta mañana, un compañero de trabajo estableció la etiqueta del script como: <script type="application/javascript">porque su autocompletado de ide tenía eso antes de "text / javascript"

Pero, resulta que IE simplemente ignora todo el script si usa "aplicación / javascript", necesita usar "texto / javascript"

Katjones
fuente
javascript es predeterminado en todos los navegadores, así que use solo<script>
Lauri
2

Encontré una peculiaridad el otro día con Internet Explorer. Estaba usando YUI y reemplazando el contenido de un cuerpo de tabla () configurando el innerHTML

Y.one('#elementId').set('innerHTML', '<tr><td>Column 1</td></tr>');

Esto funcionaría en todos los navegadores EXCEPTO IE. Finalmente descubrí que no se podía reemplazar el innerHTML de una tabla en IE. Tuve que crear un nodo usando YUI y luego agregar ese nodo.

var myNode = Y.node.create('<tr><td>Column 1</td></tr>');
Y.one('#elementId').append(myNode);

¡Fue divertido descubrirlo!

Justin
fuente
1
Tengo la sensación de que debes envolverlo con <tbody>etiquetas.
Casey Chu
En el código original, en realidad está envuelto en una etiqueta <tbody>. Todavía me sorprende que a IE no le haya gustado. Recuerdo haber leído sobre él en los documentos oficiales de Microsoft, pero ahora no puedo encontrar el enlace. ¡Lo siento!
Justin
1

Las comas adicionales y las comas faltantes solían ser un problema habitual en IE, mientras que funciona sin problemas en FF.

Profundo
fuente
1

IE es muy estricto sobre la falta de ";" también suele ser eso.

Sam3k
fuente
Encuentro muchos de estos mientras estoy jsLinting ahora. Parece ser un punto importante.
user89021
1

Por lo que vale, acabo de encontrarme con este desagradable problema en <IE9

digamos que tienes un html como este:

<table><tr><td>some content...</td></tr></table>

y por alguna razón (tuve una buena) necesita recuperar todo el HTML en la tabla antes del último TR de cierre, puede intentar algo como esto:

var tableHtml = document.getElementById('thetable').innerHTML;
var fragment = tableHtml.substring(0, tableHtml.lastIndexOf('</tr>'));

<IE9 no devolverá nada (-1) aquí porque la variable tableHtml contiene todas las etiquetas html en mayúsculas y lastIndexOf distingue entre mayúsculas y minúsculas. Para evitar esto, tuve que lanzar un toLowerCase () antes de lastIndexOf.

tomfumb
fuente
0

IE no es un navegador moderno y solo sigue ECMAScript libremente.

Robar
fuente
0

Mencionaste jQuery con el que estoy menos familiarizado, pero como referencia general, y específicamente con Prototype, una cosa a tener en cuenta son las palabras reservadas / nombres de métodos en IE. Sé que lo que a menudo me molesta son cosas como:

someElement.appendChild(new Element('label',{ **for**: someInput.id }).update( someLabelText );

(new Element (tagName, propertyHash) es cómo se crean nuevos elementos en Protitype). En IE, for:debe ser 'for':, porque fores una palabra reservada. Lo que tiene mucho sentido, pero FireFox lo tolerará.

Otro ejemplo:

someElement.wrap('div').addClassName('someClass')

(el wrapmétodo en Prototype envuelve un elemento en otro) - En IE, en áreas de texto, wrapes una propiedad y Element.wrap()debe usarse en lugar de la versión metodizada

Estos son dos ejemplos que me vienen a la mente de mi experiencia. Se basan en un prototipo, pero el problema principal no es: Tenga cuidado con los métodos / etiquetas / identificadores que IE considera palabras reservadas pero que FireFox o Safari tolerarán.

Josh
fuente
0

El hecho es que IE no es compatible con JavaScript ... Es compatible con su propia implementación de ECMAScript: JScript ... que es algo diferente ...

xavierm02
fuente
0

El uso console.log()para enviar errores a la consola de errores de Firefox hará que sus scripts fallen en IE. Tengo que recordar quitarlos cuando pruebes en IE.

Erikk Ross
fuente
Creo que el uso de console.log también fallará incluso en Firefox si no tienes FireBug activado.
ejel