Gunther: "User-Agent" vom Header oder navigator.userAgent?

Beitrag lesen

Hi!

Diesen Schluss kann man ziehen, ich würde ihn aber nicht aussprechen, weil er vom Grundproblem ablenkt. Es ist meines Erachtens schlicht so, dass da draußen zu viele Browser rumhopsen, als dass ich jeden beim Namen kennen könnte. Wir haben ja nicht nur viereinhalb verschiedene Browserfamilien (IE, Mozilla, Opera, Webkit mit Safari und Chrome, letztere unterscheiden sich im Javascript-Interpreter), die kommen auch noch in hundert verschiedenen Versionen vor.

Wie ich in meiner Antwort an Martin schon erwähnt habe, spreche ich ausdrücklich_nicht_von "Browser-Sniffing" per UA, sondern eher von so etwas wie "Device-Sniffing".

Ich möchte auf meinen bereits erwähnten Fall zurückkommen, nämlich die Erkennung von Smartphones (Mobile Devices) mit deaktiviertem Javascript.

Und wie bereits ebenfalls kurz erwähnt, fände ich es sehr begrüßenswert, wenn im Header solche Angaben bezüglich des Ausgabemediums übertragen würden, anstatt Autoren qusi zu zwingen, auf "unzuverlässige Behelfskrücken" zurückgreifen zu müssen.

Das kann ich nachvollziehen, aber im Grunde zeigt sich in diesem Punkt etwas, worauf schon vor bald 20 Jahren geachtet wurde: HTML war als vom Ausgabemedium möglichst unabhängiges Format angelegt. Dieser Gedanke ging recht schnell den Bach runter, das fing mit der Erkennung der Bildschirmgröße an, dann der Browserkrieg. Und jetzt kommt's mit den Mobilgeräten ganz dicke - insbesondere für jene, die vor ihrem Gaming-23-Zöller sitzen und gnädig auf "1280x1024 optimieren" ;>

Das kann ich jetzt nicht so ganz in den Kontext einordnen ...!?
IMHO gibt es seit Jahren (und das Archiv hier kann meine Aussage belegen) das Problem, dass man für das Styling/Design CSS verwendet, es gleichzeitig aber keine "brauchbare" Möglichkeit gibt, etwas über das jeweilige Ausgabemedium zu erfahren. Und genau darauf kommt es aber an.

Um es mal etwas "überspitzt/ übertrieben" auszudrücken:
Bei manchen Websites ist/sind die zugehörige(n) CSS Datei(en) mittlerweile größer, als der eigentliche Inhalt (wenn man mal von Grafiken und Videos absieht).
Oder wenn ich mich und mein Browsingverhalten mal betrachte: Ich surfe täglich 100 verschiedene Seiten an, drucke aber keine einzige davon aus. So gesehen sind die ganzen Print-Styles für mich reiner "Daten Ballast". Denn wenn ich doch mal eine Seite ausdrucken wollte, könnte ich gut damit leben, wenn dann erst das passende Print-Stylesheet nachgeladen würde.

HTML war als vom Ausgabemedium möglichst unabhängiges Format angelegt

HTML ja, aber CSS nicht. Und in Zeiten zunehmender (verschiedener) Ausgabemedien (Stichwort: Mobile Devices), wo es eben teilweise auch neue Dinge gibt, auf die zu achten ist (wie bspw. Datenvolumen), sehe ich das als zunehmendes Problem ...!

Wie dem auch sei, "unzuverlässig" oder "Behelfskrücken" (oder beides) trifft auf alle Möglichkeiten zu. Ich halte CSS-Mediaqueries für die sicherste Methode, sowohl, was die Funktion angeht als auch die Zukunftssicherheit. Ich erlebe sie zwar selbst als unzuverlässig, aber allemal besser als die Browserweiche, weil schon vom Prinzip her nicht ich entscheiden muss, wie das Ausgabemedium aussieht, sondern sich das Ausgabemedium selbst bewertet und aus meinen Angeboten aussucht.

Auch ich beschäftige mich seit geraumer Zeit mit Media Queries (auch hier kann das Archiv dies wieder bestätigen) und ich finde es toll, dass man mittlerweile dank Transitions & Co. Elemente auch ohne JS animieren kann. Umso unverständlicher ist es mir, dass es aktuell keine Möglichkeit gibt so etwas Elementares, wie ob es sich bspw. um ein Ausgabemedium mit Touchscreen handelt, herauszufinden. Einzig Mozilla hat mit '-moz-touch-enabled' so etwas im Repertoir ...!

Und die unterschiedlichen Implementierungen/ Interpretationen seitens der Browserhersteller konterkarieren einen Großteil der Vorteile von MQ, wobei sie aber das eigentliche Problem (s.o.) in keinster Weise lösen.

Prinzipiell stehe ich aber auf dem Standpunkt, dass die teilweise "fälschliche" Verwendung von irgendwelchen Dingen kein Grund oder Argument dafür oder dagegen sein kann.

Da gebe ich dir recht. Jeder ist für den Mist, den er verbockt, selbst verantwortlich. Browserweichen sind aber nichtsdestotrotz so ein Fall, wo man _sehr_ genau wissen sollte, was man tut. Die Anwendungsfälle, in denen mehr Nutzen als Schaden rauskommt, halte ich für überaus selten.

Das sehe ich im Bezug auf "Browserweichen" genauso. Nur wie bereits gesagt, davon sprach und spreche ich nicht. ;-)
Wobei ich ehrlich gesagt auch nicht zwingend einen Nachteil darin sehen würde, wenn es eine verlässliche Methode zur Browserindentifizierung geben würde ...!

Gruß Gunther