differnt CSS for NN4, winie, Opera, Mozilla, Konqueror
goewe.com
- css
0 Axel Richter0 gowe.com
0 Sven Rautenberg0 Matti Maekitalo0 molily0 Sven Rautenberg0 Cyx23
Bemerkung: Mein Formumsartikel vom Freitag 21.3. wurde aus dem Forum wieder entfernt (warum auch immer).
Die Methode, Style Sheets vor Netscape zu verstecken, stammt von Liam Quinn.
Die Methode, Style Sheets vor Opera zu verstecken, stammt von Juan R. Pozo.
Speziell für diese Website habe ich Pozo's Methode mit meiner eigenen Idee kombiniert:
media="all" , wobei l = l ist, versteckt das Style Sheet vor Opera.
Mit media="all dummy" versteckt man es vor NN4, WinIE und Konqueror.
Man beachte: Pozo's Methode versteckt nur die in styles4mozilla.css definierten Formatierungen, aber jedes von styles4mozilla.css via @import eingebundene Style Sheet wird von Opera sehr wohl beachtet (es kommt auf die media-Angabe an - zB:
@import url(opera.css) screen;
Beides miteinander kombiniert ergibt:
<link rel="stylesheet" type="text/css" href="styles4mozilla.css" media="all dummy">
wobbei in 'styles4mozilla.css' via @import 'styles4opera.css' eingebunden wird.
Um Konqueror ein eigenes Style Sheet zu geben, habe ich folgende Methode gefunden:
<link rel="alternate stylesheet" type="text/css" title="Konqueror" href="styles4konqueror.css" media="all">
Man beachte, daß keines der vorherigen Style Sheets einen Titel haben darf und das für Konqueror bestimmte Style Sheet muss ein 'alternate stylesheet' sein (siehe Source Code).
Zumindest Konqueror 3.0 benutzt dann das erste 'alternate stylesheet' welches einen Titel trägt.
komplettes Beispiel:
<link rel="stylesheet" href="styles4netscape.css">
<link rel="stylesheet" href="styles4allmedia.css" media="all">
<link rel="stylesheet" href="styles4mozilla.css"
media="all dummy">
<link rel="alternate stylesheet" title="Konqueror" href="styles4konqueror.css" media="screen" >
Falls irgendjemand weiss ob die obige hiding Methode bei hier nicht genannten Browsern funktioniert, waere ich sehr Dankbar!
mit freundlichen Gruessen, A.Goewe.
ps: Diesmal habe ich keine url-s angegeben die als Werbung ausgelegt werden koennten und hoffe dass dieser Beitrag jetzt nicht wieder entfert wird.
Hallo,
Bemerkung: Mein Formumsartikel vom Freitag 21.3. wurde aus dem Forum wieder entfernt (warum auch immer).
Nö. Der ist einfach im Archiv gelandet, weil keiner drauf geantwortet hat. http://forum.de.selfhtml.org/archiv/2003/3/41667/#m227977
Du hast da aber einen Fehler gemacht:
media="sareen"
blockt bei mir ausnahmslos alle Browser. Auch nicht schlecht ;-))
So ist's richtig:
media="scReen"
Diese Methode stammt von Juan R. Pozo, http://html.conclase.net/pruebas/hacko5.html
Das blockt bei mir nur Opera6.05 (7 habe ich noch nicht).
viele Grüße
Axel
Stimmt! es muss media="screen" lauten, wobei c == 'c' und R == 'C' ist.
Da ich nur media="all" verwendet habe ist es mir nicht aufgefallen.
Danke und Gruss a.goewe.
Moin!
Bemerkung: Mein Formumsartikel vom Freitag 21.3. wurde aus dem Forum wieder entfernt (warum auch immer).
Er wurde archiviert: </archiv/2003/3/41667/>
[...] komplettes Beispiel:
<link rel="stylesheet" href="styles4netscape.css">
<link rel="stylesheet" href="styles4allmedia.css" media="all">
<link rel="stylesheet" href="styles4mozilla.css"
media="all dummy">
<link rel="alternate stylesheet" title="Konqueror" href="styles4konqueror.css" media="screen" >Falls irgendjemand weiss ob die obige hiding Methode bei hier nicht genannten Browsern funktioniert, waere ich sehr Dankbar!
Deine Versionen ignorieren, dass man manchmal zwingend einen gewissen Medientyp angeben _muß_, um Formatierungen anzuwenden. Beispielsweise eben "screen" oder "print".
Außerdem hat man bei deinem Beispiel ganz streng darauf zu achten, welche Regeln von welchen anderen Regeln überschrieben werden, bzw. welche Regeln man explizit wieder aufheben muß, etc...
Insgesamt ist auch für diesen "Hack" zu sagen, dass er mehr Probleme mit sich bringt, als er löst, weil wie immer ungewiß ist, wie künftige Browser reagieren werden. Außerdem wird der Mac vollkommen unbeachtet gelassen - oder wo steht "macie.css"? Dieser Browser wirft noch ganz andere Probleme mit CSS auf.
Ich habe in meinen Jahren die Erfahrung gemacht, dass eine CSS-Weiche in vielen Fällen unnötig ist, und wenn, dann nur Netscape 4 von gewissen Anweisungen ausgeklammert werden muß. Alles andere, auch das unterschiedliche Box-Modell, läßt sich in der Regel browserübergreifend und 100% kompatibel ohne Ausnutzung von Eigenheiten in den Griff bekommen. Kleinster gemeinsamer Nenner ist hier leider der IE - was aber angesichts seiner Verbreitung (leider) sinnvoll ist, da Sondereffekte von den meisten Besuchern eben nicht wahrgenommen werden können.
ps: Diesmal habe ich keine url-s angegeben die als Werbung ausgelegt werden koennten und hoffe dass dieser Beitrag jetzt nicht wieder entfert wird.
Du bist zu paranoid.
- Sven Rautenberg
use Mosche;
Nur so nebenbei ...
Insgesamt ist auch für diesen "Hack" zu sagen, dass er mehr Probleme mit sich bringt, als er löst, weil wie immer ungewiß ist, wie künftige Browser reagieren werden. Außerdem wird der Mac vollkommen unbeachtet gelassen - oder wo steht "macie.css"? Dieser Browser wirft noch ganz andere Probleme mit CSS auf.
Wie viele Mac-User benutzen denn eigentlich Safari (http://www.apple.com/safari) und damit KHTML, den Kern von Konqueror? Ist das überhaupt bekannt, dass dait die Bedeutung des Testens mit Konqueror dramatisch ansteigt?
use Tschoe qw(Matti);
Hallo Matti und Sven,
(...) Außerdem wird der Mac vollkommen unbeachtet gelassen - oder wo steht "macie.css"? Dieser Browser wirft noch ganz andere Probleme mit CSS auf.
Wie viele Mac-User benutzen denn eigentlich Safari (http://www.apple.com/safari) und damit KHTML, den Kern von Konqueror? Ist das überhaupt bekannt, dass dait die Bedeutung des Testens mit Konqueror dramatisch ansteigt?
Hier stellt sich die Frage, ob das Testen mit Konqueror tatsächlich eindeutige Rückschlüsse auf Safari erlaubt, siehe auch </archiv/2003/3/41060/#m225478>. Rendern Safari und Konqueror gleich genug, als dass man von dem einen auf den anderen schließen kann? Fand schon ein Austausch zwischen den unterschiedlichen Entwicklungen statt?
Grüße,
Mathias
use Mosche;
Wie viele Mac-User benutzen denn eigentlich Safari (http://www.apple.com/safari) und damit KHTML, den Kern von Konqueror? Ist das überhaupt bekannt, dass dait die Bedeutung des Testens mit Konqueror dramatisch ansteigt?
Hier stellt sich die Frage, ob das Testen mit Konqueror tatsächlich eindeutige Rückschlüsse auf Safari erlaubt, siehe auch </archiv/2003/3/41060/#m225478>. Rendern Safari und Konqueror gleich genug, als dass man von dem einen auf den anderen schließen kann? Fand schon ein Austausch zwischen den unterschiedlichen Entwicklungen statt?
Da ich regelmäßig den wöchentlich CVS-Digest lese (z.B. http://members.shaw.ca/dkite/mar212003.html), habe ich da eigentlich einen ganz guten Einblick in das, was geschieht. Diese Woche waren anscheinend keine Safari-"Merges", vielleicht sind sämtliche Apple-Änderungen schon ins CVS eingeflossen. Letzte Woche (http://members.shaw.ca/dkite/mar142003.html) war auch nur wenig, dafür in den Wochen davor relativ viel.
use Tschoe qw(Matti);
Hallo Sven,
<link rel="stylesheet" href="styles4netscape.css">
<link rel="stylesheet" href="styles4allmedia.css" media="all">
<link rel="stylesheet" href="styles4mozilla.css" media="all dummy">
<link rel="alternate stylesheet" title="Konqueror" href="styles4konqueror.css" media="screen">Insgesamt ist auch für diesen "Hack" zu sagen, dass er mehr Probleme mit sich bringt, als er löst, weil wie immer ungewiß ist, wie künftige Browser reagieren werden.
Das lässt sich je nach Hack einschätzen, außerdem bedarf vermutlich jeder Workaround ständiger Kontrolle.
Viel schwerwiegender finde ich in diesem Fall, dass mit jedem Dokument massig zusätzlicher HTTP-Traffic erzeugt wird.
Ich habe in meinen Jahren die Erfahrung gemacht, dass eine CSS-Weiche in vielen Fällen unnötig ist, und wenn, dann nur Netscape 4 von gewissen Anweisungen ausgeklammert werden muß.
Dass du solchen Hacks kritisch gegenüberstehst, ist mir bekannt, aber die Fragen im Forum zeigen immer wieder, dass Bedarf besteht, und zwar selbst wenn der MSIE als kleinster gemeinsamer Nenner definiert wird, denn schließlich ist dies alleine kein Garant dafür, dass die Seite in den anderen Browsern genauso dargestellt wird.
Alles andere, auch das unterschiedliche Box-Modell, läßt sich in der Regel browserübergreifend und 100% kompatibel ohne Ausnutzung von Eigenheiten in den Griff bekommen.
Ja, mit zusätzlichen Elementen, pro Box mit padding und width eines. Das Markup einiger Seiten wird dadurch unverhältnismäßig aufgebäht, das hatten wir schon. Ich frage mich angesichts dessen, welche Lösung im Hinblick auf den zu erwartenden zukünftigen Arbeitsaufwand effizienter und nachhaltiger ist. Mit beispielsweise Tanteks Box Model-Hack, welcher unzähligen CSS-Layoutern das Leben erleichtert, stehst du ja auf Kriegsfuß. ;)
Grüße,
Mathias
Moin!
Das lässt sich je nach Hack einschätzen, außerdem bedarf vermutlich jeder Workaround ständiger Kontrolle.
[...] Ich frage mich angesichts dessen, welche Lösung im Hinblick auf den zu erwartenden zukünftigen Arbeitsaufwand effizienter und nachhaltiger ist. Mit beispielsweise Tanteks Box Model-Hack, welcher unzähligen CSS-Layoutern das Leben erleichtert, stehst du ja auf Kriegsfuß. ;)
Es ist eine grundsätzliche Entscheidung, die man da fällen muß.
Wir alle haben uns doch irgendwie gefreut, dass man mittlerweile _keine_ Sonder-Seitenversionen für Netscape und IE mehr basteln muß - zumindest _will_ das keine aufgeklärter Mensch mehr.
Warum zum Teufel also wird das gleiche Vorgehen jetzt bei CSS-Dateien angewandt? Es treten dieselben grundsätzlichen Probleme auf:
1. Ist sichergestellt, dass die angewandten Hacks wirklich zuverlässig den Zielbrowser betreffen, und keinen anderen?
2. Ist sichergestellt, dass künftige Browser den Hack immer noch kennen? Oder dass die Browser den mit dem Hack zu umgehenden Bug gemeinsam mit dem Hack-Bug entfernen?
3. Kann man eigentlich alle existierenden Browser auf Verträglichkeit mit dem Hack prüfen?
Und nicht ganz unwichtig:
4. Kann man nachfolgenden Bearbeitern den Hack ausreichend dokumentieren? Nichts ist schlimmer, als wenn Hacks verwendet werden, die man durch irgendeinen dummen Zufall oder Unwissenheit wieder deaktiviert.
In Anbetracht all dieser teilweise schwerwiegenden Probleme, die allesamt ein "Create and forget", also im Prinzip Wartungsfreiheit nach dem erstmaligen Erstellen, verhindern, weil man beim Auftreten neuer Browserversionen die Seiten noch einmal komplett durchtesten muß, sind solche Hacks sehr kritisch zu sehen. Das hat mit einzelnen, speziellen Hacks gar nichts zu tun - es geht um die Gesamtheit aller Hacks.
Es gibt einfach zu viele Szenarien, bei denen Hacks zur Zeitbombe werden können.
Nur ein Beispiel:
Der IE6 hat bei Tanteks Hack sicherlich einige solche Zeitbomben hochgehen lassen. Denn er erkennt endlich, dass die vorzeitig eingeschmuggelte "}"-Klammer in der voice-family die CSS-Klasse _nicht_ beendet. Er schaltet aber nur dann in den W3C-Box-Model-Modus, wenn er einen korrekten DOCTYPE erhält.
Also hatten und haben alle Seiten ein Problem, die Tanteks Hack einsetzen, um den IE5 zu bezwingen, aber keinen richtigen DOCTYPE angeben, um den IE6 in den Strict-Modus zu schalten und damit zu bezwingen. Oder in XHTML-Seiten die erste Zeile mit der XML-Deklaration "versauen", die den IE6 ebenfalls in den Quirks-Modus schaltet. Tantek selbst weist darauf hin, dass dies ein Problem ist und man die Zeile deshalb einfach weglassen soll. Aber geht das immer?
Dabei hat Microsoft eigentlich fast alles richtig gemacht: Im IE6 ist sowohl beseitigt, dass die erste }-Klammer die CSS-Klasse beendet, als auch das Box-Model korrigiert, was ja erst zu diesem Hack führte. Aber eben leider nur unter gewissen Umständen. Man stelle sich vor, dass bei anderen Browsern einfach nur einer der beiden Bugs korrigiert wird - und schon ist alles im Arsch! Obwohl ich vermute, dass die Hersteller die kursierenden CSS-Hacks kennen, bin ich absolut nicht davon überzeugt, dass sie diese bei ihrer Fehlerbehebung auch wirklich beachten können. Das fängt ja allein damit an, dass Tanteks Hack nicht nur dazu benutzt werden kann, das Box-Model zu korrigieren, sondern für eine Vielzahl von weiteren Dingen, die man irgendwie vor dem IE 5.5 und tiefer verstecken will.
Wenn also Probleme mit dem IE-Box-Model hat, benutze diesen "Hack":
http://www.b-spoke.de/artikel/css-box-model/boxmodell-01.html
Auch wenn auf der Seite behauptet wird, der zusätzliche Code sei unsauber, weil aufgebläht: Es ist eine absolut standardkonforme Methode. Das damit hervorgerufene Aussehen ist in allen Browsern identisch, weil es gemäß dem Standard so aussehen muß. Aber eben auch mit dem IE-Box-Model identisch aussieht.
Ok, damit ist nicht gesagt, dass irgendein Box-Model-Bug eines anderen Browsers auch geheilt wird. Aber die meisten Probleme werden vermieden, weil es gar nicht mehr so viele Kombinationen gibt, Breiten falsch zu addieren. Irgendeine Ähnlichkeit mit dem W3C-Box-Model werden ja wohl alle existierenden Box-Models in Browsern haben. :)
- Sven Rautenberg
Hallo Sven,
da CSS von allen Browsern unterschiedlich interpretiert wird, ist
ein ganz neues Risiko entstanden, nämlich der Verlust von Information.
Der Vorgang wird gerne verdrängt und als Problem der älteren Broser
dargestellt. Gerade beim Netscape 4 ist es aber so, dass zuverlässig
Browserweichen so kombiniert werden können, dass das Ergebnis berechenbar
und sicher ist.
Echte Probleme sehe ich denn eher bei Opera und Mozilla usw., für den
IE und den IE versus Mozilla ist es sowieso m.E. richtiger per Doctype
downzugraden, dann sind alle IE ähnlicher im Verhalten.
Gerade für Opera 7 könnte es nun manchmal nötig sein, statt richtiger
Angaben falsche Werte einzusetzen und diese per Weiche für Mozilla
mit richtigen Werten zu überschreiben, und dann muss erstmal
überprüft werden was Netscape 6 macht, ich hab hier noch einen
Mozilla 0.9x der da wieder anders reagiert, und alle zukünftigen
Browser...
Etwas einfacher ist es da mit älteren Browsern, obwohl iCab,
Opera 5 und andere auch nicht ganz weichensicher sind.
Trotzdem, da die Probleme CSS-Probleme sind ist es naheliegend und auch
zwingend im CSS zu korrigieren, und je nach Machart auch komfortabel.
Für Netscape 4 gibt es sehr gute Möglichkeiten im HTML per Inlinescript
und -style anzupassen, Korrekturen die aber im head mit anderer
Vorgehensweise übersichtlicher realisiert werden könnten.
Für NC4 sind auch recht wartungsfreie Lösungen möglich, und dem NC4 kann
nahezu das vollständige richtige Stylesheet zugemutet werden.
Erst beim IE4 ist letztendlich die Situation denkbar ein Stylesheet
verstecken zu müssen, falls die Seitenstruktur per DHTML nachgebessert
wird, JScript aber deaktiviert ist, und eine Weiche ist jetzt doch
nötig um dem IE4 ein Not-CSS zu verpassen. Das kann auch alles im Head
eingebunden werden, und ist zumindest per SSI, PHP usw. auch bei
mehreren Seiten zumutbar.
Die mögliche Verlagerung auf "Sonder-Seitenversionen" per mehrerer
CSS-Versionen hat schonmal den Vorteil von sauberem homogeneren HTML-Code,
aber x Versionen ist zu unpraktisch, eine CSS-Version mit möglichst wenig
Weichen und z.B. eine zweite Datei mit Ergänzungen welche nur vom NC4
geladen wird ist ja auch möglich.
Grüsse
Cyx23