Browserabfrage möglich?

[Ulli]

Hallo Leute - ich habe eine Frage zum Thema CSS und Netscape Communicator 4.x. Ich habe ein CSS mit Alpha-Filter für Texte angelegt (opacity). Netscape 6 und 7 stellt dann immerhin noch den Text dar, ohne Filterwirkung, aber immerhin. Netscape 4.x dagegen stellt noch nicht einmal den Text dar.

Daher meine Frage: kann man über eine Browserabfrage unterschiedliche CSS-Angaben ansteuern (quasi ein CSS ohne diese Filter) - und wie sähe das aus?

Wäre ganz, ganz toll, wenn mir jemand helfen könnte, vielen Dank schonmal ;-)))
Gruß, Ulli

[cheops]

hi!

schau dir mal folgende javascript-funktionen an:

navigator.appName
navigator.platform
navigator.appVersion

...die benutze ich bei uns als browserweiche, um eindeutig einen
browser identifizieren zu können. bei neueren versionen fügst
du einfach noch das attribut opacity hinzu nd bei älteren browsers
lässt du es dann einfach weg... musst halt nur dynamisch zuweisen

gruß und viel erfolg
cheops

Hallo Leute - ich habe eine Frage zum Thema CSS und Netscape Communicator 4.x. Ich habe ein CSS mit Alpha-Filter für Texte angelegt (opacity). Netscape 6 und 7 stellt dann immerhin noch den Text dar, ohne Filterwirkung, aber immerhin. Netscape 4.x dagegen stellt noch nicht einmal den Text dar.

Daher meine Frage: kann man über eine Browserabfrage unterschiedliche CSS-Angaben ansteuern (quasi ein CSS ohne diese Filter) - und wie sähe das aus?

Wäre ganz, ganz toll, wenn mir jemand helfen könnte, vielen Dank schonmal ;-)))
Gruß, Ulli

[Maxx]

Hallo Ulli, hi cheops

schau dir mal folgende javascript-funktionen an:

navigator.appName
navigator.platform
navigator.appVersion

lieber nicht so. Das ist äußerst unzuverlässig. Lieber
<link rel="stylesheet" type="text/css" href="standard.css">
<style type="text/css"> @import url(extended.css);</style>

standard.css bekommen alle Browser. Auch der 4er Netscape.
extended.css ist vor ihm verborgen. Da packst du deinen Filter rein.

HTH

Maxx

[cheops]

yo, das stimmt schon, nur kannst du damit "nur" die funktionalität checken, nicht aber den eigentlichen browser.
da speziell IE mac und netscape 4.irgendwo die fonts unterschiedlich gross darstellen und ich das unterbinden muss, bin ich gezwungen auf den browser abzuprüfen und nicht auf die funktionalität ... war halt das schnellste code-snippet was ich zur hand hatte... mag sein dass es nicht 100% passend war zur frage... :-)

grüßle
cheops

Hallo Ulli, hi cheops

schau dir mal folgende javascript-funktionen an:

navigator.appName
navigator.platform
navigator.appVersion

lieber nicht so. Das ist äußerst unzuverlässig. Lieber
<link rel="stylesheet" type="text/css" href="standard.css">
<style type="text/css"> @import url(extended.css);</style>

standard.css bekommen alle Browser. Auch der 4er Netscape.
extended.css ist vor ihm verborgen. Da packst du deinen Filter rein.

HTH

Maxx

[Johannes Zeller]

Hi cheops

yo, das stimmt schon, nur kannst du damit "nur" die funktionalität checken, nicht aber den eigentlichen browser.
da speziell IE mac und netscape 4.irgendwo die fonts unterschiedlich gross darstellen und ich das unterbinden muss, bin ich gezwungen auf den browser abzuprüfen und nicht auf die funktionalität ... war halt das schnellste code-snippet was ich zur hand hatte... mag sein dass es nicht 100% passend war zur frage... :-)

Das ist doch gar kein Problem. Verwende einfach relative Größenangaben für deine Schriften.

[...]

http://learn.to/quote *g*

Schöne Grüße

Johannes

[Johannes Zeller]

Oh großer Pharao ;-)

navigator.appName
navigator.platform
navigator.appVersion

...die benutze ich bei uns als browserweiche, um eindeutig einen
browser identifizieren zu können.

Wie das denn? Meistens habe ich z.B. JavaScript nicht aktiviert und manchmal identifiziere ich mich auch als ein anderer Browser oder als "Ein besonderer Browser" *g*. Wenn schon JavaScript, dann als Fähigkeitenabfrage, z.B. if(document.layers).

Ich würde Ulli eher mal diesen Link hier anbieten:
http://aktuell.de.selfhtml.org/tippstricks/css/browserweiche/index.htm
Das funktioniert auch ohne JavaScript.

Schöne Grüße

Johannes

[kaspar]

Hallo Leute - ich habe eine Frage zum Thema CSS und Netscape

Hallo,

Daher meine Frage: kann man über eine Browserabfrage unterschiedliche CSS-Angaben ansteuern (quasi ein CSS ohne diese Filter) - und wie sähe das aus?

da gibt es verschiedene Möglichkeiten. Und viele Antworten im netz, z.B. diese:
http://www.css4you.pehlgrim.de/wsbw/index.php

Gruß: kaspar

[Orlando]

Hi Ulli,

kann man über eine Browserabfrage unterschiedliche CSS-Angaben ansteuern (quasi ein CSS ohne diese Filter) - und wie sähe das aus?

<floet>Das hab' ich nicht zum Spaß geschrieben...<floet>

http://aktuell.de.selfhtml.org/tippstricks/css/browserweiche/

Die multikultisuperduper-Aufstellung, wie man Browser gezielt von CSS ausschließen kann, findest du hier:

http://centricle.com/ref/css/filters/

Grüße,
 Roland

[Cyx23]

Hallo Ulli,

Hallo Leute - ich habe eine Frage zum Thema CSS und Netscape Communicator 4.x. Ich habe ein CSS mit Alpha-Filter für Texte angelegt (opacity). Netscape 6 und 7 stellt dann immerhin noch den Text dar, ohne Filterwirkung, aber immerhin. Netscape 4.x dagegen stellt noch nicht einmal den Text dar.

Daher meine Frage: kann man über eine Browserabfrage unterschiedliche CSS-Angaben ansteuern (quasi ein CSS ohne diese Filter) - und wie sähe das aus?

da gibt es einige Möglichkeiten:

http://www.lipfert-malik.de/webdesign/tutorial/css.html#Browserweichen

Grüsse

Cyx23

[molily]

Hallo Cyx,

Daher meine Frage: kann man über eine Browserabfrage unterschiedliche CSS-Angaben ansteuern (quasi ein CSS ohne diese Filter) - und wie sähe das aus?

da gibt es einige Möglichkeiten:

http://www.lipfert-malik.de/webdesign/tutorial/css.html#Browserweichen

Ich weiß zwar nicht, wieso du Möglichkeiten auflistest, welche anscheinend teilweise selbst deiner Meinung nach nicht empfehlenswert sind, aber das ändert nichts daran, dass einige davon enorm kontraproduktive Nebenwirkungen haben.

User-Agent-Weichen sind, wie du selbst schreibst, unzuverlässig. (Siehe auch Archiv usw...)

Die Weiche mit iframe ist vermurkstes Markup, denn die iframe-Elemente haben keinen semantischen Wert und die Verschachtelung ist nicht wohlgeformt. Anstatt <script< meintest du wohl <script>.

Bei der JSSS-Weiche würde ich vorsichtig sein, denn einige Browser ignorieren die type-Angabe beim style-Element und versuchen so oder so den Inhalt als W3C-CSS-Code zu behandeln.

Die Script-Entities sind zwar laut Specs erlaubt, aber dennoch kann damit gerechnet werden, dass die meisten Parser diesen speziellen Code als Fehler betrachten anstatt ihn als Script-Entities zu erkennen und absichtlich und direkt zu umgehen/ignorieren. »(...) auch der W3C CSS-Validator hat nichts zu bemängeln« - stimmt nicht, der CSS-Validator meckert erwartungsgemäß: http://jigsaw.w3.org/css-validator/validator?text=font-size%3A+13px%3B+%26{'font-size%3A14px%3B'}%3B&warning=2&profile=css2&usermedium=all (auch beim Einbetten in Markup über style-Element oder -Attribut). Solche Entities sind in link-Elementen besonders gefährlich, da alle Browser, welche die Entities nicht verstehen, das link- bzw. script-Element nicht ignorieren, sondern einen Request zum Server senden (GET /&{'nc4.css'}; HTTP/1.1 usw.) und natürlich einen 404 erzeugen.

Dass die Netscape-typische Schreibweise von CSS-Eigenschaften nicht valide ist, ist dir bekannt. Ein Parser eines Browsers wird vermutlich folgendes sehen: http://jigsaw.w3.org/css-validator/validator?text=color%3Ablue%3B+%26{'color%3Agreen%3B'}%3B+%26{'color%3Ared%3B'}%3B+%2F%2Fcolor%3Aorange%3B&warning=2&profile=css2&usermedium=all.

div { // color:blue;} usw. ist ebenfalls fehlerhafte Syntax.

Diese Methoden mögen alle interessant sein (mit den nicht kritisierten gehe ich auch größtenteils konform), aber da du dir selbst, soweit ich den Artikel verstanden habe, die Vorgabe gemacht hast, W3C-konforme Lösungen ohne Zweckentfremdung der Elemente et cetera anbieten zu wollen, verstehe ich nicht, wieso du sie vorstellst und zudem hier (zusammen mit den tatsächlich brauchbaren) empfiehlst, wenn nach konkreten Lösungen gefragt wird.

Grüße,
Mathias

[Cyx23]

Hallo Mathias,

Diese Methoden mögen alle interessant sein (mit den nicht kritisierten gehe ich auch größtenteils konform), aber da du dir selbst, soweit ich den Artikel verstanden habe, die Vorgabe gemacht hast, W3C-konforme Lösungen ohne Zweckentfremdung der Elemente et cetera anbieten zu wollen, verstehe ich nicht, wieso du sie vorstellst und zudem hier (zusammen mit den tatsächlich brauchbaren) empfiehlst, wenn nach konkreten Lösungen gefragt wird.

in dem Artikel werden umfassend Möglichkeiten vorgestellt, aus mehreren
Gründen auch nicht valide Lösungen.

Nicht valide Lösungen i.d.R. mit der Erklärung warum sie nicht empfehlenswert
sind oder welche Nachteile denkbar sind (ggf. sind solche Angaben noch zu
ergänzen oder zu korrigieren).

Kurz zur JSSS-Syntax im CSS, diese empfehle ich sehr wohl, und im Verlauf
des Kapitels wird eigentlich deutlich wie und warum und auch wann es valide
einsetzbar ist.

Bei der JSSS-Weiche sind mir "einige Browser" nicht untergekommen, aber selbst
daran ist gedacht, wenn man den ganzen Artikel kennt, aber da kann noch eine
Anmerkung dazukommen, danke für den Hinweis :-)

Deine Bedenken hinsichtlich der Entities kann ich so nicht nachvollziehen,
werde mir das aber trotzdem nochmal anschauen. Der W3C Vali wird eine solche
Seite mit Entities bei Inlinestyles weder bzgl. HTML noch bei CSS anmeckern,
darf oder soll ich hier der Mitteilung des W3C-Validation-Service
"This Page Is Valid" nicht vertrauen?

Die von dir geforderten konkreten Lösungen sind zu finden, auch
Lösungen die besser sind als ein -wie leider meist- unbedacht verwandtes
@media all als Weiche für Netscape 4.

Grüsse

Cyx23

[molily]

Hallo,

Deine Bedenken hinsichtlich der Entities kann ich so nicht nachvollziehen, werde mir das aber trotzdem nochmal anschauen. Der W3C Vali wird eine solche Seite mit Entities bei Inlinestyles weder bzgl. HTML noch bei CSS anmeckern, ...

In HTML 4-Dokumenten scheinen die SGML-Parser des HTML- und des CSS-Validators die Script-Entities zu verstehen, bei XHTML sieht es anders aus. Der CSS-Validator sagt erwartungsgemäß, dass zuerst das Dokument valide sein muss. Der XHTML-Validator sagt zwar, es sei valide und gibt nur eine Warnung aus, aber wenn es mit dem empfohlenen Inhaltstyp an die Browser geliefert wird, zeigen sie das angeblich valide Dokument nicht an, weil sie auf den Parserfehler stoßen (ich tippe auf eine Unzulänglichkeit des Validators).
Für XHTML ist die Methode also in jedem Fall ungeeignet, für XHTML als text/html wahrscheinlich tolerabel, aber wenn XHTML Verwendung findet, ist die Anwendung von XML-Werkzeugen nicht weit, womit es intern auf dasselbe herauskommt...

... darf oder soll ich hier der Mitteilung des W3C-Validation-Service "This Page Is Valid" nicht vertrauen?

Ob das Dokument valide ist, ist gewissermaßen nicht relevant, wenn dieses Sonderkonstrukt zwar im Standard steht, aber die meisten Browser es nicht als solches erkennen (und auch nicht gegebenenfalls übergehen/ignorieren), sondern es wie jeden anderen CSS-Syntaxfehler behandeln und Fehlertoleranzroutinen anwenden.
Somit besteht kein faktischer Unterschied zwischen validen Script-Entities und anderen heiklen Browserweichen, welche bewusst mit invaliden Code arbeiten, von denen meist abgeraten wird beziehungsweise welche wenig Konjunktur haben.

Die von dir geforderten konkreten Lösungen sind zu finden, auch Lösungen die besser sind als ein -wie leider meist- unbedacht verwandtes @media all als Weiche für Netscape 4.

Dass Netscape 4 meist simpelst das Hauptlayout vorenthalten wird und mit einem Minimallayout abgespeist wird, ist zwar nicht elegant, aber angesichts der Tatsache, dass NS 4.x offensichtlich auch laut deinem Artikel nur über JSSS mit einem gleichwertigen Layout versorgt werden kann, verständlich, da der Unwille nachvollziehbar ist, JSSS einzusetzen und sich eventuell sogar neu in diese wie du schreibst eigentlich zurecht obsolete Technik einzuarbeiten. Insofern fürchte ich, dass deine Dokumentierung der Möglichkeiten von JSSS auf wenig Bereitschaft stoßen wird, sich damit überhaupt auseinanderzusetzen.

Grüße,
Mathias

[Cyx23]

Hallo Mathias,

den Unterschied zum XHTML werde ich mir nochmals anschauen, interessant.

Dass Netscape 4 meist simpelst das Hauptlayout vorenthalten wird und mit einem Minimallayout abgespeist wird, ist zwar nicht elegant, aber angesichts der Tatsache, dass NS 4.x offensichtlich auch laut deinem Artikel nur über JSSS mit einem gleichwertigen Layout versorgt werden kann, verständlich, da der Unwille nachvollziehbar ist, JSSS einzusetzen und sich eventuell sogar neu in diese wie du schreibst eigentlich zurecht obsolete Technik einzuarbeiten. Insofern fürchte ich, dass deine Dokumentierung der Möglichkeiten von JSSS auf wenig Bereitschaft stoßen wird, sich damit überhaupt auseinanderzusetzen.

JSSS ist allerdings mächtiger als CSS und komfortabel einsetzbar, so kann aus dem CSS augelesen und automatisch umgesetzt werden, man muss also u.U. später nicht mehr anpassen wenn im CSS etwas verändert wird.
Die Syntax ist recht einfach nachvollziehbar wenn Kenntnisse in JavaScript und CSS vorliegen, man darf sich halt nicht erschrecken lassen.
Und proprietäre Techniken müssen offenbar immer wieder mal rausgekramt werden, und bei JSSS ist die Auswirkung /Textänderung auf den ursprünglichen Code minimal.

Ich hatte z.B. auch noch ein JavaScript entwickelt das vollautomatisch für IE4 und NC4 rechts platzierte Elemente erkennt und richtig positioniert, da ist per JavaScript, besonders natürlich mit Kenntnis der JSSS-Syntax, auch einiges möglich.

Es werden dann noch immer wieder genug andere Wege gezeigt oder sollten zumindest mit etwas Transfer naheliegen, so kann ein Stylesheet einfach per document.write erzeugt werden, dabei kann auch auf Variablen usw. zugegriffen werden, auch innerWidth, es geht auch ohne JSSS, ggf. sogar per Skript im Inlinestyle.

Und es ist auch möglich per sehr einfacher CSS-Weiche in einem einzigen Stylesheet ähnlich zu arbeiten, wobei dann die Verwendung von z.B. fontsize statt font-size im "Kommentar" eine zusätzliche Sicherheit darstellt.

Da sehr viele tableless-layouts, bei denen die Spalten per float realisiert sind, gezeigt werden, reichen oft schon die CSS-Weichen aus.

Mal ein konkreteres Detail:
wenn unbedingt Links (Linkliste) direkt (also ohne span oder in einer Liste) per border usw. und display:block als buttons dargestellt werden sollen, gibt es beim NC4 (wie auch bei Überschriften mit bestimmten Eigenschaften) u.U. Probleme.
Da muss nun wirklich nicht das CSS vor Netscape versteckt werden, einfach _eine_ Anweisung, in dem Fall wenn ich es recht erinnere border, vor NC4 verstecken und das grundlegende Layout, die logische Struktur bleiben erhalten, wer mag kann sinngemäß Farbe und Schriftgrösse für NC4 dem Zweck anpassen.
Meine Entscheidung für eine aufwändigere Lösung wäre hier auch nicht unbedingt alles per Div oder Span umzumodeln (auch keine nachträglichen dhtml-layer), ich würde wohl <ul> einsetzen und hätte dann evtl. neue Möglichkeiten, dazu ein m.E. stimmigeres HTML.

Jedenfalls die Seitenstruktur kann fast immer für NC4, IE4, oft sogar Opera3.6, erhalten bleiben, die meisten Formatierungen auch.
Es gibt also oft bereits genug Möglichkeiten mit vertrauten Techniken.

Grüsse

Cyx23