peterS.: browser-erkennung: userAgent versus render engine detection

Beitrag lesen

gruss Cybaer,

...
denn es gibt durchaus situationen, (...) in denen
es wichtig ist, dieses ding genau zu kennen,

Ja, dem stimme ich zu.

Allerdings:

so auch in den untiefen von [HTMLElement.style],

Hier eher nicht.

...
oder frueher fuer die damals noch uneinheitlichen
[style.opacity]-werte wie [style.MozOpacity] oder
[style.KhtmlOpacity].

... hier muß ja gar keine Browserweiche her: Das läßt

sich alles ohne Weiche einsetzen. Die Browser, die
es nicht können, ignorieren es halt einfach (das gilt
sowohl für die filter-Stile auf den Nicht-IEs, als
auch für die div. opacity-Stile auf dem IE).

Und wie gesagt: Eine Browsererkennung aufgrund von CSS,
da grummelt es bei mir. ;-)

da ich eine faule sau bin und beim dom-scripting bisher
in noch keinem fall den exakten *build* eines browsers in
erfahrung bringen musste, da es am ende immer nur darauf
ankam, welches css-feature wie implementiert/unterstuetzt
wurde, gab es bei mir bisher auch kein einziges stueck code
zur browsererkennung.

ueber die jahre betrachtet laesst sich schon feststellen,
dass die css-(un)faehigkeiten der browser eine sehr grosse
stabilitaet besitzen und auch in die jeweils ueberarbeiteten/
neueren versionen uebernommen werden.

das ist der einzig wahre grund fuer meine interpretation von
*browser detection*.

  • Für IE nehme ich Conditional Compilation. ...

wollte ich nicht.

... IIRC beherrscht
der IE/Mac keine Behaviors, würde also von deiner Erkennung
nicht erfaßt. Bei CC wird er nicht nur erfaßt, man kann ihn
auch einfach separieren.

ich muss zugeben, dass ich dieses teil komplett ignoriere und
schon css-maessig (/* \*/ und /* */) aussen vorlasse, was der
dann mit den scripten anfaengt ist mir schlichtweg egal.

  • Für Opera ist die Abfrage einfach: window.opera (wird offiziell empfohlen)

ich hatte schon scripte von *boesen dritten* mit: "window.opera = true;"

  • Konquerors haben bei navigator.vendor ein "KDE" (da dies die
    offizielle Erkennungsmöglichkeit für "getarnte" Konquerors ist,
    wird sich das wohl auch nicht ändern, wenn auf die Webkit-Engine
    umgestellt wird)
  • Geckos haben bei navigator.product ein "Gecko". Apples WebKit
    tarnt sich hier ebenfalls als Gecko-Engine, hat aber als
    navigator.vendor ein "Apple Computer, Inc.". Außerdem kann man
    auch noch in navigator.appName nach "AppleWebKit" suchen (Konqueror
    hat hier ein schlichtes "Konqueror" - jedenfalls mom. noch).

ja ich weiss, ...

Jetzt würden mich deine Argumente interessieren, ob und wenn
ja warum Du deine Abfrage für sinnvoller/sicherer hältst ...

... und ich halte das nicht fuer sinnvoller, sondern nur fuer
langfristig sicher genug hinsichtlich der von mir benoetigten
hinreichenden genauigkeit.

denn wie ich im einzelfall an exakte informationen komme, weiss
ich ja. der schwenk auf die methoden ermoeglicht in den weitaus
meisten faellen eben nur eine vereinheitlichung des codes mit
der option, dass dieser zentral gewartet und jederzeit angepasst
werden kann, falls dessen bisherige umsetzung dann doch an grenzen
stossen sollte.

tut mir leid Cybaer, mehr als diese duennen argumente hab' ich
in diesm fall wirklich nicht zu bieten. soll ich jetzt wirklich
alles nochmal ueber den haufen werfen?

so long - gruebelnd ... peterS. - pseliger@gmx.net

--
»Because objects in JavaScript are so flexible, you will want to think differently about class hierarchies.
Deep hierarchies are inappropriate. Shallow hierarchies are efficient and expressive.« - Douglas Crockford
ie:( fl:) br:> va:( ls:& fo:) rl:| n3;} n4:} ss:} de:µ js:} mo:? zu:]