browser.html

<!DOCTYPE html>
<html lang="de">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<title>JavaScript: Browserübergreifende Entwicklung</title>
<link rel="stylesheet" href="js-doku.css">
<script type="text/javascript" src="js-doku.js"></script>
</head>
<body>

<div id="nav">
<p>Hier entsteht eine <strong>JavaScript-Dokumentation</strong> von <a href="http://molily.de/">molily</a>. Derzeit ist sie noch lückenhaft, wächst aber nach und nach. Kommentare und Feedback werden gerne per <a href="mailto:zapperlott@gmail.com">E-Mail</a> entgegen genommen.</p>
<p class="contents-link"><a href="./">Zum Inhaltsverzeichnis</a></p>
</div>

<h1>JavaScript: Browserübergreifende Entwicklung</h1>

 <div class="section" id="browserwirklichkeit">
  <h2>JavaScript und die Browser-Wirklichkeit</h2>
  <p>Wer schon etwas Erfahrung in der Webentwicklung gesammelt hat, kennt das Problem: Ein Großteil der Arbeit muss dafür investiert werden, Unterschiede und Fehler der verbreiteten Browser zu berücksichtigen. Besonders im Bereich CSS muss man mit Browserweichen arbeiten, um alle großen Browser zu einer halbwegs einheitlichen Darstellung zu bringen.</p>
  <p>Wie sieht es im Bereich JavaScript aus? Zunächst einmal ähnlich schlecht. Manche Browser setzen die DOM-Standards nicht vollständig um und für zahlreiche Aufgaben existieren nur proprietäre Technike. Somit sind oftmals <strong>mehrgleisige Scripte</strong> nötig, die dieselbe Aufgabe je nach Browser auf eine unterschiedliche Weise lösen.</p>
  <p>Dennoch gibt es keinen Grund, vor dem Browser-Durcheinander zu kapitulieren. Während es in CSS nur ungenaue Browserweichen gibt, ist es in JavaScript meistens möglich, gezielt die <strong>Existenz der Objekte abzufragen</strong>. Existiert ein Objekt und hat gegebenenfalls einen bestimmten Typ und Wert, kann damit gearbeitet werden. Andernfalls können Alternativlösungen greifen. Verwendet man solche »<strong>Fähigkeiten-Weichen</strong>« anstelle von Browserweichen, die bloß über den Browsernamen Rückschlüsse ziehen, sind zuverlässige und zukunftsfähige Scripte möglich.</p>
  <p>Zudem wurden mittlerweile die wichtigsten Unterschiede, Eigenheiten und Fehler der verbreiteten Browser in mühsamer Kleinarbeit dokumentiert. Dabei fielen fertige Script-Schnipsel und bewährte Verfahren ab, mit denen sich <strong>Standardaufgaben browserübergreifend lösen</strong> lassen. Schließlich ist in puncto JavaScript Bewegung in den Browsermarkt gekommen: Nach und nach werden Fehler bei der Umsetzung von Standards behoben, undokumentierte Techniken werden standardisiert und in die Browser eingebaut.</p>
  <p>Dieser Ausblick soll optimistisch stimmen und dazu anregen, die Herausforderung der Browser-Wirklichkeit anzunehmen. Es ist jedoch auch ein hartes Stück Arbeit, sich in die browserübergreifende JavaScript-Entwicklung hineinzudenken.</p>
</div>
<div id="abwaertskompatibilitaet" class="section">
  <h2>Abwärtskompatibilität und Zukunftsfähigkeit</h2>
  <p>Was bedeutet eigentlich »browserübergreifende Entwicklung«? Üblicherweise wird darunter verstanden: Ein Script soll in allen Browsern den gewünschten Zweck erfüllen und dasselbe leisten. Von dieser einseitigen Vorstellung sollten Sie sich verabschieden, denn in vielen Fällen ist sie schlicht nicht umsetzbar!</p>
  <p>Das realistische Ziel sollte vielmehr lautet, die vergangenen, gegenwärtigen und zukünftigen Browser <strong>gemäß ihrer jeweiligen Fähigkeiten</strong> zu bedienen. Dies bedeutet nicht, dass ihr Script auf allen Browsern und Browserversionen exakt denselben Effekt haben muss. Es ist nicht immer sinnvoll, technisch veralteten oder wenig verbreiteten Browser mit unverhältnismäßigem Aufwand dasselbe Ergebnis zu liefern.</p>
  <p>Dennoch ist es durch geschickte Programmierung meistens möglich, alle relevanten Browsern eine funktionsfähige Seite zu präsentieren - auch wenn diese z.B. in älteren Browsern nicht ganz so ansehnlich und komfortabel bedienbar ist wie in weiter entwickelten Browsern.</p>
  <p><em>Abwärtskompatibilität</em> bedeutet, dass Ihr Script auf den Fall vorbereitet ist, dass gewisse JavaScript-Techniken nicht zur Verfügung steht oder von Seiten des Browsers fehlerhaft umgesetzt sind. <em>Zukunftsfähigkeit</em> bedeutet, dass Sie durchaus neue und noch nicht breit unterstützte Techniken verwenden können. Voraussetzung ist jeweils, dass sie keine Techniken stillschweigend voraussetzen, sondern immer prüfen, ob die benötigten Objekte existieren und die Teilanweisungen ihres Programmes die erwarteten Ergebnisse liefern.</p>
</div>
<div id="fallunterscheidungen" class="section">
  <h2>Fallunterscheidungen und Vereinheitlichungen</h2>
  <p>Das Grundelement der browserübergreifenden Programmierung ist der mehrgleisiger Ablauf. Scripte nutzen immer wieder eine solche Struktur:</p>
  <pre class="content-example">Wenn die nötige Technik zur Verfügung steht,
Dann:
  Löse das Problem auf die eine Weise
Andernfalls:
    Wenn die Alternativtechnik zur Verfügung steht,
    Dann:
      Löse die Aufgabe auf eine andere Weise</pre>
	<p>Diese Fallunterscheidungen werden in JavaScript üblicherweise mit bedingten Anweisungen umgesetzt: <code>if (Bedingung) { Anweisungen } else { Anweisungen }</code></p>
  <p>Entscheidend ist, genau die Unterschiede zu kennen und <em>punktuell</em> solche Abzweigungen einzubauen. Nicht das ganze Script sollte eine solche Struktur haben, es sollte sich dieser verzweigten Abläufe nur dort bedienen, <em>wo es nötig ist</em>. Auf diese Weise sparen Sie sich doppelte Arbeit.</p>
  <p>Wo Unterschiede auftreten, sollten Sie mit solchen Abfragen möglichst für <strong>Vereinheitlichung</strong> sorgen. Darauffolgende Anweisungen müssen sich dann um die Unterschiede keine Gedanken mehr machen. Bis zur nächsten punktuellen Fallunterscheidung folgt wieder Code, der von allen Browsern verstanden wird.</p>
  <p>Nehmen wir ein Beispiel aus dem : Eine Handler-Funktion bekommt das  in manchen Browsern als Parameter übergeben. Im Internet Explorer ist es jedoch nur über <code>window.event</code> zugänglich. Über das Event-Objekt hat man Zugriff auf das , bei dem das Ereignis passiert ist, welches die Handler-Funktion gerade verarbeitet. Auch in dem Punkt unterscheiden sich die Browser: Das Element ist entweder in der Eigenschaft <code>target</code> (W3C-konforme Browser) oder <code>srcElement</code> (Internet Explorer) gespeichert. Nun könnte man folgendermaßen vorgehen:</p><pre class="content-example">function handlerFunktion (eventObjekt) {
  if (eventObjekt) {
    alert("Element, an dem das Ereignis passierte: " + eventObjekt.target.nodeName);
  } else if (window.event) {
    alert("Element, an dem das Ereignis passierte: " + window.event.srcElement.nodeName);
  }
}</pre><p>Allerdings ist dieser Code stellenweise redundant und setzt stillschweigend voraus, dass die Übergabe des Event-Objektes als Parameter und <code>target</code> sowie <code>window.event</code> und <code>srcElement</code> notwendigerweise zusammengehören - das ist zwar bei diesem Beispiel kein Problem, aber in anderen Fällen kann eine solche Annahme Probleme bringen.</p>
  <p>Anstatt direkt browserspezifischen Code zu schreiben, nutzen wir <strong>punktuelle Vereinheitlichung</strong>, die gleiche Voraussetzungen für das Script schafft. Nachdem die Browserunterschiede eingeebnet wurden, können wir die Aufgabe, die wir eigentlich lösen wollen, viel einfacher umsetzen. Vor allem wird der Code übersichtlicher und besser strukturiert: Die Bereiche, die sich nur den Browserproblemen widmen, sind getrennt von denen, die die eigentliche Aufgabe lösen.</p>
  <pre class="content-example">function handlerFunktion (eventObjekt) {

  // Vereinheitliche den Zugriff auf das Event-Objekt:
  if (!eventObjekt) {
    eventObjekt = window.event;
  }
  // Das Objekt ist jetzt browserübergreifend in der Variable eventObj gespeichert.

  // Vereinheitliche den Zugriff auf das Ziel-Element:
  var target;
  if (eventObjekt.target) {
    target = eventObjekt.target;
  } else if (eventObjekt.srcElement) {
    target = eventObjekt.srcElement;
  }
  // Das Objekt ist nun browserübergreifend in der Variable target gespeichert.

  // Nach den Vereinheitlichungen folgt die eigentliche Umsetzung.
  // Stelle das Gewünschte mit dem Ziel-Element an:
  alert("Element, an dem das Ereignis passierte: " + target.nodeName);

}</pre>
<p>Diese Umsetzung mag zunächst länger und umständlicher scheinen. Das liegt jedoch bloß an der ausführlichen Schreibweise. Eine
	 mögliche Kurzschreibweise könnte so aussehen:</p>
  <pre class="content-example">function handlerFunktion (e) {
  e = e || window.event;
  var target = e.target || e.srcElement;
  alert("Element, an dem das Ereignis passierte: " + target.nodeName);
}</pre>
<p>Mit dem <code>||</code>-Operator wird hier die Fallunterscheidung umgesetzt. Was kryptisch aussehen mag, hat bloß folgenden Effekt: Wenn der Parameter <code>e</code> gesetzt ist, nehme diesen als Event-Objekt, andernfalls versuche es mit <code>window.event</code>.</p>
  <p>Dasselbe Schema wird in der nächsten Zeile angewendet: Wenn die Eigenschaft <code>target</code> des Event-Objektes gesetzt ist, so speichere diese in der Variable <code>target</code>, andernfalls verwende die Eigenschaft <code>srcElement</code>.</p>
  <div class="note-box note-box-todo">
	 <div class="note-box-text">Todo: Erklärung des ||-Operators in den Sprachgrundlagen verlinken</div>
  </div>
  <p>Das Beispiel lässt außen vor, dass Browser denkbar sind, die weder die eine noch die andere Vorgehensweise unterstützen. Oder die Handler-Funktion wird aus Versehen außerhalb einer Ereignis-Verarbeitung aufgerufen. Es ist nicht immer nötig, diese denkbaren, aber unrealistischen Fälle abzudecken. Sie können es dennoch tun, indem Sie abfragen, ob die Variablen <code>e</code> und <code>target</code> nach der Vereinheitlichung korrekt gesetzt sind. Wenn dies nicht gegeben ist, kann die
	 Funktionsausführung z.B. durch die Anweisung <code>return;</code> abgebrochen werden.</p>
  <pre class="content-example">e = e || window.event;
if (!e) {
  // Kein Zugriff auf das Event-Objekt möglich, breche Funktion ab,
  // um einen Scriptabbruch zu umgehen.
  return;
}</pre>
<p>Beachten Sie, dass diese Schreibweise zum Überprüfen der Variable <code>e</code> nur Sinn ergibt, wenn es sich um einen Funktionsparameter handelt, der entweder den Wert <code>undefined</code> hat (falls kein Parameter übergeben wurde) oder eben das Event-Objekt enhält. Beim Umgang mit anderen Objekttypen sähe die Abfrage anders aus.</p>
</div>
<div id="faehigkeitenerkennung" class="section">
  <h2>Fähigkeitenerkennung statt Browsererkennung</h2>
  <p>Lange Zeit bedienten sich browserübergreifende JavaScripte einer sogenannten Browsererkennung. Anstatt in Erfahrung zu bringen, mit welchen konkreten Unterschieden das Script konfrontiert ist, fragte man kurzerhand den <strong>Browsernamen</strong> ab. Die Struktur einer solchen Browserweiche sah etwa so aus:</p>
  <pre class="content-example">Wenn der Browser den Namen »Internet Explorer« hat,
Dann:
  Löse die Aufgabe auf die die IE-typische Weise
Andernfalls:
  Löse die Aufgabe auf die Netscape-typische Weise</pre>
<p>Umgesetzt wurden solche Abfrage mit dem JavaScript-Objekt <code>window.navigator</code>, das verschiedene Informationen über den Browser liefert, der das JavaScript ausführt.</p>
  <p>In dem obigen Beispiel werden allein die Browser Internet Explorer und Netscape Navigator berücksichtigt, die sich Ende der 1990er Jahre gegenüberstanden und den Browsermarkt beherrschten. Diese Vorgehensweise ging so lange gut, wie nur diese beiden Browser verbreitet waren und sich deren Versionen gleich verhielten. Diese Situation war jedoch höchstens für eine kurze Zeit gegeben - danach funktionierten solche Scripte nicht mehr zuverlässig.</p>
  <p>Alternativ zur Abfrage des Browsernamens wurden <strong>zentrale Objekte</strong> zur Browsererkennung verwendet:</p>
  <pre class="content-example">Wenn das Objekt document.all existiert,
Dann:
  Nimm an, es ist ein Internet Explorer und löse die Aufgabe
  auf die die IE-typische Weise
Andernfalls:
  Wenn das Objekt document.layers existiert,
  Dann:
    Nimm an, es ist ein Netscape Navigator und löse die Aufgabe
    auf die Netscape-typische Weise</pre>
  <p>Solche Objektabfragen sind nicht völlig abwegig, denn die abgefragten Objekte <code>document.all</code> und <code>document.layers</code> wurden bei der Umsetzung meistens auch verwendet. Wenn jedoch von der Existenz <em>eines</em> Objektes wird stillschweigend auf die Existenz vieler anderer Browserfähigkeiten geschlossen wird, handelt es sich um eine versteckte Browserabfrage.</p>
  <p>Eine Browserweiche geht davon aus, dass der Browser eine Reihe von Techniken unterstützt, nur weil er einen bestimmten Namen trägt oder ein zentrales Objekt existiert. Zum einen können damit immer nur die derzeit bekannten Browser in ihren aktuellen Versionen berücksichtigt werden.</p>
  <p>Zum anderen halten sich viele Browser an herstellerunabhängige Standards, die sie mehr oder weniger korrekt umsetzen. Aber auch zahlreiche proprietäre, das heißt ursprünglich browserspezifische Erfindungen sind nicht mehr auf einen Browser begrenzt. Andere Hersteller haben sie ebenfalls übernommen. »Browserabfragen« sind schon aus diesem Grund nicht zuverlässig und zukunftsfähig.</p>
  <p>Beispielsweise wird das längst veraltete Objekt <code>document.all</code> immer noch zur Erkennung des Internet Explorers verwendet. Das ist unklug, denn oftmals gibt es andere Browser, die die verwendeten Fähigkeiten beherrschen, jedoch nicht <code>document.all</code>.</p>
  <p>Browserweichen können daher prinzipiell nicht alle Fälle angemessen berücksichtigen. Sie sollten sie möglichst vermeiden und stattdessen abfragen, ob der jeweilige Browser die <em>Fähigkeiten und Teiltechniken unterstützt</em>, die sie <em>tatsächlich in ihrem Script verwenden</em>.</p>
</div>
<div id="objektabfragen" class="section">
  <h2>Objektabfragen</h2>
  <div id="objekte-methoden" class="section">
	 <h3 class="unit-std-heading">Objekte und Methoden abfragen</h3>
	 <p>Die einzelnen Fähigkeiten eines Browsers drücken sich meist darin aus, dass bestimmte vordefinierte Objekte, Eigenschaften bzw. Methoden existieren. In manchen Fällen müssen Sie zusätzlich prüfen, ob die Eigenschaft auch einen bestimmten Typ oder Wert hat.</p>
	 <p>Wenn wir eine bedingte Anweisung mit <code>if (...) {...}</code> notieren, so wird die Bedingung (der Ausdruck zwischen den runden Klammern) letztlich in einen Boolean-Wert, also <code>true</code> oder <code>false</code> umgewandelt. Allgemeine Objekte vom Typ <code>Object</code> ergeben bei der Umwandlung in dem Typ <code>Boolean</code> den Wert <code>true</code>.</p>
	 <p>Das bedeutet, Sie können einfach <code>if (objekt.unterobjekt) { ... </code>} notieren, um die Existenz des Unterobjektes abzufragen. Für Funktionsobjekte gilt dasselbe, also notieren wir <code>if (objekt.methode) { ... </code>}. Die Schreibweise <code>objekt.unterobjekt</code> bzw. <code>objekt.methode</code> ist dabei entscheidend. Nur in besonderen Fällen ist dies durch <code>if (objekt)</code> bzw. <code>if (methode)</code> ersetzbar.</p>
	 <p>Das folgende Beispiel veranschaulicht die Existenzabfrage von Objekten und Methoden. Die Funktion bringt den aktuell markierten Text im Dokument in Erfahrung und gibt diesen in einem Meldungsfenster aus.</p>
	 <pre class="content-example">function selektierterText () {
  var text = "";

  if (window.getSelection) {
    text = window.getSelection();
  } else if (document.getSelection) {
    text = document.getSelection();
  } else if (document.selection &amp;&amp; document.selection.createRange) {
    text = document.selection.createRange().text;
  } else {
    return;
  }

  alert(text);
}</pre>
<p>Es existieren für diese Aufgabenstellung <strong>drei Lösungsweisen</strong>, die in unterschiedlichen Browsern zum Ziel führen. Das Beispiel demonstriert daher eine dreiteilige Fallunterscheidung mit verschachtelten <code>if</code>-<code>else</code>-Anweisungen.</p>
	 <p>Je nachdem, welche Objekte bzw. Methoden existieren, werden diese verwenden. Kennt der JavaScript-Interpreter keines dieser Objekte, wird die Funktion vorzeitig beendet. Die verschachtelten Fallunterscheidung in verständlicher Sprache:</p>
	 <pre class="content-example">Existiert die Methode window.getSelection?
Falls ja:
  benutze diese Methode.
Falls nein:
  Existiert die Methode document.getSelection?
  Falls ja:
    Benutze diese Methode.
  Falls nein:
    Existiert das Objekt document.selection und hat es eine Methode createRange?
      Falls ja:
        Benutze diese Methode.
      Falls nein:
        Brich ab.</pre>
<p>Wie Sie sehen, kommt dieses Beispiel ganz ohne Browserabfragen aus und ist doch für verschiedene Browser ausgelegt.</p>
  </div>
  <div class="section">
	 <h3 class="unit-std-heading">Andere Typen abfragen</h3>
	 <p>Wenn Sie die Existenz von Objekten anderer Typen prüfen wollen, müssen Sie gegebenenfalls anders vorgehen.</p>
	 <p>Zahlen (Typ <code>Number</code>) und Zeichenketten (Typ <code>String</code>) können Sie im Prinzip zwar auch mit <code>if (objekt.numberEigenschaft)</code> bzw. <code>if (objekt.stringEigenschaft)</code> abfragen. Die Bedingung in den Klammern wird aber wie gesagt in ein <code>Boolean</code>-Wert umgewandelt. Leere Zeichenketten (<code>""</code>) und gewisse Zahlenwerte (z.B. <code>0</code>) ergeben bei dieser Umwandlung <code>false</code>. Diese Umwandlungsregeln können Verwirrung stiften: Manchmal ist <code>0</code> ein gültiger Wert und Sie können damit arbeiten, in anderen Fällen weist er darauf hin, dass der Browser die von Ihnen benötigte Fähigkeit nicht hat und Sie die abgefragte Eigenschaft nicht verwenden können.</p>
	 <div class="note-box note-box-todo">
		<p class="note-box-title">ToDo: Link auf "Was ist alles true/false?"</div>
	 </div>
	 <p>Wenn Sie mit solchen Typen umgehen, sollten Sie daher auf den Operator <code>typeof</code> ausweichen. Dieser gibt den Typ einer Eigenschaft als String zurück. In den beschriebenen Fällen wäre das <code>"string"</code> bzw. <code>"number"</code>). Ein Beispiel ist die Abfrage der Existenz von <code>window.innerHeight</code>:</p>
	 <pre class="content-example">if (typeof window.innerHeight == "number") {
  alert("Der Anzeigebereich des Browserfensters ist " +
    window.innerHeight + " Pixel breit!");
}</pre>
<p>Da manche Browser, insbesondere der Internet Explorer beim Einsatz <code>typeof</code> den Typen nicht immer korrekt wiedergeben, hat sich eingebürgert, bei Existenzabfragen bloß zu prüfen, ob <code>typeof</code> nicht <code>"undefined"</code> liefert:</p>
	 <pre class="content-example">if (typeof window.innerHeight != "undefined") {
  alert("Der Anzeigebereich des Browserfensters ist " +
    window.innerHeight + " Pixel breit!");
}</pre>
<div class="note-box note-box-todo">
		<p class="note-box-title">ToDo: siehe den weiterführenden Artikel <a href="http://aktuell.de.selfhtml.org/artikel/javascript/objektabfragen/">Objektabfragen und Fallunterscheidungen in JavaScript</a></div>
	 </div>
  </div>
</div>
<div id="erkennung-sonderfaelle" class="section">
  <h2>Browsererkennung in Sonderfällen</h2>
  <p>Eine Fähigkeitenerkennung mit Abfragen der verwendeten Objekte ist in den meisten Fällen möglich und vorzuziehen. Wenn Sie diese Vorgehensweise gewohnt sind, werden Sie bei neuen Aufgaben schnell einen Weg finden, wie sie die Browserunterschiede in Ihrem Script zuverlässig prüfen und entsprechende Fallunterscheidungen einbauen können. Es sei allerdings nicht verschwiegen, dass sich manche Browsereigenheiten und -fehler nicht so einfach erkennen lassen. Diese Fälle sind glücklicherweise äußerst selten.</p>
  <p>Ein Beispiel: Sie prüfen, ob eine Methode existiert und rufen Sie auf, falls sie existiert. Wenn ein Browser die Methode nun kennt, aber falsch implementiert hat, sodass sie nicht das beabsichtigte tut, können Sie dies nicht immer erkennen. Wenn auch der Rückgabewert in Ordnung scheint, können Sie den Browserfehler schwer feststellen.</p>
  <p>In diesen Ausnahmefällen bleibt oft nichts anderes als eine Browserabfrage übrig. Wenn Sie eine solche einbauen, müssen Sie darauf achten, dass das Script nicht unter unerwarteten Umständen fehlerhaft arbeitet. Beispielweise kann der Browserfehler, den Sie umgehen wollen, schon in der nächsten Version behoben sein. Dann kann es sein, dass Ihr Script abbricht. Eine Regel lautet daher, nur bekannte Browserversionen anzusprechen. Doch auch diese Vorgehensweise hat ihren Nachteil: Erscheint eine neue Version, die den Fehler immer noch beinhaltet, müssen Sie das Script zeitnah aktualisieren und die Erkennung anpassen. Wie Sie sehen, handelt Sie sich mit Browserabfragen schnell Probleme ein.</p>
  <p>Eine allgemeine Browsererkennung ist über das Objekt <code>window.navigator</code> und dessen Eigenschaften möglich. Ein Fertigscript, das Ihnen Browsername und -version zur Verfügung stellt, finden Sie unter <a href="http://www.quirksmode.org/js/detect.html" class="anchor-external" lang="en">Browser detect [en]</a>. Seien Sie sich jedoch darüber im klaren, dass diese <code>navigator</code>-Eigenschaften nicht verfügbar oder manipuliert sein können - eine Erkennung über <code>navigator</code> ist nicht hundertprozentig zuverlässig!</p>
  <p>Für spezifische Browser gibt es zuverlässigere Erkennungsmethoden:</p>
  <p><strong>Opera</strong> bietet das Objekt <code>window.opera</code> an, welches auch nur im Opera existiert. Dieses können Sie einfach mit <code>if (window.opera) {...}</code> abfragen.</p>
  <p>Wenn Sie den <strong>Internet Explorer</strong> in einem Script erkennen wollen, so können Sie alternativ zu <em>Conditional Compilation</em> (engl. bedingte Ausführung) greifen. Dabei handelt es sich um eine Microsoft-eigene Zusatzsprache, die Sie in den JavaScript-Code einfügen können. Im Grunde handelt es sich um JavaScript-Kommentare nach dem Schema <code>/*@cc_on ... @*/</code>. Während die anderen Browser sie ignorieren, erkennt der Internet Explorer <code>@cc_on</code> eine Anweisung. In diesem Fall: Schalte Conditional Compilation (CC) an. Das bedeutet, dass der Internet Explorer den Text zwischen <code>@cc_on</code> und <code>@</code> als JavaScript-Code behandelt und ausführt, obwohl diese sich in einem Kommentar befindet. Lange Rede, kurzer Sinn: Auf diese Weise können Sie JavaScript-Code notieren, der garantiert nur vom Internet Explorer ausgeführt wird - denn vor allen anderen Browser ist er in einem Kommentar versteckt. Ein Beispiel:</p>
  <pre class="content-example">if (/*@cc_on ! @*/ false) {
  window.alert("Dies wird nur im Internet Explorer ausgeführt!");
}</pre>
<p>Alle Browser außer dem Internet Explorer führen den Code <code>if (false) {...}</code> aus, nur im Internet Explorer wird mittels speziellem Kommentar ein Negationsoperator (das Ausrufezeichen) eingefügt. Der IE führt also <code>if (!false) {...}</code> und damit die Anweisungen im <code>if</code>-Block aus.</p>
  <p>...</p>
</div>
<div id="unterstuetzung" class="section">
  <h2>JavaScript-Unterstützung verbreiteter Browser</h2>
  <div class="section">
	 <h3 class="unit-std-heading">Einleitung</h3>
	 <p>... Engines statt Browser!</p>
  </div>
  <div class="section">
	 <h3 class="unit-std-heading">Mozilla Firefox (Gecko- und SpiderMonkey-Engine)</h3>
  </div>
  <div class="section">
	 <h3 class="unit-std-heading">Internet Explorer</h3>
  </div>
  <div class="section">
	 <h3 class="unit-std-heading">Opera</h3>
  </div>
  <div class="section">
	 <h3 class="unit-std-heading">Safari (Webkit-Engine)</h3>
  </div>
</div>

<div id="footer">
<p><strong>JavaScript-Dokumentation</strong> &middot; <a href="./">Zum Inhaltsverzeichnis</a></p>
<p>Autor: <a href="http://molily.de/">molily</a> &middot; Kontakt: <a href="mailto:zapperlott@gmail.com">zapperlott@gmail.com</a></p>
<p>Lizenz: <a rel="license" href="http://creativecommons.org/licenses/by-sa/3.0/de/">Creative Commons Namensnennung - Weitergabe unter gleichen Bedingungen</a>.</p>
</div>

</body>
</html>