Problem mit Layern im MAC Safari
0 0 
Tim Tepaße
0 0 Tim Tepaße
Problem mit Layern im MAC Safari
Hallo, allerseits!
Ich habe eine Website mit Layertechnik erstellt, die unter Win und MacOS auf fast allen Browsern läuft. Nur der Mac-Safari macht Probleme. Er stellt einige Layer nicht dar. Die Seite liegt unter http://www.first-entertainment.de . Leider konnte mir noch keiner mit dem Problem helfen, ich finde grad keinen Ansatz, woran es liegen könnte... hat jemand eine Idee? Bin für jede Hilfe dankbar!!!
Viele Grüße,
Chris.
-
Hallo,
Ich habe eine Website mit Layertechnik erstellt, die unter Win und MacOS auf fast allen Browsern läuft. Nur der Mac-Safari macht Probleme. Er stellt einige Layer nicht dar.
da kannst du versuchen etwas nachzuhelfen, ggf. über eine
Browserweiche.Nach meinen Erfahrungen mit dem Browser und DHTML kann es z.B.
hilfreich sein ein neu positioniertes Element erst noch per
visibility zu verstecken und anschliessend wieder sichtbar zu
machen damit es "auftaucht".Grüsse
Cyx23
-
Hallo Cyx,
da kannst du versuchen etwas nachzuhelfen, ggf. über eine
Browserweiche.Mir ist bislang noch keine Browserweiche bekannt, die Safari als Browser selektiert. Hast Du da andere Informationen?
Tim
-
Hallo Tim,
Mir ist bislang noch keine Browserweiche bekannt, die Safari als Browser selektiert. Hast Du da andere Informationen?
bei JavaScript sollte es hier doch sogar recht einfach sein und vmtl. mehrere
Wege, notfalls trotz der bekannten Unsicherheiten auch per Useragent, geben?Vor zwei Jahren hatte ich mal ein DHTML-Menu entwickelt und wenn ich es recht
erinnere mit document.contains u. document.getElementsByTagName abgefragt, andere
Möglichkeiten finden sich vielleicht bei Browsererkennung durch JavaScript.Grüsse
Cyx23
-
Hallo Cyx,
notfalls trotz der bekannten Unsicherheiten auch per Useragent, geben?
Der Useragent String meines Safaris lautet:
"Netscape Mozilla/5.0 (Macintosh; U; PPC Mac OS X; de-de) AppleWebKit/412 (KHTML, like Gecko) Safari/412)"
Man beachte, wie gut dieser UA-String darauf optimiert ist, bei UA-Tests für was anderes gehalten zu werden. Geniale Arbeit da bei Apple. ;)
andere Möglichkeiten finden sich vielleicht bei Browsererkennung durch JavaScript.
Dein Skript stuft mich als Safari/Konqueror ein, was ja auch halbwegs richtig ist.
Nur: Die Entwicklung von Safari und Konqueror driften immer mehr auseinander, neulich haben sich die KHTML-Entwickler darüber beschwert, daß sie bestimmte Innovationen von Safari nicht zurückpflegen können, da diese bestimmte andere Techniken benötigen. Ich würde also nicht mehr annehmen, daß Safari == Konqueror, z.B. kann Konqi document.all, Safari dagegen nicht, etc.
Und: Das Ausmaß Deiner schönen Tabelle zeigt es ja: Die „jungen, wilden“ Browser entwickeln sich immer weiter, d.h. die Entscheidungsmatrix für einen Browser wird immer länger, da es um die Unterstützung immer obskurerer Eigenschaften („Es gibt window.crypto?“) geht. Ob das irgendwann noch praktikabel ist?
Eine Prüfung nach Unterstützung von benötigten Eigenschaften und eventuelle Fallbacks sind da wohl einfacher. Zumindest erspart man sich das Testen nach x-tausend unterschiedlicher Browserversionen.
Tim
-
Hallo Tim,
Eine Prüfung nach Unterstützung von benötigten Eigenschaften und eventuelle Fallbacks sind da wohl einfacher. Zumindest erspart man sich das Testen nach x-tausend unterschiedlicher Browserversionen.
genau das klappt ja nicht immer oder oft nur soweit dass zu viele
Browser bleiben welche mit den angeblich unterstützten Anforderungen
gar nicht klar kommen.Und im vorliegenden Fall ist das Problem womöglich gar nicht anders als
über die Browserversion, also Useragent und/oder typisches Verhalten,
abfragbar; m.E. sind da übrigens sowieso Safari und Konqueror betroffen.
Ansonsten ist es natürlich unerfreulich wenn indirekt durch Apples
Browserpolitik Konqueror geschwächt wird, dazu natürlich die von
dir angesprochene zunehmende Browservielfalt.Grüsse
Cyx23
-
Hallo Cyx,
Ansonsten ist es natürlich unerfreulich wenn indirekt durch Apples Browserpolitik Konqueror geschwächt wird ..
Ich sehe das garnicht mal so als Schwächung. Safari ist ein fork von KHTML, die beiden Linien entwickeln sich schon allein aus technischen Gründen auseinander, KHTML läuft unter QT, Safari mit der ganzen MacOS X Umgebung. Wo es Überschneidungen gibt, können die KHTML-Jungs die Apple-Patches sicherlich einpflegen, wo nicht, dann halt nicht.
Ein anderes Problem scheint eher zu sein, daß Safari nicht wirklich offen entwickelt wird, gemessen an der Kultur von OS-Projekten. Aber das war bei Apple zu erwarten.
Tim
-
-
-
-
-