Beispiel für notwendige Browserweiche gesucht
molily
0 0 0 0 molily
0
0 0 0 
Struppi
0 »RegExp.prototype.compile« hat unter 2er Safaries *gelogen*
0
Beispiel für notwendige Browserweiche gesucht
molily
Hallo Leute,
ich suche für SELFHTML 9 ein JavaScript-Beispiel für einen Fall, in dem eine echte, »böse« Browsererkennung nötig ist, weil alle anderen üblichen Methoden der Objektabfragen nicht greifen.
Dummerweise fällt mir keines verbreitetes Problem ein, das man nur mithilfe von navigator-Abfragen und Co. umgehen kann. Sicher haben irgendwelche speziellen Versionen irgendwelche speziellen Problemchen, aber die sind mir zu besonders und kurzlebig, als dass sie als einleuchtende Beispiele gelten können. Wenn ich z.B. in jQuery suche, finden sich natürlich im Detail tausende Browserabfragen, aber die wenigsten davon scheinen mir häufige Probleme, in die ein gewöhnlicher JavaScript-Entwickler geraten würde.
Was mir einfallen würde ist Elemente erzeugen mit name-Attribut, diese Geschichte hier. Andererseits sind navigator-Abfragen bei solchen IE-Problemen nicht einmal nötig, da es Conditional Compilation gibt. Die will ich auch vorstellen, aber es gibts nicht einen halbwegs verbreiteten, »beispielhaften« Anwendungsfall, wo selbst die nicht greifen?
Mathias
-
Hallo,
Für Opera schonmal
window.opera...mfg, Flo
--
Developers are dying. Computers are getting trash. CEO's become forgetten. The only remaining things are ideas, lies and crises. So if you want to be immortal, first think, than stop it and go to microsoft and become later a manager at Lehman Brothers...
sh:) fo:| ch:? rl:( br:^ n4:| ie:{ mo:| va:} de:> zu:} fl:{ ss:) ls:< js:|
*Zu dem de:> Ich benutze wegen IE im moment noch tabellen, weil dieser display:table noch nicht versteht. Ich werde aber, wenn IE 6 & IE 7 < 10% mein neues CSS-Layout einspielen...-
Für Opera schonmal
window.opera...Ich will aber nicht wissen, wie ich den ein oder anderen Browser erkennen kann, sondern in welchem (einschlägigen) Fall ich unbedingt eine Browsererkennung brauche.
Mathias
-
Hallo,
Sorry, Thread falsch verstanden :)
mfg, Flo
--
Developers are dying. Computers are getting trash. CEO's become forgetten. The only remaining things are ideas, lies and crises. So if you want to be immortal, first think, than stop it and go to microsoft and become later a manager at Lehman Brothers...
sh:) fo:| ch:? rl:( br:^ n4:| ie:{ mo:| va:} de:> zu:} fl:{ ss:) ls:< js:|
*Zu dem de:> Ich benutze wegen IE im moment noch tabellen, weil dieser display:table noch nicht versteht. Ich werde aber, wenn IE 6 & IE 7 < 10% mein neues CSS-Layout einspielen... -
Für Opera schonmal
window.opera...Ich will aber nicht wissen, wie ich den ein oder anderen Browser erkennen kann, sondern in welchem (einschlägigen) Fall ich unbedingt eine Browsererkennung brauche.
Opera hat des Öfteren Probleme mit fix (oder absolut?) positionierten Elementen, deren
top-undbottom-Eigenschaft einen Wert abweichend vonautobesitzt. Die Höhe des Elements wird bei ausschließlicher Veränderung der Viewporthöhe unter Umständen[1] nicht angepasst.
Natürlich könnte dieses Problem in zukünftigen Opera-Versionen komplett beseitigt sein; ich weiß daher nicht, wie sinnvoll dieses Beispiel wäre.[1] unter welchen Umständen gölte es noch testen. Neuere Operas sind da m.E. etwas besser geworden, haben aber immer noch Probleme.
Gruß,
Nerog-
Opera hat des Öfteren Probleme mit fix (oder absolut?) positionierten Elementen, deren
top-undbottom-Eigenschaft einen Wert abweichend vonautobesitzt. Die Höhe des Elements wird bei ausschließlicher Veränderung der Viewporthöhe unter Umständen[1] nicht angepasst.Hättest du da vielleicht einen Testcase, der den Fehler reproduziert?
Und wie kann man den Fehler mittels JavaScript umgehen?Mathias
-
Hi,
Opera hat des Öfteren Probleme mit fix (oder absolut?) positionierten Elementen, deren
top-undbottom-Eigenschaft einen Wert abweichend vonautobesitzt. Die Höhe des Elements wird bei ausschließlicher Veränderung der Viewporthöhe unter Umständen[1] nicht angepasst.Hättest du da vielleicht einen Testcase, der den Fehler reproduziert?
Ich hab nochmal nachgesehen, ob ich diese problematischen Konstellationen wiederfinde und habe nochmal getestet. Viele Probleme scheinen im neusten Opera behoben zu sein – unter anderm das
top/bottom-Problem (jedenfalls in einfachen Zusammenhängen).Trotzdem habe ich hier mal einen Fall ans Ende meines Postings gehängt, bei dem Opera (Windows) die Höhe nicht richtig anpasst, wenn man das Browserfenster ausschließlich in der Höhe verändert (es also beispielsweise mit der Maus nur am oberen/unteren Fensterrahmen „anfasst“).
Und wie kann man den Fehler mittels JavaScript umgehen?
Im
onresize-Event-Handler lässt sich per JavaScript die Höhe des Elements berechnen und diese manuell setzen. Eventuell würde auch eine leichte Veränderung irgendeiner CSS-Eigenschaft den Browser zwingen neu (und richtig) zu rendern.Gruß,
NerogPS: Testcase:
<?xml version="1.0" encoding="utf-8"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="de" lang="de"> <head> <title>Testcase</title> <style type="text/css"> [code lang=css] @media screen, projection { html { display:table; height:100%; width:100%; } body { display:table-cell; height:100%; border:1px solid red; } }</style>
</head>
<body>
</body>
</html>
[/code]
-
-
-
-
-
Hi Mathias,
ich suche für SELFHTML 9 ein JavaScript-Beispiel für einen Fall, in dem eine echte, »böse« Browsererkennung nötig ist, weil alle anderen üblichen Methoden der Objektabfragen nicht greifen.
Denk doch mal an Konstrukte, die im IE7 oder FF über Css und hover gelöst werden können, im IE6 jedoch Javascript benötigen, weil der nur a-tags hovern kann, beispielsweise eine aus Listen aufgebaute Navi. Hier lässt sich im IE6 dann über Javascript ein Klassenwechsel machen, der das hovern nachbildet.
Gruesse, Joachim
--
Am Ende wird alles gut.-
Hi,
Denk doch mal an Konstrukte, die im IE7 oder FF über Css und hover gelöst werden können, im IE6 jedoch Javascript benötigen
sowas löse ich über MS conditional comment, da andere Browser solch ein Script gar nicht erst laden sollten...
freundliche Grüße
Ingo-
Hi Ingo,
sowas löse ich über MS conditional comment, da andere Browser solch ein Script gar nicht erst laden sollten...
hm, das ist mir persönlich zu "unhandlich", vor allem, da ich sowieso Javascripts eingebunden habe. Und solche Spezialhilfen sind in der Regel nur wenige zeilen...
Davon abgesehen helfen conditionals eben nur bei IE. Safari 2 wollt einmal partout die Seitenhöhe nicht korrekt darstellen, wenn html-Elemente ein/ausgeblendet wurden. Letztlich habe ich ihm dann auch eine kleine js-Hilfe verpasst - natürlich mit entsprechender Browserweiche. Gefiel mir besser als fragwürdige Css-Hacks oder noch fragwürdigere html-Strukturen.
Gruesse, Joachim
--
Am Ende wird alles gut.
-
-
-
Hallo,
[style].opacity = x;
[style].filter = 'Alpha(opacity='+x+')';mfg, Flo
--
Developers are dying. Computers are getting trash. CEO's become forgetten. The only remaining things are ideas, lies and crises. So if you want to be immortal, first think, than stop it and go to microsoft and become later a manager at Lehman Brothers...
sh:) fo:| ch:? rl:( br:^ n4:| ie:{ mo:| va:} de:> zu:} fl:{ ss:) ls:< js:|
*Zu dem de:> Ich benutze wegen IE im moment noch tabellen, weil dieser display:table noch nicht versteht. Ich werde aber, wenn IE 6 & IE 7 < 10% mein neues CSS-Layout einspielen...-
[style].opacity = x;
[style].filter = 'Alpha(opacity='+x+')';Vielleicht habe ich mich missverständlich ausgedrückt. Mit einer Browserweiche meine ich nicht einfach browserübergreifende Programmierung bzw. die Berücksichtigung mehrere Lösungswege. Ich suche vielmehr Code, bei dem eine Erkennung des Browsers (z.B. über navigator.userAgent) nötig ist, um dann etwas zu tun, was nicht mit Existenzabfragen von Objekten sicher gelöst werden kann.
Das obige bezeichne ich nicht als Browserweiche, aber es ist natürlich ein gutes Beispiel für mehrgleisige Scripte. Fälle wie den obigen gibt es viele, z.B. cssFloat vs. styleFloat. Glücklicherweise sind all diese extrem leicht zu handhaben. Ich setze einfach beide oder lese das aus, was gesetzt ist. Das funktioniert. Und wenn nicht, wenn das eine Exception auslösen würde, kann ich die Eigenschaften ohnehin abfragen.
var st = el.style;
st.cssFloat = st.styleFloat = "none";
var val = st.cssFloat || st.styleFloat;Das wäre so ein klassisches Beispiel, wo eine Browserweiche nicht nötig ist (gut, man könnte hier Conditional Compilation verwenden, schließlich ist es ein reiner IE-Bug).
Mathias
-
Hallo Mathias!
Vielleicht habe ich mich missverständlich ausgedrückt. Mit einer Browserweiche meine ich nicht einfach browserübergreifende Programmierung bzw. die Berücksichtigung mehrere Lösungswege. Ich suche vielmehr Code, bei dem eine Erkennung des Browsers (z.B. über navigator.userAgent) nötig ist, um dann etwas zu tun, was nicht mit Existenzabfragen von Objekten sicher gelöst werden kann.
Als Laie stellt sich mir die Frage, ob es so einen Fall überhaupt geben kann? Denn was sollte sicherer sein, als die Existenzabfrage von Objekten!?
Ich würde mir auch wünschen, dass man zukünftig von der gerade für Anfänger leicht "irreführenden" Bezeichnung "Browsererkennung" abrückt, denn letztlich will man ja gar nicht nach dem Browser unterscheiden, sondern eben genau nach seinen Fähigkeiten. Und das kann ja durchaus jeweils eine Menge mehrerer Browser(versionen) ergeben und nicht nur den Einen, den der aktuelle User gerade verwendet.
Und für die aktuell noch häufig vorkommenden und meist eine Sonderbehandlung notwendig machenden IEs gibt es ja die bereits erwähnten zuverlässigen Methoden der CCs.
Gruß Gunther
-
Lieber Gunther,
Als Laie stellt sich mir die Frage, ob es so einen Fall überhaupt geben kann? Denn was sollte sicherer sein, als die Existenzabfrage von Objekten!?
ich stimme Dir in diesem Punkt völlig zu. Meiner Meinung nach wird molily hier kein Glück haben, da ein Fall nach dem von ihm gesuchten Beispiel kaum existieren dürfte.
Liebe Grüße,
Felix Riesterer.
--
ie:% br:> fl:| va:) ls:[ fo:) rl:° n4:? de:> ss:| ch:? js:) mo:} zu:)-
Hi,
Als Laie stellt sich mir die Frage, ob es so einen Fall überhaupt geben kann? Denn was sollte sicherer sein, als die Existenzabfrage von Objekten!?
ich stimme Dir in diesem Punkt völlig zu. Meiner Meinung nach wird molily hier kein Glück haben, da ein Fall nach dem von ihm gesuchten Beispiel kaum existieren dürfte.
Was ist damit? Ein Bug, der nur im Opera auftritt, nicht direkt durch die Existenz einer JavaScript-Eigenschaft geprüft werden kann, aber dennoch mittels JavaScript „behoben“ werden kann.
Gruß,
Nerog-
Lieber Nerog,
Was ist damit? Ein Bug, der [...] aber dennoch mittels JavaScript „behoben“ werden kann.
nö. Browserbugs im CSS-Bereich werden gefixt (hier geht es ja nicht um den IE). Daher können solche JS-Spielereien irgendwann nach hinten losgehen. Ich lehne Deinen Einwand an dieser Stelle ab.
Liebe Grüße,
Felix Riesterer.
--
ie:% br:> fl:| va:) ls:[ fo:) rl:° n4:? de:> ss:| ch:? js:) mo:} zu:)-
Hi,
Was ist damit? Ein Bug, der [...] aber dennoch mittels JavaScript „behoben“ werden kann.
nö. Browserbugs im CSS-Bereich werden gefixt (hier geht es ja nicht um den IE).
Von wem? Opera trägt diesen Bug schon lange mit sich herum. Vielleicht wird er irgendwann gefixt. Vielleicht werden die IE-Bugs zukünftig auch gefixt.
Browsererkennung, wie sie auch im OP als Beispiel angeführt wird, dient doch wohl dem Browser-Bug-Workaround – oder, was natürlich sein kann – ich hab das OP missverstanden.Daher können solche JS-Spielereien irgendwann nach hinten losgehen.
Besagte JS-Spielereien funktionieren notfalls auch in Browsern, die jenen Bug nicht besitzen – sind da aber natürlich nicht notwendig. Sollte der Bug irgendwann gefixt werden, macht die Spielerei auch keine Probleme.
Ich lehne Deinen Einwand an dieser Stelle ab.
Dein gutes Recht. Auch wenn es kein Einwand im Sinne des OP war, scheint molily deine Meinung zu teilen ;)
Gruß,
Nerog
-
-
-
-
-
-
-
Ist der Thread ein Trick, um am Ende im Archiv etwas zu haben, auf das verwiesen werden kann, wenn es heißt "Aber es gibt Fälle, wo so eine Browserweiche unbedingt nötig ist!"?
Das Ganze ist ja nun auch wirklich schwierig: Die Objekt-Existenz-Abfrage erschlägt sehr viele Fälle, die IE-Geschichten lassen sich über Conditional Comments regeln, bleibt ja eigentlich nicht viel übrig.
Um es nochmal deutlich zu machen - Ja, mir fällt auch nichts ein.
--
Reden ist Silber, Schweigen ist Gold, meine Ausführungen sind Platin.
Self-Code: sh:( ch:? rl:( br:> n4:( ie:{ mo:) va:) de:> zu:} fl:| ss:| ls:~ js:| -
Hi,
ich suche für SELFHTML 9 ein JavaScript-Beispiel für einen Fall, in dem eine echte, »böse« Browsererkennung nötig ist, weil alle anderen üblichen Methoden der Objektabfragen nicht greifen.
Ich hätte da eventuell noch zwei Fälle, für die man „böse“ Browsererkennung braucht – und die man eigentlich serverseitig angehen sollte, aber man sich natürlich auch mit JavaScript behelfen kann.
1. APNG/GIF: Liegt eine Animation als APNG vor und der Browser unterstützt nur PNG, wird auch nur ein statisches Bild angezeigt. Es gibt IMO keine Möglichkeit abzufragen, ob die Animation abgespielt wird. Ein Fallback als GIF, kann nur aufgrund von Browsersniffing angezeigt werden.
2. MathML: Ob ein Browser mit MathML gar nichts anfangen kann und stattdessen einen Ersatz, z.B. in Form eines Bildes, braucht (z.B. IE), MathML nativ darstellen kann (z.B. FF, Opera9.5) oder MathML mit Hilfe eines Stylesheets darstellen kann (z.B. Opera<9.5, Safari) kann IMO auch nur durch „böse“ Browsererkennung ermittelt werden.
Sollte ich mich bei einem der Fälle (oder bei beiden) irren, wäre es nett, wenn jemand eine „saubere“ Lösung parat hätte.
Gruß,
Nerog-
Hi,
- APNG/GIF: Liegt eine Animation als APNG vor und der Browser unterstützt nur PNG, wird auch nur ein statisches Bild angezeigt. Es gibt IMO keine Möglichkeit abzufragen, ob die Animation abgespielt wird. Ein Fallback als GIF, kann nur aufgrund von Browsersniffing angezeigt werden.
GIF-Animation kann im Browser ebenfalls deaktiviert sein - und du hast keine Moeglichkeit, es zu erkennen.
MfG ChrisB
--
„This is the author's opinion, not necessarily that of Starbucks.“-
Hi,
GIF-Animation kann im Browser ebenfalls deaktiviert sein - und du hast keine Moeglichkeit, es zu erkennen.
Richtig. Mir ging es allerdings darum, zu erkennen, ob der Browser PNG-Animation als APNG prinzipiell unterstützt, um dann ggf. ein APNG- bzw. ein GIF-Bild zu laden.
Natürlich kann der Benutzer beides deaktivieren; genauso wie JavaScript, womit das Orginalposting überflüssig wäre ;)
Gruß,
Nerog
-
-
ich suche für SELFHTML 9 ein JavaScript-Beispiel für einen Fall, in dem eine echte, »böse« Browsererkennung nötig ist, weil alle anderen üblichen Methoden der Objektabfragen nicht greifen.
Es gibt zwei Sachen, einmal position fixed und dann den Bug, dass der IE keine Formularelemente überdecken kann. Das ist z.b. in meinem Versuch einer JS Combobox drin.
Allerdings würd ich eine Browserabfrage mit CC immer vorziehen und kann mir auch kein Problem vorstellen wo das nicht sinnvoller als navigator abfragen wäre.
Struppi.
-
gruss molily,
ich hatte mal das problem, dass Safaries mit einer 2er versionsnummer
beim test auf »RegExp.prototype.compile« *gelogen* haben.
der aufruf der [compile]-methode eines [[RegExp]]-objektes fuehrte
umgehend zu einer fehlermeldung, obwohl der test auf [compile] dessen
*funktionale existenz* bestaetigte.
unter den derzeitigen webkit-implementierungen tritt das problem nicht
mehr auf; aber fuer den zeitraum eines knappen jahres habe ich explizit
und ohne versionsunterscheidung auf webkit-engines geprueft, um unter
safari eine funktionierende [compile]-methode bereitstellen zu koennen.in der praxis habe ich bis auf dieses eine mal tatsaechlich weder eine
unterscheidung auf bestimmte versionen einer render- noch auf die einer
JavaScript-engine machen muessen. *feature-detection* hat bisher noch
in jedem fall geholfen.so long - 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:] -
Yerf!
Dummerweise fällt mir keines verbreitetes Problem ein, das man nur mithilfe von navigator-Abfragen und Co. umgehen kann. Sicher haben irgendwelche speziellen Versionen irgendwelche speziellen Problemchen, aber die sind mir zu besonders und kurzlebig, als dass sie als einleuchtende Beispiele gelten können.
Das Problem ist ja, das eine solche Unterscheidung nur bei einem definitiven Bug des Browsers notwendig wird. Und die sind außerhalb des IEs (den man mittels CC begegenen kann) eher selten und durch die häufigeren Releases (bei den nicht IE-brwosern) verschwinden sie meist auch recht schnell wieder.
Das einzige, das mir bisher über den Weg gelaufen ist, war beim Opera ein Fehler bei getComputedStyle. Vor Version 9.5 hat der bei der Abfrage der Width nicht den korrekten Wert geliefert, sondern den der OffsetWidth (also inklusive Rahmen und Padding).
Theoretisch könnte man dem aber auch mit einer Plausibilitätsprüfung entgegenkommen: sprich wenn Width gleich offsetWidth und Padding oder Border ungleich null, dann ist was faul...
Gruß,
Harlequin
--
<!--[if IE]>This page is best viewed with a webbrowser. Get one today!<![endif]-->