Was sind die typischen Gründe, warum in Firefox entwickeltes Javascript im IE fehlschlägt? [geschlossen]


108

Ich habe einige mit Javascript erweiterte Seiten entwickelt, die in den letzten Versionen von Firefox und Safari einwandfrei funktionieren. Ich habe es versäumt, in Internet Explorer einzuchecken, und jetzt finde ich, dass die Seiten in IE 6 und 7 (bisher) nicht funktionieren. Die Skripte werden irgendwie nicht ausgeführt, die Seiten zeigen, als ob Javascript nicht vorhanden wäre, obwohl etwas Javascript ausgeführt wird. Ich verwende eigene Bibliotheken mit Dom-Manipulation, von YUI 2 aus verwende ich YUI-Loader und XML-Http-Request und auf einer Seite verwende ich "psupload", was von JQuery abhängt.

Ich installiere Microsoft Script Editor von Office XP und werde jetzt debuggen. Ich werde jetzt auch spezifische Tests schreiben.

Was sind die typischen Fehlerquellen des IE? In welche Richtung kann ich meine Augen offen halten?

Ich habe diese Seite gefunden, die einige Unterschiede zeigt. Besuch: Quirksmode

Können Sie aus Ihrer Erfahrung einige typische Dinge nennen, nach denen ich zuerst suchen sollte?

Ich werde hier später auch weitere Fragen zu bestimmten Aufgaben stellen, aber im Moment interessiert mich Ihre Erfahrung, warum der IE normalerweise bei Skripten fehlschlägt, die in Firefox einwandfrei funktionieren

Edit: Danke für all die tollen Antworten!

In der Zwischenzeit habe ich den gesamten Code so angepasst, dass er auch mit Internet Explorer funktioniert. Ich habe jQuery integriert und jetzt meine eigenen Klassen darauf aufgebaut. Dies war mein grundlegender Fehler, dass ich nicht von Anfang an alle meine Sachen auf jQuery aufgebaut habe. Jetzt habe ich.

Auch JSLint hat mir sehr geholfen.

Und viele der einzelnen Probleme aus den verschiedenen Antworten haben geholfen.


Bisher gibt es keine Probleme mit CSS oder Styling, da ich das aus früheren Codierungen wusste. Nur JS Probleme - karlthorwald
user89021

1
Ich werde JSLint jetzt zuerst für alle Dateien ausführen, es gibt einige, die ich nie angepasst habe.
user89021

7
"Dies war mein grundlegender Fehler, dass ich nicht von Anfang an alle meine Sachen auf jQuery aufgebaut habe." - Es wird nicht alle Ihre browserübergreifenden Probleme auf magische Weise lösen. Durchsuchen Sie den Stackoverflow nach jQuery und IE. Sie werden unzählige Probleme finden. Am besten lernen Sie Cross-Browser-Scripting selbst. Wenn jQuery oder eines seiner Milliarden skizzenhaften Plugins ausfällt, können Sie eine wirklich funktionierende Cross-Browser-Lösung implementieren und wissen, dass sie funktioniert und warum.
Dagg Nabbit

11
+1 Zu Nein's Kommentar oben. Sie sind weitaus besser dran, jQuery vollständig zu vermeiden, wenn Sie Javascript lernen - jQuery ist unglaublich nützlich, wenn Sie etwas Komplexes schnell und einfach erledigen möchten, aber wenn Sie lernen, schützt es Sie vor der Komplexität des Verständnisses, wie Javascript tatsächlich funktioniert funktioniert - viel zu viele Leute scheinen jQuery zu kennen, haben aber keine Ahnung, wie man Javascript schreibt. Sie haben keinen Fehler gemacht, der ursprünglich nicht auf jQuery aufgebaut hat - Sie haben jetzt ein weitaus besseres Verständnis für Ihren eigenen Code als wenn Sie dies getan hätten.
Lucideer

Antworten:


121

Bitte zögern Sie nicht, diese Liste zu aktualisieren, wenn Sie Fehler / Auslassungen usw. sehen.

Hinweis: IE9 behebt viele der folgenden Probleme, sodass ein Großteil davon nur für IE8 und darunter und bis zu einem gewissen Grad für IE9 im Mackenmodus gilt. Zum Beispiel unterstützt IE9 SVG, <canvas>, <audio>und <video>nativ, aber Sie müssen die Einhaltung von Standards - Modus aktivieren für sie zur Verfügung stehen.


Allgemeines:

  • Probleme mit teilweise geladenen Dokumenten: Es ist eine gute Idee, Ihr JavaScript in einem window.onloadoder einem ähnlichen Ereignis hinzuzufügen, da der IE nicht viele Vorgänge in teilweise geladenen Dokumenten unterstützt.

  • Unterschiedliche Attribute : In CSS ist es elm.style.styleFloatin IE vs elm.style.cssFloatin Firefox. In <label>Tags wird mit dem forAttribut elm.htmlForin IE vs elm.forin Firefox zugegriffen . Beachten Sie, dass dies forim IE reserviert ist. Daher elm['for']ist es wahrscheinlich besser, den IE daran zu hindern, eine Ausnahme auszulösen.


Basis-JavaScript-Sprache:

  • Zugriff auf Zeichen in Zeichenfolgen : 'string'[0]Wird im IE nicht unterstützt, da dies nicht in den ursprünglichen JavaScript-Spezifikationen enthalten ist. Verwenden 'string'.charAt(0)oder 'string'.split('')[0]beachten Sie, dass der Zugriff auf Elemente in Arrays erheblich schneller ist als die Verwendung charAtmit Zeichenfolgen im IE (obwohl beim splitersten Aufruf ein gewisser Overhead anfällt ).

  • Kommas vor dem Ende von Objekten: zB {'foo': 'bar',}sind im IE nicht erlaubt.


Elementspezifische Probleme:

  • Erhalten documenteines IFrames :

    • Firefox und IE8 +: IFrame.contentDocument (IE unterstützt dies ab Version 8. )
    • IE: IFrame.contentWindow.document
    • ( IFrame.contentWindowbezieht sich auf die windowin beiden Browsern.)

  • Canvas: Versionen von IE vor IE9 unterstützen das <canvas>Element nicht. IE unterstützt jedoch VML , eine ähnliche Technologie, und explorercanvas kann einen direkten Wrapper für <canvas>Elemente für viele Vorgänge bereitstellen . Beachten Sie, dass IE8 im Standardkonformitätsmodus um ein Vielfaches langsamer ist und viel mehr Störungen aufweist als im Mackenmodus bei Verwendung von VML.

  • SVG: IE9 unterstützt SVG nativ. IE6-8 kann SVG unterstützen, jedoch nur mit externen Plugins, wobei nur einige dieser Plugins die JavaScript-Manipulation unterstützen.

  • <audio>und <video>: werden nur in IE9 unterstützt.

  • Dynamisches Erstellen von Optionsfeldern: IE <8 hat einen Fehler, der das Erstellen von Optionsfeldern mit document.createElementdeaktivierbar macht. Siehe auch Wie erstellen Sie dynamisch ein Optionsfeld in Javascript, das in allen Browsern funktioniert? für einen Weg, dies zu umgehen.

  • Eingebettetes JavaScript in <a href>Tags und onbeforeunloadKonflikte im IE: Wenn im hrefTeil eines aTags eingebettetes JavaScript vorhanden ist (z. B. <a href="javascript: doStuff()">zeigt der IE immer die zurückgegebene Nachricht an, es onbeforeunloadsei denn, der onbeforeunloadHandler wurde zuvor entfernt. Siehe auch Bestätigen beim Schließen eines Tabs .

  • <script>Tag-Ereignisunterschiede: onsuccess und onerrorwerden im IE nicht unterstützt und durch einen IE-spezifischen ersetzt, onreadystatechangeder ausgelöst wird, unabhängig davon, ob der Download erfolgreich war oder fehlgeschlagen ist. Siehe auch JavaScript Madness für weitere Informationen.


Elementgröße / Position / Scrollen und Mausposition:

  • Abrufen der Elementgröße / -position : Breite / Höhe der Elemente erfolgt manchmal elm.style.pixelHeight/Widtheher im IE als elm.offsetHeight/Width, aber keines ist im IE zuverlässig, insbesondere im Mackenmodus, und manchmal liefert eines ein besseres Ergebnis als das andere.

    elm.offsetTopund elm.offsetLeftwerden oft falsch gemeldet, was dazu führt, dass Positionen von Elementen falsch sind, weshalb Popup-Elemente usw. in vielen Fällen einige Pixel entfernt sind.

    Beachten Sie auch, dass displayder noneIE beim Zugriff auf Größen- / Positionsattribute eine Ausnahme auslöst , wenn ein Element (oder ein übergeordnetes Element des Elements) einen von hat , anstatt 0wie bei Firefox zurückzukehren.

  • Abrufen der Bildschirmgröße (Abrufen des sichtbaren Bereichs des Bildschirms):

    • Feuerfuchs: window.innerWidth/innerHeight
    • IE-Standardmodus: document.documentElement.clientWidth/clientHeight
    • IE-Mackenmodus: document.body.clientWidth/clientHeight

  • Dokument- Bildlaufposition / Mausposition: Diese Position wird vom w3c nicht definiert und ist daher selbst in Firefox nicht standardisiert. So finden Sie das scrollLeft/ scrollTopdes document:

    • Firefox und IE im Mackenmodus: document.body.scrollLeft/scrollTop
    • IE im Standardmodus: document.documentElement.scrollLeft/scrollTop
    • HINWEIS: Einige andere Browser verwenden pageXOffset/ pageYOffsetebenfalls.

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

    Um die Position des Mauszeigers zu ermitteln evt.clientXund evt.clientYin mousemoveEreignissen die Position relativ zum Dokument anzugeben, ohne die Bildlaufposition hinzuzufügen , muss die vorherige Funktion integriert werden:

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

Auswahl / Bereiche:

  • <textarea>und <input>Auswahlen : selectionStartund selectionEndsind nicht im IE implementiert, und es gibt ein proprietäres "Bereichs" -System an seiner Stelle, siehe auch Caret-Position im Textbereich, in Zeichen von Anfang an .

  • Abrufen des aktuell ausgewählten Texts im Dokument:

    • Feuerfuchs: window.getSelection().toString()
    • IE: document.selection.createRange().text


Elemente nach ID abrufen:

  • document.getElementByIdkann auch auf das nameAttribut in Formularen verweisen (abhängig davon, welches zuerst im Dokument definiert wird), daher ist es am besten, keine unterschiedlichen Elemente mit demselben nameund zu haben id. Dies geht auf die Tage zurück, als ides noch kein W3C-Standard war. document.all( eine proprietäre IE-spezifische Eigenschaft ) ist erheblich schneller als document.getElementById, hat jedoch andere Probleme, da immer namezuvor Prioritäten gesetzt werden id. Ich persönlich verwende diesen Code und greife mit zusätzlichen Überprüfungen zurück, um sicherzugehen:

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

Probleme mit schreibgeschütztem innerHTML:

  • IE nicht unterstützt nicht den Innerhtml der Einstellung col, colGroup, frameSet, html, head, style, table, tBody, tFoot, tHead, title, und trElemente. Hier ist eine Funktion, die dies für tabellenbezogene Elemente umgeht:

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

    Beachten Sie auch, dass der IE das Hinzufügen eines <tbody>zu einem erforderlich macht , <table>bevor <tr>s an dieses <tbody>Element angehängt wird , wenn Folgendes erstellt document.createElementwird: Beispiel:

    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

Ereignisunterschiede:

  • Abrufen der eventVariablen: DOM-Ereignisse werden nicht an Funktionen im IE übergeben und sind als zugänglich window.event. Eine übliche Methode, um das Ereignis
    elm.onmouseover = function(evt) {evt = evt||window.event}
    abzurufen, besteht darin, z. B. die Standardeinstellung zu verwenden, window.eventwenn evtundefiniert ist.

  • Wichtige Unterschiede im Ereigniscode: Die wichtigsten Ereigniscodes variieren stark. Wenn Sie sich jedoch Quirksmode oder JavaScript Madness ansehen , unterscheiden sich IE, Safari und Opera kaum wieder.

  • buttonMausereignisunterschiede : Das Attribut im IE ist ein Bit-Flag, das mehrere Maustasten gleichzeitig zulässt:

    • Links: 1 ( var isLeft = evt.button & 1)
    • Rechts: 2 ( var isRight = evt.button & 2)
    • Mitte: 4 ( var isCenter = evt.button & 4)

      Das W3C-Modell (von Firefox unterstützt) ist weniger flexibel als das IE-Modell, da nur eine einzige Taste gleichzeitig mit links als 0, rechts als 2und Mitte als zulässig ist 1. Beachten Sie, dass dies, wie Peter-Paul Koch erwähnt , sehr kontraintuitiv ist, da dies 0normalerweise "kein Knopf" bedeutet.

      offsetXund offsetYsind problematisch und es ist wahrscheinlich am besten, sie im IE zu vermeiden. Ein zuverlässigerer Weg, um das offsetXund offsetYim IE zu erhalten, wäre , die Position des relativ positionierten Elements zu erhalten und es von clientXund zu subtrahieren clientY.

      Beachten Sie außerdem, dass Sie im IE, um einen Doppelklick auf ein clickEreignis zu erhalten, sowohl ein clickals auch ein dblclickEreignis für eine Funktion registrieren müssen. Firefox wird clickebenso wie dblclickbeim Doppelklicken ausgelöst, sodass eine IE-spezifische Erkennung erforderlich ist, um dasselbe Verhalten zu erzielen.

  • Unterschiede in dem Ereignismodell Umgang: Sowohl das proprietäre IE - Modells und die Firefox - Modell Unterstützung Handhabung von Ereignissen von unten nach oben, zB bei Veranstaltungen in beiden Elementen sind <div><span></span></div>dann Ereignisse werden im auslösen span dann die divanstatt die Ordnung , die sie sind gebunden, wenn ein traditionelles zB elm.onclick = function(evt) {}verwendet wurde.

    "Capture" -Ereignisse werden im Allgemeinen nur in Firefox usw. unterstützt, wodurch divdie spanEreignisse in einer Reihenfolge von oben nach unten ausgelöst werden. IE hat elm.setCapture()und elm.releaseCapture()um Mausereignisse aus dem Dokument auf das Element umzuleiten ( elmin diesem Fall), bevor andere Ereignisse verarbeitet werden, aber sie haben eine Reihe von Leistungs- und anderen Problemen, so dass sie wahrscheinlich vermieden werden sollten.

    • Feuerfuchs:

      Anhängen : elm.addEventListener(type, listener, useCapture [true/false])
      Abnehmen : elm.removeEventListener(type, listener, useCapture)
      ( typeist zB 'mouseover'ohne on)

    • IE: Im IE kann nur ein einzelnes Ereignis eines bestimmten Typs zu einem Element hinzugefügt werden. Eine Ausnahme wird ausgelöst, wenn mehr als ein Ereignis desselben Typs hinzugefügt wird. Beachten Sie auch, dass sich das Ereignis in Ereignisfunktionen eher auf das gebundene als auf das gebundene Element thisbezieht window(daher weniger nützlich ist):

      Anhängen : elm.attachEvent(sEvent, fpNotify)
      Abnehmen : elm.detachEvent(sEvent, fpNotify)
      ( sEventist zB 'onmouseover')

  • Unterschiede bei Ereignisattributen:

    • Verhindern Sie, dass Ereignisse von anderen Abhörfunktionen verarbeitet werden :

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

    • Verhindern Sie, dass z. B. Schlüsselereignisse Zeichen einfügen oder Kontrollkästchen nicht aktiviert werden:

      Firefox: evt.preventDefault()
      IE: evt.returnValue = false
      Hinweis: Nur die Rückkehr falsein keydown, keypress, mousedown, mouseup, clickund resetwird auch Standard verhindern.

    • Holen Sie sich das Element, das das Ereignis ausgelöst hat:

      Firefox: evt.target
      IE: evt.srcElement

    • Abrufen des Elements, von dem der Mauszeiger wegbewegt wurde: evt.fromElement Im IE befindet sich evt.targetin Firefox, wenn dies in einem onmouseoutEreignis der Fall istevt.relatedTarget

    • Abrufen des Elements, auf das sich der Mauszeiger bewegt hat: evt.toElement Im IE befindet sich evt.relatedTargetin Firefox, wenn dies in einem onmouseoutEreignis der Fall istevt.target

    • Hinweis: evt.currentTarget (das Element, an das das Ereignis gebunden war) hat im IE keine Entsprechung.


12
Sehr, sehr, sehr schöne Liste! Vielen Dank an alle, die dazu beigetragen haben :)
cwap

26

Suchen Sie auch nach Kommas wie diesen oder ähnlichen in Ihrem Code

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

Das letzte Komma (nach Wert2) wird von Firefox toleriert, nicht jedoch von IE


1
Die meisten guten Redakteure sollten diesen fangen
SeanJA

1
+1, ich hatte diesen zu oft.
David V.

1
Ich würde dir +10 geben, wenn ich könnte - das passiert mir die ganze Zeit.
Josh

Oh und um @ SeanJAs Kommentar zu ergänzen: Ich bin kürzlich zu NetBeans gewechselt, was dies auffängt.
Josh

Ich habe so viele Stunden verloren, als ich zum ersten Mal JS-Arbeit geleistet habe. Jetzt überprüfe ich als erstes! Fluch beschissene Textmate-Erweiterungen, die Kommas hinterlassen.
Agos

12

Wenn Sie sich an die Verwendung von jQuery oder YUI halten, während Ihr Beitrag markiert wird, sollten Sie nur minimale Unterschiede zwischen den Browsern aufweisen. Dafür sind die Frameworks gedacht, um diese browserübergreifenden Unterschiede für Sie zu berücksichtigen.

Schauen Sie sich zum Beispiel die DOM-Traversal-Seite im Quirksmode an. Der IE unterstützt die meisten Dinge nicht. Während dies der Fall ist, unterstützen die Frameworks beispielsweise den IE nicht elem.childElementCount, aber in jQuery: $(elem).children().size()funktioniert, um diesen Wert zu erhalten. in jedem Browser. Sie werden feststellen, dass es in der Bibliothek etwas gibt, das 99% der nicht unterstützten Fälle in verschiedenen Browsern behandelt, zumindest mit Skript. Bei CSS müssen Sie möglicherweise zu Plugins für die Bibliothek wechseln. Ein häufiges Beispiel hierfür ist das Abrunden abgerundeter Ecken Arbeiten im IE ... da es keine CSS-Unterstützung für solche hat.

Wenn Sie jedoch anfangen, Dinge direkt zu tun, wie document.XXX(thing), dann sind Sie nicht in der Bibliothek, Sie machen Javascript direkt (es ist alles Javascript, aber Sie verstehen es :), und dies kann Probleme verursachen oder auch nicht, je nachdem wie Betrunken war das IE-Team bei der Implementierung dieser speziellen Funktion.

Mit IE scheitern Sie eher daran, dass das Styling richtig herauskommt, als an rohen Javascript-Problemen, Animationen, die ein paar Pixel entfernt sind, und dergleichen, viel mehr natürlich im IE6.


Ich verstehe jetzt besser. Ja, ich habe solche Dinge auch direkt gemacht. karlthorwald
user89021

1
Wenn Sie eine IDE wie Netbeans verwenden, können Sie die Zielbrowser für Ihr Javascript festlegen. Dies hilft Ihnen auch, indem Sie gewarnt werden, wenn Sie etwas tun, das anscheinend nicht unterstützt wird.
SeanJA

10

getElementbyID stimmt auch mit dem Namensattribut im IE überein, jedoch nicht mit anderen Browsern, und der IE wählt den zuerst gefundenen aus.

Beispiel:

<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

3
Entschuldigung für die Unhöflichkeit, aber IE ist wirklich hässlich
user89021

12
document.getElementByIdOrNameIGuessWhateverMan (id);
JulianR

5

Es gibt viele Dinge, aber eine Falle, in die ich früher geraten bin, war, dass viele Browser JSON ohne Anführungszeichen akzeptieren, während ie6 und ie7 dies nicht tun.

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

Bearbeiten : Zur Verdeutlichung ist dies nur dann ein Problem, wenn tatsächlich JSON erforderlich ist, im Gegensatz zu einem Objektliteral. JSON ist eine Teilmenge der Objektliteral-Syntax und als Datenaustauschformat (wie XML) gedacht, weshalb es wählerischer gestaltet ist.


2
Beachten Sie, dass dies vom Kontext abhängt, ein Objektliteral in Ordnung ist, JSON nicht ... aber jQuery lässt beispielsweise in der neuesten Version überhaupt kein ungültiges JSON zu.
Nick Craver

Nicht meine Ablehnung ... aber Sie sollten dies für andere klarstellen, dann +1 von mir.
Nick Craver

5

Unterschiedliche JavaScript-Unterstützung

IE unterstützt (die meisten) Erweiterungen, die JavaScript seit 1.5 hinzugefügt wurden, nicht.

Neu in 1.6

  • Array - Methoden - indexOf(), lastIndexOf(), every(), filter(), forEach(), map(),some()
  • for each ... in - iteriert Werte anstelle von Eigenschaftsnamen.

Neu in 1.7

Neu in 1.8

  • Array-Methoden - reduce(),reduceRight()
  • Verknüpfungen zum Definieren von Funktionen.

Für einige dieser Dinge müssen Sie eine Versionsnummer von JavaScript angeben, unter der ausgeführt werden soll (was unter IE [1,2,3].indexOf(2)nicht funktioniert), aber für einige Dinge scheint dies keine große Sache zu sein, bis Sie versuchen, es im IE auszuführen


1
Das JavaScript, über das Sie hier sprechen, ist Mozillas JavaScript (TM), nicht Javascript im allgemeineren Sinne. Es ist nicht zu erwarten, dass alle ECMAScript-Implementierungen / Javascript-Engines (in diesem Fall MS JScript) dem JavaScript (TM) von Mozilla folgen. ECMAScript ist der Standard, nicht JavaScript (TM), und JavaScript (TM) ist kein Javascript. Ich hoffe das hat Sinn gemacht.
Dagg Nabbit

Macht für mich Sinn, aber in einem Thread über die Kompatibilität zwischen JavaScript und JScript dachte ich, dass das schon verstanden werden würde :)
Gnarf

Wenn Sie sagen "IE unterstützt (die meisten) die seit 1.5 zu JavaScript hinzugefügten Erweiterungen nicht.", Klingt es so, als würden Sie sagen, Mozillas JavaScript (TM) ist ein Standard, den der IE einhalten sollte, wenn dies natürlich nicht der Fall ist. Man könnte zumindest sagen, dass Mozillas JavaScript oder ähnliches ... andere Browser unterstützen nicht alle Erweiterungen von Mozilla für ECMAScript wie Destrukturierungszuweisungen usw. Die Frage betraf Unterschiede zwischen 'most' javascriptund (der spezifischen Implementierung) JScript, nicht Unterschiede zwischen Mozilla JavaScript(TM)und JScript. Es ist möglicherweise besser zu zeigen, wo der IE von ES abweicht.
Dagg Nabbit

3

Die Hauptunterschiede zwischen JavaScript im IE und JavaScript in modernen Browsern (z. B. Firefox) können auf dieselben Gründe für die Unterschiede im CSS / (X) HTML-Cross-Browser zurückgeführt werden. Früher gab es keinen De-facto-Standard; IE / Netscape / Opera führten einen Rasenkrieg, bei dem die meisten Spezifikationen implementiert, aber auch einige weggelassen und proprietäre Spezifikationen erstellt wurden, um Vorteile gegenüber einander zu erzielen. Ich könnte ausführlich weitermachen, aber lassen Sie uns mit der Veröffentlichung von IE8 fortfahren: JavaScript wurde jahrelang vermieden / verachtet, und mit dem Aufkommen von FF und der Verachtung von Webcomm konzentrierte sich IE hauptsächlich darauf, sein CSS von IE6 an weiterzuentwickeln. Und im Grunde DOM-Unterstützung hinter sich gelassen. Die DOM-Unterstützung von IE8 könnte genauso gut die von IE6 sein, die 2001 eingeführt wurde. Die DOM-Unterstützung von IE liegt also fast ein Jahrzehnt hinter modernen Browsern. Wenn Sie JavaScript-Diskrepanzen haben, die für eine Layout-Engine spezifisch sind, sollten Sie sie am besten genauso angreifen, wie wir es bei den CSS-Problemen getan haben. Targeting dieses Browsers. VERWENDEN SIE KEIN BROWSER-SNIFFING. Verwenden Sie die Funktionserkennung, um Ihren Browser / dessen DOM-Unterstützung aufzuspüren.

JScript ist keine IE-eigene Implementierung von ECMAScript. JScript war die Antwort von IE auf Netscape's JavaScript, die beide vor ECMAScript entstanden sind.

In Bezug auf Typattribute für das Skriptelement ist type = "text / javascript" der Standardstandard (zumindest in HTML5), sodass Sie niemals ein Typattribut benötigen, es sei denn, Ihr Skript ist kein JavaScript.

Soweit IE innerHTML nicht unterstützt ... innerHTML wurde von IE erfunden und ist bis heute KEIN DOM-Standard. Andere Browser haben es übernommen, weil es nützlich ist, weshalb Sie es browserübergreifend verwenden können. In Bezug auf sich dynamisch ändernde Tabellen sagt MSDN: "Aufgrund der spezifischen Struktur, die für Tabellen erforderlich ist, sind die Eigenschaften innerText und innerHTML der Tabellen- und tr-Objekte schreibgeschützt." Ich weiß nicht, wie viel davon anfangs zutraf, aber die modernen Browser haben es eindeutig herausgefunden, während sie sich mit der Komplexität des Tabellenlayouts befassten.

Ich empfehle dringend, PPK über JavaScript zu lesen. Jeremy Keiths DOM-Scripting Douglas Crockfords JavaScript: The Good Parts und Christian Hellmans JavaScript - Anfang mit DOM-Scripting und Ajax , um einen guten Einblick in JavaScript zu erhalten.

Wenn Sie Frameworks / Bibliotheken noch nicht genau kennen, sollten Sie sie vermeiden. Vor 2 Jahren bin ich in die jQuery-Falle geraten, und obwohl ich großartige Leistungen vollbringen konnte, habe ich nie etwas über das richtige Codieren von JavaScript gelernt. Im Nachhinein ist jQuery ein verdammt tolles DOM-Toolkit, aber mein Versagen, die richtigen Abschlüsse, die prototypische Vererbung usw. zu lernen, hat nicht nur mein persönliches Wissen zurückgeworfen, sondern meine Arbeit begann, große Leistungstreffer zu erzielen, weil ich keine Ahnung hatte, was ich tat.

JavaScript ist die Sprache des Browsers. Wenn Sie ein Client-seitiger / Front-End-Ingenieur sind, ist es äußerst wichtig, dass Sie JavaScript beherrschen. Node.js bringt JavaScript auf Hochtouren. Ich sehe täglich enorme Fortschritte in seiner Entwicklung. Serverseitiges JavaScript wird in naher Zukunft ein Standard sein. Ich erwähne dies, um weiter zu betonen, wie wichtig JavaScript jetzt ist und sein wird.

JavaScript wird mehr Wellen schlagen als Rails.

Viel Spaß beim Scripting!


2
Gute Antwort, obwohl ich nicht damit einverstanden bin, die Funktionserkennung zum Aufspüren des Browsers zu verwenden. Verwenden Sie die Feature-Erkennung nur, um die Unterstützung dieser Features zu testen . Siehe auch die Beispiele unter Funktionserkennung ist keine Browsererkennung .
Marcel Korpel

meh. Ich stimme Ihrer Meinungsverschiedenheit voll und ganz zu. Danke, dass du das verstanden hast. Ich bin immer noch ein JavaScript n00b, aber es ist keine Schande in meinem Spiel. "Die funktionsbasierte Browsererkennung ist eine sehr schlechte Vorgehensweise, die unbedingt vermieden werden sollte. Die direkte Funktionserkennung ist eine bewährte Methode und in fast allen Fällen genau das, was Sie benötigen."
Albert

2

Einige native Objekte sind schreibgeschützt, ohne es wirklich zu sein (Sie können darauf schreiben, aber es hat keine Auswirkung). Ein allgemeines erweitertes Javascript basiert beispielsweise auf der Erweiterung des ElementObjekts durch Überschreiben von Systemmethoden, z. B. Ändern von Element.prototype.appendChild (), um mehr zu tun als einen untergeordneten Knoten anzuhängen - beispielsweise mit den Daten der Eltern zu initialisieren. Dies schlägt im IE6 unbeaufsichtigt fehl - die ursprüngliche Methode wird für neue Objekte anstelle des neuen aufgerufen.

Einige Browser (ich erinnere mich nicht, welche jetzt) ​​betrachten Zeilenumbrüche zwischen HTML-Tags als Textknoten, andere nicht. ChildNodes (n), nextSibling (), firstChild () und dergleichen verhalten sich also sehr unterschiedlich.


2

Nachgestellte Kommas in Arrays und Objektliteralen waren früher ein Problem, wurden in letzter Zeit nicht überprüft (dh IE8):

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

Dies würde zusätzlichen Code verursachen, wenn solche Strukturen serverseitig generiert werden.


2

Ich habe heute Morgen gerade einen gefunden, ein Mitarbeiter hat das Skript-Tag wie <script type="application/javascript">folgt festgelegt : Weil sein Ide Autocomplete das vor "Text / Javascript" hatte.

Es stellt sich jedoch heraus, dass der IE das gesamte Skript einfach ignoriert, wenn Sie "application / javascript" verwenden. Sie müssen "text / javascript" verwenden.


Javascript ist Standard in allen Browsern, verwenden Sie also nur<script>
Lauri

2

Ich habe neulich mit Internet Explorer eine merkwürdige Eigenart gefunden. Ich habe YUI verwendet und den Inhalt eines Tabellenkörpers () durch Festlegen von innerHTML ersetzt

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

Dies würde in allen Browsern außer IE funktionieren. Endlich stellte ich fest, dass Sie das innerHTML einer Tabelle im IE nicht ersetzen konnten. Ich musste einen Knoten mit YUI erstellen und diesen Knoten dann anhängen.

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

Es hat Spaß gemacht, das herauszufinden!


1
Ich habe das Gefühl, dass Sie es mit <tbody>Tags umwickeln müssen .
Casey Chu

Im Originalcode ist es tatsächlich in ein <tbody> -Tag eingeschlossen. Es ist mir immer noch ein Rätsel, dass es dem IE nicht gefallen hat. Ich erinnere mich, dass ich es in den offiziellen Dokumenten von Microsoft gelesen habe, aber ich kann den Link jetzt nicht finden. Es tut uns leid!
Justin

1

Zusätzliche Kommas und fehlende Kommas waren im IE ein übliches Problem, während es in FF reibungslos funktioniert.


1

IE ist sehr streng über das Fehlen von ";" so ist normalerweise das.


Ich finde viele davon, während ich jetzt jsLinting bin. Scheint ein wichtiger Punkt zu sein.
user89021

1

Für das, was es wert ist, bin ich gerade auf dieses böse Problem in <IE9 gestoßen

Angenommen, Sie haben ein HTML wie dieses:

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

und aus irgendeinem Grund (ich hatte einen guten) müssen Sie den gesamten HTML-Code in der Tabelle vor dem letzten schließenden TR abrufen. Möglicherweise versuchen Sie Folgendes:

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

<IE9 gibt hier nichts (-1) zurück, da die Variable tableHtml alle HTML-Tags in Großbuchstaben enthält und lastIndexOf zwischen Groß- und Kleinschreibung unterscheidet. Um dies zu umgehen, musste ich vor lastIndexOf ein toLowerCase () einwerfen.


0

IE ist kein moderner Browser und folgt ECMAScript nur lose.


0

Sie haben jQuery erwähnt, mit dem ich weniger vertraut bin, aber als allgemeine Referenz und speziell für Prototype sollten Sie auf reservierte Wörter / Methodennamen im IE achten. Ich weiß, was mich oft erwischt, sind Dinge wie:

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

(Mit dem neuen Element (tagName, propertyHash) werden in Protitype neue Elemente erstellt.) Im IE for:muss sein 'for':, weilfor es sich um ein reserviertes Wort handelt. Was durchaus Sinn macht - aber FireFox wird dies tolerieren.

Ein anderes Beispiel:

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

(Die wrapMethode in Prototype umschließt ein Element mit einem anderen.) - In IE ist in Textbereichen wrapeine Eigenschaft undElement.wrap() muss anstelle der methodisierten Version verwendet werden

Dies sind zwei Beispiele, die mir aus meiner Erfahrung in den Sinn kommen. Sie basieren auf Prototypen, aber das Kernproblem ist nicht: Achten Sie auf Methoden / Labels / Bezeichner, die der IE als reservierte Wörter betrachtet, die FireFox oder Safari jedoch tolerieren.


0

Tatsache ist, dass der IE kein JavaScript unterstützt ... Es unterstützt seine eigene Implementierung von ECMAScript: JScript ... was etwas anders ist ...


0

Die Verwendung console.log()für die Ausgabe von Fehlern an die Firefox-Fehlerkonsole führt dazu, dass Ihre Skripte im IE fehlschlagen. Ich muss daran denken, diese herauszunehmen, wenn Sie im IE testen.


Ich glaube, dass die Verwendung von console.log auch in Firefox fehlschlägt, wenn Sie FireBug nicht aktiviert haben.
Ejel
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.