Und hier ist warum
Es widerspricht dem Geist der Webstandards
Der eigentliche Grund, warum Webstandards existieren, ist, dass wir keinen spezifischen Code für spezifische Umgebungen schreiben müssen. Wir sollten Code schreiben, der etablierte Standards einhält, und die Software, die für die Anzeige unseres Codes zuständig ist, sollte ihn so anzeigen, wie es die Standards vorschreiben.
Es stützt sich auf den User-Agent-String des Browsers
...was eine köstlich-desaströse Geschichte hat und leicht zu fälschen ist.
Es kann Geräte behindern
Beispiel: Sie erkennen das iPhone und liefern spezielle Inhalte aus. Nun kann das iPhone die Webseite nie so sehen, wie andere Browser sie sehen, obwohl es dazu vollkommen fähig wäre.
Warum tun wir es dann?
Wir tun es, weil verschiedene Browser Dinge unterschiedlich handhaben und Browsererkennung uns aus der Patsche helfen und Dinge so funktionieren lassen kann, wie sie sollten. Man kann uns das kaum verdenken, oder?
Oft sind die Situationen, die uns dazu bringen, auf Browsererkennung zurückzugreifen, wutentbrannt. Aber denken Sie daran, dass oft nicht der Browser schuld ist. Selbst im Fall von IE 6 war er zum Zeitpunkt seiner Veröffentlichung der standardkonformste und fortschrittlichste Browser. Und einige der Standards, die wir heute haben, waren zu dieser Zeit noch nicht vollständig.
Was sollten wir stattdessen tun?
Ich bin die Erste, die zugibt, dass das reale Webdesign manchmal schnelle Lösungen, budgetgerechte Lösungen und das Sicherstellen, dass Funktionen wie beabsichtigt funktionieren, erfordert. Das erlaubt nicht immer altruistische Entscheidungen, die auf einige Funktionalitäten verzichten, weil es das "Richtige" ist.
Idealerweise...
...würden wir **Funktionsprüfungen** durchführen. Das sind die Informationen, die wir wirklich brauchen, oder? Testen, ob die Umgebung, in der wir uns befinden, zu dem fähig ist, was wir tun wollen. Wenn ja, tun wir es. Leichter gesagt als getan, da bin ich mir sicher, und ich selbst wüsste kaum, wo ich anfangen sollte. Aber ich bin mir sicher, einige von euch sind sehr kluge Leute und können das schaffen (oder tun es bereits!)
Mehr
Hier ist ein bisschen über Funktionsprüfung von Quirksmode. Und hier ist Dave Shea mit einem guten Beispiel dafür, warum Browsererkennung nicht gut ist.
Chris,
Sind Sie für oder gegen Browsererkennung zur Auslieferung verschiedener Stylesheets?
Zum Beispiel: Ich verwende derzeit einen HTC Wizard (O2 Xda Mini II S) und einige Websites (selbst solche mit einem mobilen Stylesheet) sehen miserabel aus aufgrund von skalierten Grafiken, festen Größen, die zu breit für den Bildschirm sind usw.
Ich würde persönlich lieber den UA von Mobilgeräten erkennen und ein anderes Stylesheet für Mobiltelefone mit großen Bildschirmen (Win Mobile-Geräte, LG Viewty) und kleineren Bildschirmen (Sony Erricsson C905) bereitstellen.
Nur meine 2 Cents
Chris
Ich verwende keine Browsererkennung dafür, sondern Bildschirmbreiten-Erkennung. Ich beginne mit dem Stylesheet, das für einen schmalen Bildschirm geeignet ist, und verwende dann JS, um die Breite zu erkennen und das Stylesheet zu ändern, falls erforderlich.
Warum verwenden Sie dann
<!--[if IE 6]>...<![endif]-->und<!--[if IE 7]>...<![endif]-->?Ich würde lieber
ha!
:)
Ja, das ist viel besser. Aber da wir die Dinge nicht so machen können, ist Browsererkennung der einzige Ausweg.
Rechtsklick, Quelltext anzeigen
Bedingte Kommentare werden nur von IE ausgeführt, alle anderen Browser behandeln sie wie jeden anderen Kommentar. Sie implizieren also schon durch die Verwendung von IE. Auf diese Weise sind sie auch eine implizite Funktionsprüfung: Beachten Sie, dass sie in einem Kommentar-Tag verschachtelt sind. Dies ähnelt (aber nicht genau) dem Satz
Wenn wir normalerweise Funktionsprüfungen durchführen, gibt es einige Techniken, die unbeabsichtigt den Browser identifizieren **können**, wie z. B. das Prüfen auf Event-Listener. Hier nutzen wir lediglich die Tatsache aus, dass wenn diese Bedingung ausgeführt wird, der Browser IE ist. Die von Chris beschriebene Browsererkennung erfolgt mit JavaScript und der Verwendung von integrierten Methoden, die für die tatsächliche Erkennung der Client-Identität unzureichend sind. Und diese Methoden erfordern, dass zukünftige Änderungen im Browser eine vollständige Neufassung des Codes bedeuten. Funktionsprüfungen ermöglichen zukünftige Standardkonformität in einem Browser, der heute noch nicht dazu fähig ist. Mit bedingten Kommentaren können wir auch ganz einfach einen Link zu einer CSS-Datei oder einer JS-Datei oder was auch immer ersetzen. Sie haben also einen Punkt, dass CCs einen Browser erkennen, aber ihre Verwendung ist ein viel geringeres Übel als die Verwendung traditioneller Browser-Erkennungsmethoden.
Der Titel des Beitrags ist zu großzügig. Sie können Browsererkennung verwenden, um die Interaktion der Benutzer mit Ihrer Website zu verbessern.
Einfaches Beispiel. Wenn ich auf der Seite ein Datei-Upload-Feld habe, wäre es für den Benutzer toll zu wissen, dass er Dateien per Drag & Drop auf das Feld ziehen kann. Aber das ist nur eine Funktion von Chrome und Safari. Also muss ich Browsererkennung oder browserspezifische CSS-Hacks verwenden.
Genau darum geht es, wäre es nicht besser zu erkennen, **ob der Browser für Drag & Drop fähig ist**, anstatt für den Browser selbst? So sind Sie gut aufgestellt, wenn ein neuer Browser herauskommt, der es unterstützt.
Ich stimme dem Titel des Beitrags nicht wirklich zu, aber ich verstehe Chris' Punkt. Browsererkennung und die Manipulation eines User-Agent-Strings haben durchaus ihre Vorteile, z. B. das Erkennen von Cloaking und anderen schädlichen Internetaktivitäten. :)
User-Agent-Erkennung ist schlecht. Funktionsbasierte Erkennung ist gut.
Das fasst es ziemlich gut zusammen, David. Ich stimme vollkommen zu.
Gut gesagt! Ich denke, so sollte der Titel lauten :)
Das sollte wirklich der Titel des Beitrags sein!
Ich denke auch, dass ich den Punkt verstehe, aber im Moment möchte ich immer noch, dass einige Websites mir diese optimierte mobile Website zur Verfügung stellen, wenn sie verfügbar ist. Vielleicht macht eine Website wie Twitter es richtig, wenn sie standardmäßig die mobile Website für Handys anbietet, aber die Option für die Standardansicht anbietet… Besser noch, eine Website könnte eine Benutzereinstellung speichern und jedem geben, was er möchte.
Ich denke, ich verstehe, was Sie sagen wollen, und stimme Ihnen größtenteils zu. Ich glaube jedoch, dass das Internet dazu da ist, Informationen bestmöglich zugänglich zu machen. Ich glaube, dass die richtige Lösung für ein Gerät nicht unbedingt die richtige Lösung für ein anderes Gerät ist. Zum Beispiel iPhone vs. ein Breitbildmonitor. Eine Website, die dies tut, ist Amazon. Wenn Sie die Website zum ersten Mal auf dem iPhone aufrufen, gelangen Sie zur iPhone-Seite mit der Option, zur "PC"-Seite zu wechseln. Ich glaube also, dass eine Funktionsprüfung eine großartige Lösung ist, ebenso wie die Geräteerkennung. Das ist aber nur meine bescheidene Meinung.
...ist schlecht und unvermeidlich (wie das Schicksal). Danke, Microsoft!
Kann schlecht sein, aber manchmal ist es nötig.
Wo kann ich IE6 herunterladen, um eine Website zu testen?
Wenn Sie unter Windows sind, verwenden Sie IETester: http://www.my-debugbar.com/wiki/IETester/HomePage
Aus irgendeinem Grund lieferte mir IE Tester nicht die entsprechenden IE6-Ergebnisse. Daher verwende ich IE6-Standalone zusammen mit IE7 unter Windows XP. Hier ist der Link für Standalone IE6 http://tredosoft.com/Multiple_IE
Meine jüngste Erfahrung mit dem Blackberry Browser ändert meine Einstellung zur Browsererkennung
http://supportforums.blackberry.com/rim/board/message?board.id=browser_dev&thread.id=817
Manchmal muss man einfach wissen, wann man es mit einem kaputten Stück Software zu tun hat.
Was denkst du über browserspezifisches CSS? Im Laufe der Wartung scheint es ein notwendiges Übel zu sein.
Ich halte es für ein notwendiges Übel. CSS ist nicht wirklich in der Lage, Browser zu erkennen oder Funktionen zu testen, daher ist es ziemlich unsere einzige Option.
Ich glaube, ich spreche mehr über JavaScript-Erkennung (oder andere Mittel, die den User-Agent-String erkennen und etwas damit tun können) und Weiterleitungen oder das Ausliefern spezieller Inhalte oder Ähnliches.
In Bezug auf JS-User-Agent-Erkennung und das Ausliefern von „speziellen Inhalten“ möchte ich Ihnen eine Situation vorschlagen…
Angenommen, Sie wären ein großes Unternehmen und ein Vorreiter bei der Weiterentwicklung von Standards und der Webentwicklung. Vielleicht ein Unternehmen wie, ich weiß nicht, Google oder so ähnlich;P
Und nehmen wir an, Sie wollten Ihren Teil dazu beitragen, die Benutzer zu ermutigen, IE6 zugunsten von FF, Chrome oder WebKit zu verlassen.
Wie genau schlagen Sie die Entscheidung vor, die Benachrichtigung „Upgrade für besseren Service“ anzuzeigen, wenn nicht durch Browsererkennung?
Dies ist nur eine einfache Situation, aber Sie verstehen den Punkt. Oh, und es ist auch wahr.
Andererseits ist Google ganz für Tabellenlayouts, verwendet keine DOCTYPE-Deklarationen und verwendet veraltete Tags wie
<center>.Ich schätze, die Regel lautet: Wenn Sie alle auf jedem Computer erreichen wollen (insbesondere auf alten mit alten Browsern), verwenden Sie alte Markup-Sprache. Designen Sie, als wäre es ’97 wieder...Chris, ich muss Ihnen hier respektvoll widersprechen. Oft wird die „Funktionsprüfung“ genau über die „Browsererkennung“ durchgeführt.
Ich sage, Sie sollten immer den gleichen (X)HTML-Inhalt ausliefern, unabhängig vom Zugriffsgerät. Die Website sollte zumindest in Lynx nutzbar sein.
Die Entscheidung bezüglich CSS (der Darstellungsschicht) sollte absolut vom Browser abhängen. Nehmen wir Ihr Beispiel: iPhone. Obwohl Sie die gleiche Webseite mit dem iPhone aufrufen **können**, ist die Möglichkeit, eine Benutzeroberfläche anzubieten, die auf das Gerät zugeschnitten ist, für Power-User von Mobiltelefonen sicherlich sehr geschätzt. Navigation fällt mir hier ein. Große Finger + kleine Bildschirme = schwer zu navigieren, auch wenn das Gerät des Benutzers „echte“ Webseiten anzeigen „kann“.
Auch in Bezug auf bedingte Stile, à la IE6, ist nichts falsch an einer kleinen Anpassung hier und da. Ich würde keineswegs so weit gehen zu sagen, dass die Leute auf IE6 „ eingehen“ sollten. Aber Sie müssen wirklich über progressive Enhancement nachdenken, und manchmal kann man die Fähigkeiten nicht wirklich „erkennen“, ohne zuerst den Browser zu erkennen.
Dann gibt es natürlich noch Ihre Verhaltensschicht. Obwohl wir mit AJAX-Frameworks wie Prototype, jQuery und ähnlichem bereits die Unterschiede zwischen IE und, nun ja, allem anderen mit den Remote-Aufrufen abstrahieren. Diese Funktionsprüfung mit reinem JS ist meist recht einfach: Sie ist entweder aktiviert oder nicht.
Allerdings werden sehr, sehr umfangreiche clientseitige Verarbeitungen auf mobiler Seite wieder leiden. Wenn Sie wissen, dass Ihr Benutzer einen mobilen Browser und damit ein sehr leistungsschwaches mobiles Gerät hat, möchten Sie wahrscheinlich nicht viel Verarbeitung vom Server zum Client auslagern. Das iPhone ist ziemlich leistungsfähig, aber wie alle anderen Smartphones leidet es im Prozessor- und Speicherbereich recht stark.
Ich verstehe, was Sie sagen wollen; es wirkt jedoch in der Theorie ziemlich streng, aber in der Praxis nicht vorteilhaft. Wie ein anderer Poster erwähnte, verwenden Sie selbst Browsererkennung für IE-Probleme ;P
Die erste JavaScript-Bibliothek, die Browser-Sniffing entfernt, ist jQuery in 1.3.
Eine lustige Geschichte ist, dass es auf The Ajax Experience ein Panel gab, bei dem John Resig ausgelacht wurde, weil er erwähnte, Browser-Sniffing abzuschaffen. Sie sagten, es sei unmöglich, aber er hat es tatsächlich getan!
Ich kann nicht zustimmen!
Also sollte eine Person mit Firefox zu Hause genau die gleiche Webseite für die New York Times erhalten wie jemand auf einem Blackberry? Die Bildschirme sind komplett unterschiedlich groß. JavaScript-Unterstützung auf einem BB ist lückenhaft.
Ich bin mir ziemlich sicher, dass dies nicht das ist, was Chris vorschlägt, und warum Sie anstelle von Browsererkennung Funktionsprüfungen durchführen sollten. Eines der Dinge, die man erkennen muss, ist die Fenstergröße, nehmen Sie an, Ihr Benutzer wird den kleinsten, schlechtesten Browser aller Zeiten verwenden und sich von dort aus hocharbeiten. Durch die Verwendung von JavaScript können Sie mehr oder weniger bestimmen, wie gut der Browser/die Anzeige des Benutzers ist, und die Website dazu bringen, das Stylesheet entsprechend zu ändern.
Vorausgesetzt natürlich, dass Sie JS verwenden **können**, um diese Dinge zu erkennen.
In dem kleinen Prozentsatz der Fälle, in denen ein Benutzer JS deaktiviert hat, ist der User-Agent-String auf Serverseite die nächstbeste Option.
Und in dem noch kleineren Fall, dass der Benutzer JS deaktiviert hat und seinen User-Agent fälscht... nun, dann mögen die Würfel fallen, nehme ich an. Stellen Sie einfach sicher, dass alle Inhalte zugänglich sind und die gesamte Website im Grunde ohne JS, ohne CSS und ohne Bilder funktioniert.
Wenn Sie von Erkennung mit Javascript sprechen, stelle ich mir vor, dass die meisten Frameworks Funktionsprüfungen verwenden. Zum Beispiel ermittelt Mootools die Browser-Engine. Beispiel zur Erkennung von Trident (Internet Explorer)
return (!window.ActiveXObject) ? false : ((window.XMLHttpRequest) ? 5 : 4);
setzt Browser.Engine.trident auf trident4/trident5, wenn es sich um IE handelt.
Aber es fühlt sich so gut an, den Leuten auf IE zu sagen, dass ihr Browser schlecht ist...
Sicher, ich bin dagegen, den Leuten mit einem schlechten Browser den Zugang zu verweigern, aber trotzdem kann ich es ihnen diskret sagen...
Auf meiner Website (http://www.loriskumo.com) habe ich ein kleines Bild oben rechts verwendet, um meine Besucher einzuladen, stattdessen Firefox statt IE zu aktivieren. Aber wenn sie es nicht wollen, können sie sie trotzdem besuchen.
Es ist, was ich meinen kleinen Kampf gegen IE nenne...
Guter Beitrag… Browser zu erkennen ist eine Qual!
jQuery verwendet keine Browser-Sniffing mehr, sie verwenden Funktionserkennung, wie Chris erwähnt hat, um Kopfschmerzen und Probleme in der Zukunft zu vermeiden. Entschuldigung, falls jemand das erwähnt hat, aber ich habe es nicht gesehen.
Bei handsetdetection.com verwenden wir den User-Agent plus andere Header, um Fähigkeiten auf Mobiltelefonen/Handys bereitzustellen.
Ich widerspreche Ihrer Behauptung, dass spezielle Inhalte böse sind.
Wenn ein Kunde eine für iPhone optimierte Erfahrung wünscht, warum sollte man sie ihm nicht geben? Sicher, das iPhone kann normale Inhalte anzeigen, aber warum die Erfahrung nicht anpassen, wenn man weiß, dass es ein iPhone ist?
Ich denke, wenn Sie die Browsererkennung verwenden, um zu erkennen, ob der Benutzer einen PC oder ein iPhone verwendet, ist das in Ordnung. Wahrscheinlich kann man es so sehen, dass es nur als Methode zur Erkennung des verwendeten Geräts oder der Maschine dient und der Browser nicht das Wichtigste daran ist.
Ich denke, Browsererkennung für das iPhone ist gut. Ich werde bald eine vollständige Flash-Website haben – niemals – also möchte ich dies als Backup haben… aber was weiß ich… ich bin sowieso schlecht darin.
aber IE6 ist mir einfach zu schlecht. Ich bin neu in der Designwelt.. IE6 ist nicht meine Ära, könnte ich sagen.. ich verwende nichts, um Probleme mit IE-Sachen zu lösen.. lasse es einfach so.. vielleicht ist es nicht gut.. aber zumindest ist das eine Aussage: „Benutzen Sie keinen IE“.
Ich stimme zu, dass Browsererkennung schlecht ist. Und ich wollte nur dieses Beispiel für eine schrecklich schiefgelaufene Browsererkennung teilen. Die Version der Ubiquity-Erweiterung wird als Version von Firefox behandelt: http://flickr.com/photos/spiri/3274163228/
Ich verstehe Feature-Erkennung nicht vollständig.
Die meiste Browsererkennungsfunktion in meinen Skripten dient dazu, sehr obskure Browser-Bugs zu umgehen und ist normalerweise nur für einen einzelnen Browser gleichzeitig.
Ich bezweifle, dass Bibliotheken all diese kleinen Browser-Bugs erkennen und sie dann als Features markieren, die ich überprüfen kann. Was ist, wenn mehrere Browser eine Funktion implementiert haben, aber einer in einigen Bereichen fehlerhaft ist und ich anders damit arbeiten muss?
Was ich sehe, ist, dass ich am Ende mehrere Features greifen und testen muss, um einen bestimmten Browser ansprechen und den Bug beheben zu können. Am Ende wird es immer noch Browsererkennung sein, aber ein umständlicher Weg, sie durch die Betrachtung von Features zu ermitteln, um festzustellen, mit welchem Browser ich es zu tun habe.
Ich sehe, wie es uns davon abhält, uns auf User-Agent-Strings zu verlassen, um Browser zu erkennen. So oder so werde ich immer noch eine Möglichkeit zur Browser- und Versionserkennung haben wollen, egal ob sie durch die Erkennung von User-Agent-Strings oder durch Funktionserkennung erfolgt.
Ich würde gerne sehen, wie Bibliotheken Browsererkennungsfunktionen beibehalten, sie aber auf Funktionserkennung basieren. Geben Sie uns eine genauere Browsererkennung und lassen Sie uns sie oder Funktionserkennung verwenden, je nachdem, was für uns am besten funktioniert.
Ich weiß, dass dies ein alter Thread ist, aber er erscheint immer noch weit oben in Google.
Die Schriftartdarstellung in Firefox ist dichter als in Chrome oder Safari für einige Serifenschriften. Das Anpassen der CSS-Letterspacing-Eigenschaft speziell für Firefox macht einen großen Unterschied für die Lesbarkeit.
Browsererkennung ist in diesem Fall nützlich, es sei denn, jemand kann eine bessere Methode vorschlagen?