Erkennen von Funktionen anstelle von Browsern

Aktualisierung: Dezember 2013

Bisher haben viele Webentwickler eine Browsererkennung implementiert, um eine gewisse Konsistenz bei der Anzeige von Webseiten in den verschiedenen Browsern zu erreichen. In der Regel wird dabei ein einzelner Vergleichsvorgang ausgeführt. Er umfasst meist die Benutzer-Agent-Zeichenfolge. Anschließend werden verschiedene Designannahmen zu den Features formuliert, die von diesem Browser unterstützt werden. In der Praxis hat sich die Featureerkennung jedoch als effizienteres und weniger wartungsintensives Verfahren erwiesen. In diesem Artikel wird beschrieben, wie Sie mit der Featureerkennung die Unterstützung standardbasierter Features überprüfen. Darüber hinaus werden verschiedene Möglichkeiten zur effektiven Erkennung von Features demonstriert.

Nachteile der Browsererkennung

Bei einer typischen Implementierung weist die Browsererkennung einige Nachteile auf:

  • Wenn ein neuer Browser veröffentlicht oder ein vorhandener Browser aktualisiert wird, müssen Sie den neuen Browser im Browsererkennungscode berücksichtigen. Aktualisierte Browser unterstützen möglicherweise Standards und Features, die zum Zeitpunkt des Entwurfs des Browsererkennungscodes nicht unterstützt wurden.
  • Schlussfolgerungen zur Featureunterstützung sind möglicherweise nicht richtig oder angemessen.
  • Zu neuen Geräten gehören häufig auch neue Browserversionen. In der Folge muss der Browsererkennungscode überprüft und eventuell geändert werden, damit die neuen Browser unterstützt werden. Im manchen Fällen ist es komplizierter, angepasste Implementierungen für die einzelnen Browser zu erstellen.
  • Eine Browsererkennungsmethode identifiziert möglicherweise einen bestimmten Browser nicht richtig. Beispiel: Viele Browser unterstützen die Möglichkeit, die Benutzer-Agent-Zeichenfolge zu ändern.

Betrachten Sie dazu das folgende (ungültige) Codebeispiel. Dieser Code versucht auf unkorrekte Weise, einen Ereignishandler mithilfe browserspezifischer Verfahren zuzuweisen.


function getInternetExplorerVersion()
// Returns the version of Internet Explorer or a -1
// (indicating the use of another browser).
{
  var rv = -1; // Default value assumes failure. 
  var ua = navigator.userAgent;

  // If user agent string contains "MSIE x.y", assume
  // Internet Explorer and use "x.y" to determine the
  // version.
 
  var re  = new RegExp("MSIE ([0-9]{1,}[\.0-9]{0,})");
  if (re.exec(ua) != null) 
    rv = parseFloat( RegExp.$1 );
  return rv;

}

function registerEvent( sTargetID, sEventName, fnHandler ) 
{
  var oTarget = document.getElementById( sTargetID );
  if ( oTarget != null ) { 

     // This is not an optimal example; it demonstrates 
     // techniques that you should not follow. 

     if ( getInternetExplorerVersion() > -1 ) { 
       oTarget.attachEvent( "on" + sEventName, fnHandler );
     } else {
       oTarget.addEventListener( sEventName, fnHandler ); 
     }
  }
}

In diesem Beispiel wird versucht, mithilfe der Benutzer-Agent-Zeichenfolge zu bestimmen, ob es sich beim Browser um Windows Internet Explorer handelt. Der Code funktioniert zwar in Internet Explorer und den meisten anderen Browsern, enthält jedoch mehrere Probleme:

  • Das Codebeispiel konzentriert sich auf den Browser (Internet Explorer), nicht auf das Feature (Ereignishandlerregistrierung für DOM-Ebene 3). Daher registriert das Beispiel, wenn die Webseite mit Internet Explorer angezeigt wird, auch dann mit attachEvent die Ereignishandler, wenn die Version von Internet Explorer die addEventListener-Methode unterstützt. Außerdem müsste dieses Beispiel mit allen (hypothetischen) neuen Versionen von Internet Explorer getestet werden.
  • Dieses Beispiel nimmt an, dass Internet Explorer die addEventListener-Methode nicht unterstützt. In Bezug auf Internet Explorer 9 ist diese Annahme falsch. Viele Browsererkennungsimplementierungen arbeiten mit ähnlichen Annahmen.
  • Dieses Beispiel versucht zwar nicht, zwischen Versionen von Internet Explorer zu unterscheiden, aber die Behandlung der Benutzer-Agent-Zeichenfolge in Internet Explorer wurde geändert. Anwendungen, die gemäß dem Verhalten einer früheren Version entwickelt wurden, melden möglicherweise falsche Ergebnisse für Webseiten, die in der mit Internet Explorer 8 eingeführten Kompatibilitätsansicht angezeigt werden. Weitere Informationen finden Sie in den Artikeln Informationen zu Benutzer-Agent-Zeichenfolgen und Grundlegendes zur Kompatibilitätsansicht.

In diesem Beispiel werden viele Schwächen der Browsererkennung bei der Ermittlung der von einem Webbrowser unterstützten Features veranschaulicht. Einen effektiveren Ansatz bietet die direkte Erkennung der Unterstützung für das Feature (siehe folgenden Beispielcode).


function registerEvent( sTargetID, sEventName, fnHandler ) 
{
   var oTarget = document.getElementById( sTargetID );
   if ( oTarget != null ) 
   {
      if ( oTarget.addEventListener ) {   
         oTarget.addEventListener( sEventName, fnToBeRun, false );
      } else {
        var sOnEvent = "on" + sEventName; 
        if ( oTarget.attachEvent ) 
        {
           oTarget.attachEvent( sOnEvent, fnHandler );
        }
      }
   }
}

Dieses Beispiel bietet zwei Vorteile gegenüber dem oben beschriebenen Code:

  • Dieser Code konzentriert sich auf das Feature statt auf den Browser. Wenn Benutzer einen Browser verwenden, der die addEventListener-Methode unterstützt (beispielsweise Internet Explorer 9 und viele andere Browser), dann wird der Ereignishandler mit dieser Methode definiert.
  • Der Code bevorzugt die standardbasierte Methode gegenüber der proprietären Methode. In diesem Fall überprüft der Beispielcode die Unterstützung für die bevorzugte Methode (addEventListener), bevor die alternative Methode verwendet wird.

Dieses Beispiel ist effektiv, weil es nicht vom Verhalten eines bestimmten Browsers ausgeht. Die Methode muss weder aktualisiert werden, um alle (hypothetischen) neuen Versionen von Internet Explorer zu unterstützen, noch muss sie erweitert werden, um neue Browser oder Geräte zu unterstützen. Für den Beispielcode ist nur relevant, ob das Feature verfügbar ist. Dies ist der Hauptunterschied zwischen der Featureerkennung und der Browsererkennung.

Im Idealfall unterstützen alle Browser die gleichen Standards und implementieren diese Standards auf genau die gleiche Weise. In der Realität gibt es jedoch eine Reihe von Variationen zwischen den Browsern und bei der jeweiligen Implementierung der verschiedenen Standards.

Für Webentwickler besteht die beste Strategie darin, sich auf Features zu verlassen, die in allgemein unterstützten stabilen Standards definiert sind, beispielsweise HTML5, CSS3 (Cascading Stylesheets, Level 3), skalierbare Vektorgrafiken (Scalable Vector Graphics, SVG) usw. Erkennen Sie die Unterstützung für die Features, die Sie verwenden möchten, und stellen Sie alternative Methoden nur bei Bedarf bereit.

Es gibt eine Reihe von Möglichkeiten, um Features zu erkennen:

  • Suchen Sie nach DOM-Objekten (Document Object Model, Dokumentobjektmodell) oder -Eigenschaften, die dem Feature zugeordnet sind.
  • Versuchen Sie, ein Objekt oder Attribut zu erstellen, das im Zusammenhang mit dem Feature steht.
  • Ermitteln Sie mit der hasFeature-Methode, ob die DOM-Implementierung das Feature unterstützt.

Weitere Informationen finden Sie unter So wird's gemacht: Erstellen effektiver Fallbackstrategien.

Erkennen von DOM-Objekten und Eigenschaften

Die gängigste Methode zur Erkennung von Features besteht darin, das DOM für Objekte oder Eigenschaften zu untersuchen, die mit dem zu verwendenden Feature verknüpft sind. Der folgende Code zeigt beispielsweise., wie Sie ermitteln, ob der Browser die addEventListener-Methode für die Definition eines Ereignishandlers unterstützt.


function registerEvent( sTargetID, sEventName, fnHandler ) 
{
   var oTarget = document.getElementById( sTargetID );
   if ( oTarget != null ) 
   {
      if ( oTarget.addEventListener ) {   
         oTarget.addEventListener( sEventName, fnToBeRun, false );
      } else {
        var sOnEvent = "on" + sEventName; 
        if ( oTarget.attachEvent ) 
        {
           oTarget.attachEvent( sOnEvent, fnHandler );
        }
      }
   }
}

In diesem Beispiel überprüft der Ereignisregistrierungscode zuerst, ob das Objekt, das das Ereignis behandelt, die addEventListener-Methode unterstützt. Erst danach wird die Methode für die Registrierung des Ereignishandlers aufgerufen. Damit vermeiden Sie Laufzeit-Syntaxfehler und erhalten einen alternativen Ansatz (auch Fallbackstrategie genannt), wenn das bevorzugte Verfahren nicht unterstützt wird.

Orientieren Sie sich bei der Bestimmung von Objekten, Eigenschaften, Attributen oder Methoden, die Ihnen bei der Erkennung eines Features helfen können, an der Spezifikation, die das gewünschte Feature definiert.

Beispielsweise unterstützt Internet Explorer 9 das performance-Objekt der Navigationstiming-Spezifikation. Zum Zeitpunkt der Erstellung dieses Themas definiert diese Spezifikation das "window.performance"-Attribut. Daher können Sie anhand des Vorhandenseins einer performance-Eigenschaft für das window-Objekt ermitteln, ob der aktuelle Webbrowser die Navigationstiming-Spezifikation unterstützt (siehe folgendes Codebeispiel).


if ( window.performance ) {
   showLoadTimes( window.performance );
}

In diesem Beispiel wird die showLoadTimes()-Funktion nur aufgerufen, wenn das window-Objekt eine performance-Eigenschaft unterstützt.

Erstellen von Objekten zur Unterstützung von Features

Einige Features können erst im DOM erkannt werden, wenn sie vom Browser gerendert werden. Beispielsweise unterstützt Internet Explorer 9 das audio-Element nur, wenn eine Webseite im IE9-Standards-Modus angezeigt wird. Wenn eine Webseite, die ein audio-Element enthält, im IE5-Modus (Quirksmodus) angezeigt wird (oder in einer früheren Version von Internet Explorer angezeigt wird), wird das audio-Element als unbekanntes (generisches) Element gerendert.

Aufbauend auf dem vorherigen Abschnitt kann unter Umständen bereits mithilfe des folgenden Beispielcodes ermittelt werden, ob ein Browser das audio-Element unterstützt.


<!doctype html>
<head>
<title>Simple Audio Support Test</title>

<script type="text/javascript">

   function supportsAudio() 
   {
     var d = document;
     var o = d.getElementById( "audio1" );
     return ( o != null ); 
   }

   function checkAudioSupport() 
   {
      var s = ( supportsAudio() == true ) ? 
              "supports " : "does not support ";
      var o = document.getElementById( "dOutput" );
      o.outerText = "Your browser " + s + "the audio element.";
   }

</script>

</head>
<body>
   <audio id="audio1" src="audiofile.mp3" />

    <button onclick="checkAudioSupport();">
        Click to test audio support.
    </button>
    <br />
    <div id="dOutput">Please click a button</div>

</body>
</html>

Dieser Code versucht, ein audio-Element zu erstellen, und basiert seine Analyse der Featureunterstützung darauf, ob das Objekt erstellt wurde. Dieses Beispiel weist beim Anzeigen der Seite im IE9-Modus richtigerweise daraufhin, dass Internet Explorer 9 das audio-Element unterstützt. Allerdings stellt das Beispiel die gleiche Behauptung auf, wenn die Webseite im IE5-Modus angezeigt wird. Die supportsAudio()-Funktion nimmt an, dass die Möglichkeit, einen Verweis auf ein von einem audio-Element erstelltes Objekt abzurufen, tatsächlich ein audio-Element mit Unterstützung für Musikwiedergabe darstellt. Dies ist ein Problem, weil von Webbrowsern erwartet wird, dass sie generische Verweise auf von ihnen nicht unterstützte HTML-Elemente erstellen.


   function supportsAudio() 
   {
     var o = document.createElement( 'audio' );
     return ( o.canPlayType ); 
   }

Außerdem muss in diesem Beispiel die Webseite kein audio-Element enthalten, damit die Unterstützung für das audio-Element ermittelt werden kann.

Wenn das DOM kein integriertes DOM-Objekt bzw. keine DOM-Eigenschaft für das zu erkennende Feature enthält, verwenden Sie createElement oder eine ähnliche Methode, um ein temporäres Objekt zu erstellen. Überprüfen Sie dann, ob das temporäre Objekt zu dem Objekttyp gehört, der Sie interessiert.

Hinweis  Die besten Ergebnisse erzielen Sie, wenn Sie Annahmen zu Browsern auf verschiedenen Geräten vermeiden. Ein Desktopbrowser unterstützt möglicherweise andere Features als eine mobile Version des gleichen Browsers, die sich wiederum vom gleichen Browser auf einem anderen Gerät unterscheiden kann. Mit der Featureerkennung testen Sie alle Browser auf die benötigten Features.

Suchen nach DOM-Features

Die hasFeature-Methode zeigt Unterstützung für einzelne Spezifikationen oder Gruppen von Features an, die durch eine Spezifikation definiert werden. Der folgende Code zeigt beispielsweise, wie Sie bestimmen, ob ein Browser SVG unterstützt.


bResult = document.implementation.hasFeature("org.w3c.svg", "1.0")

Bestimmte Featurezeichenfolgen werden durch die Spezifikation definiert, die das Feature definiert. Beispielsweise unterstützt die Spezifikation des World Wide Web Consortium (W3C) für Ebene 2 des Dokumentobjektmodells (Document Object Model, DOM) verschiedene Featurezeichenfolgen, die Modulen der Gesamtspezifikation entsprechen.

Beachten Sie dabei, dass die hasFeature-Methode zwar anzeigen kann, ob ein bestimmter Browser ein bestimmtes Feature unterstützt, dass aber durchaus die Möglichkeit besteht, dass der Browser nicht alle Aspekte des Features unterstützt. Nehmen Sie sich im Zweifelsfall die Zeit, die Implementierung eines bestimmten Features in gängigen Browsern zu untersuchen.

Weitere Informationen zum Status einer bestimmten Spezifikation oder einer Gruppe von Features finden Sie in den Ressourcen, die von der Organisation bereitgestellt werden, die die Spezifikation betreut. So enthält beispielsweise die Website des World Wide Web Consortium (W3C) einen Beteiligungsbereich, in dem Ressourcen im Zusammenhang mit der Entwicklung von W3C-Standards beschrieben werden. Dazu gehören öffentliche Diskussionsbereiche, Statusupdates und verwandte Informationen.

Es gibt viele Möglichkeiten, die von einem Webbrowser unterstützten Features zu erkennen. Wenden Sie dabei unbedingt Erkennungsverfahren an, die sich direkt auf das zu verwendende Feature beziehen. Es empfiehlt sich z. B. nicht, die Farbe eines Textfelds zu bestimmen, um die Schriftart zu ermitteln, mit der der Inhalt des Textfelds angezeigt wird. Assoziationen dieser Art ziehen später weitere Probleme nach sich.

 

 

Anzeigen:
© 2014 Microsoft