Quelles sont les raisons typiques pour lesquelles Javascript développé sur Firefox échoue sur IE? [fermé]

108

J'ai développé des pages améliorées javascript qui fonctionnent bien sur Firefox et Safari récents. J'ai manqué de vérifier dans Internet Explorer, et maintenant je trouve que les pages ne fonctionnent pas sur IE 6 et 7 (jusqu'à présent). Les scripts ne sont pas exécutés d'une manière ou d'une autre, les pages s'affichent comme si javascript n'était pas là, bien que certains javascript soient exécutés. J'utilise mes propres bibliothèques avec manipulation dom, de YUI 2 j'utilise YUI-Loader et XML-Http-Request, et sur une page j'utilise "psupload", qui dépend de JQuery.

J'installe Microsoft Script Editor à partir d'Office XP et je vais maintenant déboguer. J'écrirai également des tests spécifiques maintenant.

Quels sont les points de défaillance typiques d'IE? Dans quelle direction je peux garder les yeux ouverts.

J'ai trouvé cette page, qui montre quelques différences. visite: Quirksmode

Pouvez-vous, d'après votre expérience, nommer des éléments typiques que je devrais rechercher en premier?

Je poserai également plus de questions ici pour des tâches spécifiques plus tard, mais pour l'instant, je suis intéressé par votre expérience des raisons pour lesquelles IE échoue généralement sur les scripts qui fonctionnent bien dans Firefox

Edit: Merci pour toutes ces bonnes réponses!

En attendant, j'ai adapté l'ensemble du code pour qu'il fonctionne également avec Internet Explorer. J'ai intégré jQuery et construit mes propres classes dessus maintenant. C'était mon erreur fondamentale, de ne pas avoir construit tout mon contenu sur jQuery depuis le début. Maintenant j'ai.

JSLint m'a également beaucoup aidé.

Et bon nombre des problèmes uniques des différentes réponses ont aidé.

user89021
la source
Il n'y a pas de problèmes avec le CSS ou le style jusqu'à présent, comme je le savais grâce au codage précédent. Seuls les problèmes de JS - karlthorwald
user89021
1
Je vais d'abord lancer JSLint maintenant sur tous les fichiers, il y en a que je n'ai jamais adaptés.
user89021
7
"C'était mon erreur de base, de ne pas avoir construit tout mon contenu sur jQuery depuis le début." - cela ne résoudra pas comme par magie tous vos problèmes entre navigateurs. Recherchez stackoverflow pour jQuery et IE, vous trouverez des tonnes de problèmes. Il est préférable d'apprendre vous-même la création de scripts multi-navigateurs.Ainsi, lorsque jQuery ou l'un de ses milliards de plugins sommaires échoue, vous serez en mesure de mettre en œuvre une véritable solution multi-navigateurs fonctionnelle, et de savoir que cela fonctionne, et pourquoi.
Dagg Nabbit
11
+1 Sur le commentaire de non ci-dessus. Vous êtes de loin préférable d'éviter complètement jQuery IFF vous apprenez javascript - jQuery est incroyablement utile si vous voulez faire quelque chose de complexe rapidement et facilement, mais si vous apprenez, cela vous protégera de la complexité de comprendre comment javascript réellement fonctionne - beaucoup trop de gens semblent connaître jQuery mais ne savent pas comment écrire du javascript. Vous n'avez pas fait d'erreur en ne vous basant pas sur jQuery à l'origine - vous avez maintenant une bien meilleure compréhension de votre propre code que si vous l'aviez fait.
lucideer

Réponses:

121

N'hésitez pas à mettre à jour cette liste si vous voyez des erreurs / omissions, etc.

Remarque: IE9 corrige bon nombre des problèmes suivants, donc une grande partie de cela ne s'applique qu'à IE8 et aux versions antérieures et dans une certaine mesure à IE9 en mode bizarreries. Par exemple, IE9 supporte SVG, <canvas>, <audio>et en mode <video>natif, mais vous devez activer le mode de conformité aux normes pour qu'elles soient disponibles.


Général:

  • Problèmes avec les documents partiellement chargés: c'est une bonne idée d'ajouter votre JavaScript dans un window.onloadévénement ou un événement similaire, car IE ne prend pas en charge de nombreuses opérations dans les documents partiellement chargés.

  • Attributs différents : en CSS, c'est elm.style.styleFloatdans IE par rapport elm.style.cssFloatà Firefox. Dans les <label>balises, l' forattribut est accessible avec elm.htmlFordans IE vs elm.fordans Firefox. Notez que cela forest réservé dans IE, elm['for']c'est donc probablement une meilleure idée pour empêcher IE de déclencher une exception.


Langage JavaScript de base:

  • Accéder aux caractères dans les chaînes : 'string'[0]n'est pas pris en charge dans IE car il ne figure pas dans les spécifications JavaScript d'origine. Utilisez 'string'.charAt(0)ou 'string'.split('')[0]notez que l'accès aux éléments dans les tableaux est beaucoup plus rapide que l'utilisation charAtavec des chaînes dans IE (bien qu'il y ait une surcharge initiale lors du splitpremier appel.)

  • Les virgules avant la fin des objets: par exemple, {'foo': 'bar',}ne sont pas autorisées dans IE.


Problèmes spécifiques aux éléments:

  • Obtenir le documentd'un IFrame :

    • Firefox et IE8 +: IFrame.contentDocument (IE a commencé à prendre en charge cela à partir de la version 8. )
    • C'EST À DIRE: IFrame.contentWindow.document
    • ( IFrame.contentWindowfait référence au windowdans les deux navigateurs.)

  • Canvas: les versions d'IE antérieures à IE9 ne prennent pas en charge l' <canvas>élément. Cependant, IE prend en charge VML qui est une technologie similaire, et explorercanvas peut fournir un wrapper sur place pour les <canvas>éléments de nombreuses opérations. Sachez que IE8 en mode de conformité aux normes est plusieurs fois plus lent et comporte beaucoup plus de problèmes qu'en mode bizarreries lors de l'utilisation de VML.

  • SVG: IE9 prend en charge SVG nativement. IE6-8 peut prendre en charge SVG, mais uniquement avec des plugins externes avec seulement certains de ces plugins prenant en charge la manipulation JavaScript.

  • <audio>et <video>: ne sont pris en charge que dans IE9.

  • Création dynamique de boutons radio: IE <8 a un bogue qui rend les boutons radio créés avec document.createElementuncheckable. Voir aussi Comment créer dynamiquement un bouton radio en Javascript qui fonctionne dans tous les navigateurs? pour un moyen de contourner cela.

  • JavaScript incorporé dans les <a href>balises et onbeforeunloadconflits dans IE: S'il y a du JavaScript intégré dans la hrefpartie d'une abalise (par exemple, <a href="javascript: doStuff()">IE affichera toujours le message renvoyé à onbeforeunloadmoins que le onbeforeunloadgestionnaire ne soit supprimé au préalable. Voir aussi Demander confirmation lors de la fermeture d'un onglet .

  • <script>différences d'événement de balise: onsuccess et onerrorne sont pas pris en charge dans IE et sont remplacés par un IE spécifique onreadystatechangequi est déclenché, que le téléchargement ait réussi ou échoué. Voir aussi JavaScript Madness pour plus d'informations.


Taille / position / défilement des éléments et position de la souris:

  • Obtenir la taille / la position de l'élément : la largeur / la hauteur des éléments est parfois elm.style.pixelHeight/Widthdans IE plutôt queelm.offsetHeight/Width , mais ni l'un ni l'autre n'est fiable dans IE, en particulier en mode bizarreries, et parfois l'un donne un meilleur résultat que l'autre.

    elm.offsetTopet elm.offsetLeftsont souvent signalés de manière incorrecte, ce qui conduit à trouver des positions d'éléments incorrectes, c'est pourquoi les éléments contextuels, etc., sont à quelques pixels dans de nombreux cas.

    Notez également que si un élément (ou un parent de l'élément) a un displayde, nonealors IE lèvera une exception lors de l'accès aux attributs de taille / position plutôt que de retourner 0comme le fait Firefox.

  • Obtenez la taille de l'écran (Obtention de la zone visible de l'écran):

    • Firefox: window.innerWidth/innerHeight
    • Mode normes IE: document.documentElement.clientWidth/clientHeight
    • Mode bizarreries IE: document.body.clientWidth/clientHeight

  • Position de défilement du document / position de la souris : celle-ci n'est en fait pas définie par le w3c et n'est donc pas standard même dans Firefox. Pour trouver le scrollLeft/ scrollTopdu document:

    • Firefox et IE en mode bizarre: document.body.scrollLeft/scrollTop
    • IE en mode standard: document.documentElement.scrollLeft/scrollTop
    • REMARQUE: certains autres navigateurs utilisent également 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];
      };

    Afin d'obtenir la position du curseur de la souris, evt.clientXet evt.clientYdans les mousemoveévénements donnera la position relative au document sans ajouter la position de défilement donc la fonction précédente devra être incorporée:

    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]];
     };
    };

Sélections / plages:

  • <textarea>et <input>sélections : selectionStartet selectionEndne sont pas implémentés dans IE, et il y a un système propriétaire de "gammes" à sa place, voir aussi Position du curseur dans textarea, en caractères dès le début .

  • Obtenir le texte actuellement sélectionné dans le document:

    • Firefox: window.getSelection().toString()
    • C'EST À DIRE: document.selection.createRange().text


Obtenir des éléments par ID:

  • document.getElementByIdpeut également faire référence à l' nameattribut dans les formulaires (en fonction de celui qui est défini en premier dans le document), il est donc préférable de ne pas avoir différents éléments qui ont le même nameet id. Cela remonte à l'époque où ce idn'était pas un standard du W3C. document.all( une propriété propre à IE ) est nettement plus rapide que document.getElementById, mais elle présente d'autres problèmes car elle priorise toujours nameavant id. J'utilise personnellement ce code, en retombant avec des vérifications supplémentaires juste pour être sûr:

    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;
     };
    };

Problèmes avec la lecture seule innerHTML:

  • IE ne prend pas en charge le réglage de la innerHTML de col, colGroup, frameSet, html, head, style, table, tBody, tFoot, tHead, title, et les tréléments. Voici une fonction qui fonctionne autour de cela pour les éléments liés aux tables:

    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;
      };
     };
    };

    Notez également que IE nécessite l'ajout de a <tbody>à a <table>avant d'ajouter <tr>s à cet <tbody>élément lors de la création en utilisant document.createElement, par exemple:

    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

Différences d'événements:

  • Obtention de la eventvariable: les événements DOM ne sont pas passés aux fonctions dans IE et sont accessibles en tant que window.event. Une manière courante d'obtenir l'événement est d'utiliser par exemple la valeur par
    elm.onmouseover = function(evt) {evt = evt||window.event}
    défaut window.eventif evtn'est pas définie.

  • Différences entre les codes d'événements clés : les codes d'événements clés varient énormément, bien que si vous regardez Quirksmode ou JavaScript Madness , ce n'est guère spécifique à IE, Safari et Opera sont à nouveau différents.

  • Différences d'événements de souris: l' buttonattribut dans IE est un bit-flag qui autorise plusieurs boutons de souris à la fois:

    • Gauche: 1 ( var isLeft = evt.button & 1)
    • Droite: 2 ( var isRight = evt.button & 2)
    • Centre: 4 ( var isCenter = evt.button & 4)

      Le modèle W3C (pris en charge par Firefox) est moins flexible que le modèle IE, avec un seul bouton autorisé à la fois avec la gauche comme 0, la droite comme 2et le centre comme 1. Notez que, comme le mentionne Peter-Paul Koch , cela est très contre-intuitif, car cela 0signifie généralement «pas de bouton».

      offsetXet offsetYsont problématiques et il est probablement préférable de les éviter dans IE. Un moyen plus fiable d'obtenir le offsetXet offsetYdans IE serait d' obtenir la position de l'élément relativement positionné et de le soustraire de clientXet clientY.

      Notez également que dans IE, pour obtenir un double-clic dans un clickévénement, vous devez enregistrer à la fois un événement clicket dblclickune fonction. Firefox se déclenche clickainsi que dblclicklors d'un double-clic, donc une détection spécifique à IE est nécessaire pour avoir le même comportement.

  • Les différences dans le modèle de gestion des événements: Tant le modèle IE propriétaire et le traitement de soutien du modèle Firefox des événements dès le départ en bas, par exemple , s'il y a des événements dans les deux éléments <div><span></span></div>puis événements déclenchent en span alors le divlieu de l'ordre qu'ils sont lié si un exemple traditionnel a elm.onclick = function(evt) {}été utilisé.

    Les événements "Capture" ne sont généralement pris en charge que dans Firefox, etc., ce qui déclenchera divensuite les spanévénements dans un ordre descendant. IE a elm.setCapture()et elm.releaseCapture()pour rediriger les événements de souris du document vers l'élément ( elmdans ce cas) avant de traiter d'autres événements, mais ils ont un certain nombre de problèmes de performances et d'autres donc devraient probablement être évités.

    • Firefox:

      Attach : elm.addEventListener(type, listener, useCapture [true/false])
      Detach : elm.removeEventListener(type, listener, useCapture)
      ( typeest par exemple 'mouseover'sans le on)

    • IE: Un seul événement d'un type donné sur un élément peut être ajouté dans IE - une exception est déclenchée si plus d'un événement du même type est ajouté. Notez également que le thisfait référence à windowplutôt qu'à l'élément lié dans les fonctions d'événement (c'est donc moins utile):

      Joindre : elm.attachEvent(sEvent, fpNotify)
      Détacher : elm.detachEvent(sEvent, fpNotify)
      ( sEventest par exemple 'onmouseover')

  • Différences d'attributs d'événement:

    • Arrêtez le traitement des événements par toute autre fonction d'écoute :

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

    • Arrêtez, par exemple, les événements clés d'insérer des caractères ou d'empêcher les cases à cocher d'être cochées:

      Firefox: evt.preventDefault()
      IE: evt.returnValue = false
      Note: Je viens de revenir falseen keydown, keypress, mousedown, mouseup, clicket resetempêchera également défaut.

    • Récupérez l'élément qui a déclenché l'événement:

      Firefox: evt.target
      IE: evt.srcElement

    • Obtention de l'élément dont le curseur de la souris s'est éloigné: evt.fromElement dans IE se trouve evt.targetdans Firefox si dans un onmouseoutévénement, sinonevt.relatedTarget

    • Obtention de l'élément vers lequel le curseur de la souris a été déplacé: evt.toElement dans IE est evt.relatedTargetdans Firefox si dans un onmouseoutévénement, sinonevt.target

    • Remarque: evt.currentTarget (l'élément auquel l'événement était lié) n'a pas d'équivalent dans IE.

cryo
la source
12
Très, très, très belle liste! Merci à tous ceux qui ont contribué :)
cwap
26

Vérifiez également les virgules telles que celles-ci ou similaires le cas échéant dans votre code

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

la dernière virgule (valeur suivante2) sera tolérée par Firefox, mais pas IE

Luca Rocchi
la source
1
La plupart des bons éditeurs devraient attraper celui-ci
SeanJA
1
+1, j'ai eu celui-ci trop souvent.
David V.
1
Je vous donnerais +10 si je pouvais - cela m'arrive tout le temps.
Josh
Oh et pour ajouter au commentaire de @ SeanJA: je suis récemment passé à NetBeans qui saisit cela.
Josh
J'ai perdu tellement d'heures là-dessus la première fois que j'ai fait du travail sur JS. C'est maintenant la première chose que je vérifie! Curse les extensions de Textmate merdiques en laissant des virgules.
Agos
12

Si vous vous en tenez à utiliser jQuery ou YUI lorsque votre message est balisé, vous devriez avoir des différences minimes entre les navigateurs ... c'est à cela que servent les frameworks, pour prendre en charge ces différences entre navigateurs pour vous.

Pour un exemple, regardez la page de traversée du DOM quirksmode , selon elle, IE ne prend pas en charge la plupart des choses ... alors que c'est vrai, les frameworks le font, par exemple IE ne prend pas en charge elem.childElementCount, mais dans jQuery:$(elem).children().size() fonctionne pour obtenir cette valeur, dans chaque navigateur. Vous constaterez qu'il y a quelque chose dans la bibliothèque pour gérer 99% des cas non pris en charge dans les navigateurs, au moins avec un script ... avec CSS, vous devrez peut-être passer aux plugins pour la bibliothèque, un exemple courant est d'obtenir des coins arrondis travaillant dans IE ... car il n'a pas de support CSS pour un tel.

Si toutefois vous commencez à faire des choses directement, comme document.XXX(thing), alors vous n'êtes pas dans la bibliothèque, vous faites du javascript directement (tout est javascript, mais vous comprenez :), et cela peut ou non causer des problèmes, selon la façon dont ivre l'équipe IE était lors de la mise en œuvre de cette fonction particulière.

Avec IE, vous êtes plus susceptible d'échouer en termes de style que les problèmes javascript bruts, les animations à quelques pixels de distance et ce genre de choses, bien plus encore dans IE6 bien sûr.

Nick Craver
la source
Je comprends mieux maintenant. Oui, j'ai aussi fait de telles choses directement. karlthorwald
user89021
1
Si vous utilisez un IDE comme Netbeans, vous pouvez définir les navigateurs cibles pour votre javascript et cela vous aidera également en vous avertissant lorsque vous faites quelque chose qui ne semble pas être pris en charge.
SeanJA
10

getElementbyID correspondra également à l'attribut name dans IE, mais pas aux autres navigateurs, et IE sélectionnera celui qu'il trouve en premier.

exemple:

<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
la source
3
désolé d'être impoli mais IE est vraiment moche
user89021
12
document.getElementByIdOrNameIGuessWhateverMan (id);
JulianR
5

Il y a beaucoup de choses, mais un piège dans lequel je tombais était que de nombreux navigateurs acceptaient JSON sans les noms entre guillemets, contrairement à ie6 et ie7.

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

Edit : Pour clarifier, ce n'est un problème que lorsque JSON réel est requis, par opposition à un littéral d'objet. JSON est un sous-ensemble de la syntaxe littérale d'objet et est conçu comme un format d'échange de données (comme XML), c'est pourquoi il est conçu pour être plus sélectif.

Jakob
la source
2
Notez que cela dépend du contexte, un littéral d'objet convient, JSON ne l'est pas ... mais par exemple jQuery n'autorise pas du tout JSON invalide dans sa dernière version.
Nick Craver
Ce n'est pas mon vote négatif ... mais vous devriez clarifier cela pour les autres, puis +1 de ma part.
Nick Craver
5

Prise en charge différente de JavaScript

IE ne prend pas en charge (la plupart) les extensions ajoutées à JavaScript depuis la version 1.5.

Nouveau dans la 1.6

  • Méthodes Array - indexOf(), lastIndexOf(), every(), filter(), forEach(), map(),some()
  • for each ... in - itère les valeurs au lieu des noms de propriété.

Nouveau dans la 1.7

Nouveau dans la 1.8

  • Méthodes de tableau - reduce(),reduceRight()
  • Raccourcis pour définir les fonctions.

Certaines de ces choses vous obligent à spécifier un numéro de version de JavaScript sous lequel s'exécuter (qui se cassera sous IE), mais certaines choses comme [1,2,3].indexOf(2)peuvent ne pas sembler si importantes, jusqu'à ce que vous essayiez de l'exécuter dans IE

gnarf
la source
1
le JavaScript dont vous parlez ici est le JavaScript (TM) de mozilla, et non le javascript au sens plus générique. Toutes les implémentations / moteurs javascript d'ECMAScript (MS JScript dans ce cas) ne devraient pas suivre le JavaScript (TM) de Mozilla. ECMAScript est la norme, pas JavaScript (TM), et JavaScript (TM) n'est pas javascript. J'espère que cela a du sens.
Dagg Nabbit
Cela a du sens pour moi, mais sur un fil de discussion sur la compatibilité entre JavaScript et JScript, je me suis dit que ce serait déjà compris :)
gnarf
Quand vous dites "IE ne prend pas en charge (la plupart des) extensions ajoutées à JavaScript depuis la version 1.5.", Il semble que vous disiez que JavaScript (TM) de Mozilla est une norme à laquelle IE devrait adhérer, alors que ce n'est bien sûr pas le cas. Vous pourriez au moins dire le JavaScript de Mozilla ou similaire ... d'autres navigateurs ne prennent pas en charge toutes les extensions de Mozilla à ECMAScript comme l'affectation de déstructuration, etc. La question portait sur les différences entre 'la plupart' javascriptet (l'implémentation spécifique) JScript, pas les différences entre Mozilla JavaScript(TM)et JScript. Il serait peut-être préférable de montrer où IE s'écarte d'ES.
Dagg Nabbit
3

Les différences majeures entre JavaScript dans IE et JavaScript dans les navigateurs modernes (ex, Firefox) peuvent être attribuées aux mêmes raisons derrière les différences dans les navigateurs croisés CSS / (X) HTML. À l'époque, il n'y avait pas de norme de facto; IE / Netscape / Opera ont mené une guerre de territoire, implémentant la plupart des spécifications, mais également en omettant certaines et en créant des spécifications propriétaires pour gagner des avantages les uns sur les autres. Je pourrais continuer longtemps, mais passons à la sortie d'IE8: JavaScript a été évité / méprisé pendant des années, et avec la montée en puissance de FF et le mépris de webcomm, IE a choisi de se concentrer principalement sur l'avancement de leur CSS à partir d'IE6. Et essentiellement laissé le support DOM derrière. Le support DOM d'IE8 pourrait tout aussi bien être celui d'IE6, qui a été déployé en 2001 ... donc le support DOM d'IE8 a presque dix ans de retard sur les navigateurs modernes. Si vous rencontrez des divergences JavaScript spécifiques à un moteur de mise en page, le mieux est de l'attaquer de la même manière que nous avons résolu les problèmes CSS; Cibler ce navigateur. N'UTILISEZ PAS LE BROWSER SNIFFING, utilisez la détection des fonctionnalités pour détecter votre navigateur / son niveau de support DOM.

JScript n'est pas la propre implémentation d'ECMAScript par IE; JScript était la réponse d'IE au JavaScript de Netscape, tous deux nés avant ECMAScript.

En ce qui concerne les attributs de type sur l'élément de script, type = "text / javascript" est la norme par défaut (au moins en HTML5), vous n'avez donc jamais besoin d'un attribut de type à moins que votre script ne soit pas JavaScript.

En ce qui concerne IE ne supportant pas innerHTML ... innerHTML a été inventé par IE et n'est pas encore aujourd'hui un standard DOM. D'autres navigateurs l'ont adopté car il est utile, c'est pourquoi vous pouvez l'utiliser sur plusieurs navigateurs. En changeant dynamiquement jusqu'à tableaux, MSDN dit « en raison de la structure spécifique requise par les tables, les innerText et innerHTML propriétés des objets de table et tr sont en lecture seule. » Je ne sais pas à quel point c'était vrai au départ, mais il est clair que les navigateurs modernes l'ont compris tout en faisant face aux complexités de la mise en page des tableaux.

Je recommande vivement de lire PPK sur JavaScript Scripting DOM de Jeremy Keith JavaScript: The Good Parts de Douglas Crockford et Beginning JavaScript with DOM Scripting and Ajax de Christian Hellman pour bien comprendre JavaScript.

En ce qui concerne les cadres / bibliothèques, si vous ne maîtrisez pas encore très bien JavaScript, vous devez les éviter. Il y a 2 ans, je suis tombé dans le piège de jQuery, et bien que j'aie pu réaliser de magnifiques exploits, je n'ai jamais rien appris sur le codage correct de JavaScript. Avec le recul, jQuery est une boîte à outils DOM géniale, mais mon échec à apprendre les fermetures appropriées, l'héritage prototypique, etc.

JavaScript est la langue du navigateur; si vous êtes ingénieur côté client / front-end, il est de la plus haute importance que vous commandiez JavaScript. Node.js apporte la pleine inclinaison de JavaScript, je vois d'immenses progrès réalisés quotidiennement dans son développement; Le JavaScript côté serveur deviendra une norme dans un très proche avenir. Je mentionne cela pour souligner davantage à quel point JavaScript est et sera important.

JavaScript va faire plus de vagues que Rails.

Joyeux script!

Albert
la source
2
Bonne réponse, même si je ne suis pas d'accord avec l'utilisation de la détection de fonctionnalités pour flairer le navigateur; utilisez uniquement la détection des fonctionnalités pour tester la prise en charge de ces fonctionnalités. Voir également les exemples dans La détection de fonctionnalités n'est pas la détection de navigateur .
Marcel Korpel
meh. Je suis entièrement d'accord avec votre désaccord. merci d'avoir attrapé ça. je suis toujours un JavaScript n00b, mais il n'y a pas de honte dans mon jeu. "La détection de navigateur basée sur les fonctionnalités est une très mauvaise pratique qui doit être évitée à tout prix. La détection simple des fonctionnalités est une bonne pratique et, dans presque tous les cas, c'est exactement ce dont vous aurez besoin."
albert
2

Certains objets natifs sont en lecture seule sans en avoir vraiment l'air (vous pouvez y écrire mais cela n'a aucun effet). Par exemple, un javascript avancé commun est basé sur l'extension de l' Elementobjet en remplaçant les méthodes système, par exemple, en modifiant Element.prototype.appendChild () pour faire plus que l'ajout d'un nœud enfant - disons, l'initialiser avec les données du parent. Cela échouera silencieusement sur IE6 - la méthode d'origine sera appelée sur les nouveaux objets au lieu du nouveau.

Certains navigateurs (je ne me souviens plus lequel maintenant) considèrent les nouvelles lignes entre les balises HTML comme des nœuds de texte, tandis que d'autres ne le font pas. Ainsi, childNodes (n), nextSibling (), firstChild () et autres se comporteront très différemment.

SF.
la source
2

Les virgules de fin dans les tableaux et les littéraux d'objet étaient un problème, n'ont pas été vérifiées récemment (ce qui signifie IE8):

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

Cela entraînerait du code supplémentaire lors de la génération de telles structures côté serveur.

npup
la source
2

Je viens d'en trouver un ce matin, un collègue a défini la balise de script comme suit: <script type="application/javascript">parce que son ide autocomplete avait cela avant "text / javascript"

Mais, il s'avère que IE ignore tout le script si vous utilisez "application / javascript", vous devez utiliser "text / javascript"

Katjones
la source
javascript est par défaut dans tous les navigateurs, alors utilisez juste<script>
Lauri
2

J'ai trouvé une bizarrerie l'autre jour avec Internet Explorer. J'utilisais YUI et remplaçais le contenu d'un corps de table () en définissant le innerHTML

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

Cela fonctionnerait dans tous les navigateurs SAUF IE. J'ai finalement découvert que vous ne pouviez pas remplacer le innerHTML d'une table dans IE. J'ai dû créer un nœud en utilisant YUI, puis ajouter ce nœud.

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

C'était amusant à comprendre!

Justin
la source
1
J'ai le sentiment que vous devez l'envelopper avec des <tbody>étiquettes.
Casey Chu
Dans le code d'origine, il est en fait enveloppé dans une balise <tbody>. Cela me souffle encore que IE n'aime pas ça. Je me souviens de l'avoir lu dans la documentation officielle de Microsoft, mais je ne trouve pas le lien maintenant. Désolé!
Justin
1

Les virgules supplémentaires et les virgules manquantes étaient un problème habituel sur IE alors que cela fonctionne correctement sur FF.

Profond
la source
1

IE est très stricte sur le fait de manquer ";" il en est généralement de même.

Sam3k
la source
J'en trouve beaucoup pendant que je suis jsLinting maintenant. Semble être un point important.
user89021
1

Pour ce que ça vaut, je viens de tomber sur ce problème désagréable dans <IE9

disons que vous avez du code HTML comme celui-ci:

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

et pour une raison quelconque (j'en ai eu une bonne), vous devez récupérer tout le HTML du tableau avant le dernier TR de fermeture, vous pouvez essayer quelque chose comme ceci:

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

<IE9 ne renvoie rien (-1) ici car la variable tableHtml contient toutes les balises html en majuscules et lastIndexOf est sensible à la casse. Pour contourner cela, j'ai dû lancer un toLowerCase () avant lastIndexOf.

tomfumb
la source
0

IE n'est pas un navigateur moderne et ne suit ECMAScript que vaguement.

Rob
la source
0

Vous avez mentionné jQuery avec lequel je suis moins familier, mais pour référence générale, et en particulier avec Prototype, une chose à surveiller est les mots / noms de méthodes réservés dans IE. Je sais ce qui m'attire souvent, ce sont des choses comme:

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

(new Element (tagName, propertyHash) est la façon dont les nouveaux éléments sont créés dans Protitype). Dans IE, for:doit être 'for':, carfor est un mot réservé. Ce qui est tout à fait logique - mais FireFox le tolérera.

Un autre exemple:

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

(la wrapméthode de Prototype enveloppe un élément dans un autre) - Dans IE, sur textareas, wrapest une propriété, etElement.wrap() doit être utilisée à la place de la version méthodisée

Ce sont deux exemples qui me viennent à l'esprit de mon expérience. Ils sont basés sur un prototype, mais le problème principal n'est pas: faites attention aux méthodes / étiquettes / identificateurs que IE considère comme des mots réservés mais que FireFox ou Safari les toléreront.

Josh
la source
0

Le fait est que IE ne prend pas en charge JavaScript ... Il prend en charge sa propre implémentation d'ECMAScript: JScript ... ce qui est un peu différent ...

xavierm02
la source
0

En utilisant console.log() pour afficher les erreurs sur la console d'erreur Firefox entraînera l'échec de vos scripts dans IE. N'oubliez pas de les retirer lorsque vous testez dans IE.

Erikk Ross
la source
Je pense que l'utilisation de console.log échouera également même dans Firefox si FireBug n'est pas activé.
ejel