Die unterschiedliche Darstellung von Inhalten in verschiedenen Browsern liegt in der Natur der Sache. Auch wenn eine gleich bleibende Darstellung wünschenswert wäre, sollte dies nicht zu den obersten Prioritäten eines Webdesigners gehören. Wichtiger ist es, eine solide Basis zu schaffen, die Inhalte auch in älteren Browsern vernünftig lesbar macht. Doch auch hier kann es zu Problemen kommen, da selbst standardkonformer Code in unterschiedlichen Browsern oft seltsame Blüten treibt – gerade innerhalb der Browserfamilien sind die Ergebnisse oft verblüffend unterschiedlich.
In der Vergangenheit hat man sich hier, speziell bei den verschiedenen Versionen des Internet Explorers, gerne mit CSS-Hacks, wie etwa dem Star-Hack, beholfen. Diese basieren auf Unzulänglichkeiten des Browsers, doch sind entweder nicht schön, unsicher oder machen den Code gar invalide. Es geht eleganter.
Der offizielle Weg: Conditional Comments
Die Notwendigkeit, diesem Problem schnell von offizieller Seite aus beizukommen, hat Microsoft erkannt und dazu die so genannten Conditional Comments (kurz CCs) eingeführt, die sich auch heute noch steigender Beliebtheit erfreuen. Um etwa die ganze Internet-Explorer-Familie (ab Version 5) anzusprechen, verwendet man folgendes:
<!--[if IE]> Beliebiger Code <![endif]-->
Anstelle von “Beliebiger Code” können beliebige Inhalte notiert werden, etwa HTML-Tags, CSS-Anweisungen oder aber auch -Dateien, welche auch das Haupteinsatzgebiet dieser Technik darstellen. So ist es etwa möglich, eine CSS-Datei für alle modernen Browser einzurichten und darüber hinaus eine, die nur den Internet Explorer 6 anspricht, was aufgrund der zahlreichen Unzulänglichkeiten das häufigste Einsatzgebiet darstellt.
CSS-Datei für alle Browser:
<link rel="stylesheet" type="text/css" media="screen" href="styles.css"/>
Zusätzliche CSS-Datei, nur für IE6:
<!--[if IE 6]>
<link rel="stylesheet" type="text/css" media="screen" href="styles_ie6.css"/>
<![endif]-->
So hat man ein mächtiges Werkzeug, beliebige Deklarationen so anzupassen, dass auch der IE6 etwas damit anfangen kann bzw. sie überhaupt erst interpretiert. Die Vorgehensweise ist das dabei folgende: Zuerst werden sämtliche, für die Funktion der Website benötigten Styles in “styles.css” angegeben, egal ob der Internet Explorer 6 etwas damit anfangen kann. Im Anschluss werden diese in “styles_ie6.css” mit eigens für diesen Browser angepassten Deklarationen überschrieben.
Der Einsatz
Besonders zum Tragen kommt diese Herangehensweise bei CSS-Eigenschaften, die der Internet Explorer in der Version 6 noch nicht versteht, wie etwa in folgendem Beispiel:
.box {
border: 1px solid #000;
background: #fff59b;
width: 120px;
min-height: 120px;
}
Der zugehörige Aufruf in HTML:
<div class="box">Der Inhalt</div>
Während diese Box in moderneren Browsern eine Mindesthöhe von 120 Pixel erhält, passt sie sich im Internet Explorer 6 nur der Höhe des Inhaltes an. Für diesen Fall wird in “styles_ie6.css” zusätzlich zu obiger Deklaration folgendes notiert:
.box {
height: 120px;
}
So hat diese Box auch im IE6 eine Mindesthöhe von 120 Pixeln, da “height” von diesem Browser im Grunde wie “min-height” ausgelegt wird.
Des Weiteren ist es mittels der CCs möglich, in Spezialfällen für moderne Browser eine semitransparente PNG-Grafik einzusetzen und für den IE6, der diese nicht unterstützt, eine abgespeckte GIF-Datei.
In “styles.css” wird folgendes notiert:
.box {
border: 1px solid #000;
background: url(bg.png) right bottom no-repeat;
width: 120px;
min-height: 120px;
}
In “styles_ie6.css” wiederum darüber hinaus das:
.box {
background-image: url(bg.gif);
}
Hierbei muss darauf geachtet werden, anders zum obigen Aufruf die Eigenschaft “background-image” zu verwenden, um direkt das Hintergrundbild anzusprechen. Angaben zu “background-repeat” (“no-repeat”) oder “background-position” (“right bottom”) müssen jedoch nicht noch einmal getroffen werden.
Natürlich ist es so auch möglich, dem Internet Explorer 6 zu sagen, dass er gänzlich auf den Hintergrund verzichten soll, ist dieses doch nur schmückendes Beiwerk. Die Benutzbarkeit bleibt meist auch ohne erhalten:
.box {
background: none;
}
Mittels der Conditional Comments können aber auch ganze Gruppen angesprochen werden, etwa alle Internet Explorer kleiner Version 7 (“lt” = less-than):
<!--[if lt IE 7]> Beliebiger Code <![endif]-->
Oder aber auch die aktuelle Version des Internet Explorers inkl. aller zukünftigen Ausgaben (“gte” = greater-than or equal):
<!--[if gte IE 8]> Beliebiger Code <![endif]-->
Doch im umgekehrten Weg ist es auch möglich, eine CSS-Datei anzulegen, die alle Browser außer dem IE berücksichtigt (“!” = not):
<!--[if !IE]> Beliebiger Code <![endif]-->
Eine komplette Übersicht aller Operatoren findet sich im MSDN-Artikel.
Die Alternative: Das CSS Browser Selector-Script
Auch wenn die meisten Probleme von Unterschieden innerhalb der IE-Familie bzw. zwischen dem Internet Explorer und Browsern anderer Hersteller herrühren und mit den Conditional Comments gelöst werden können, gibt es doch immer wieder Fälle, in denen auch andere Browser, etwa Firefox und Opera, unterschieden werden müssen.
Hier kommt das exzellente CSS Browser Selector-Script (CSSBS) von Rafael Lima zum Einsatz, das mir schon sehr viel Kopfzerbrechen erspart hat.
Diese kleine JavaScript-Datei mit nur einer Größe von 2 kB wird einfach im Kopf der Website eingebunden und bietet die Möglichkeit, künftig alle gängigen Browser (und darüber hinaus) auf einfachste Weise unterscheiden zu können.
<script src="js/css_browser_selector.js" type="text/javascript"></script>
Das Script sorgt dafür, dass dem <html>-Tag je nach Browser spezifische Klassen zugewiesen werden, die dann mittels CSS-Selektoren angesprochen werden können.
Konkret wird hierbei zwischen dem Browser-Typ bzw. der -Version, dem Betriebssystem und ob JavaScript eingeschaltet ist oder nicht, unterschieden.
In Falle meines Entwicklungsbrowsers sieht <html>-Tag dann so aus:
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="de" lang="de" class="gecko ff3 win js">
Dies entspricht dem Firefox 3.5 unter Windows mit eingeschaltetem JavaScript:
- “gecko” ist der allgemeine Code für alle Browser, die auf der Gecko-Engine basieren (Netscape Navigator, Firefox, SeaMonkey usw.)
- “ff3″ spezifiziert diese Gruppe in Richtung der Firefox-Famile der Version 3
- “win” entspricht dem Betriebssystem Windows
- “js” sagt aus, dass JavaScript eingeschaltet ist, wobei dieser Wert natürlich erst gar nicht vorhanden ist, wenn der Browser keine Unterstützung dieser Sprache mitbringt bzw. sie ausgeschaltet ist
Der <html>-Tag eines Internet Explorer 7 unter Mac OS würde wiederum folgendermaßen aussehen:
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="de" lang="de" class="ie ie7 mac js">
Hier wiederum zeichnet “mac” das Betriebssystem Mac OS aus, “ie” steht für die Internet Explorer-Familie und “ie7″ spezifiziert diesen Wert in Richtung des Browsers IE7.
Zur Unterscheidung des Betriebssystems stehen aber beispielsweise auch folgende Codes zur Verfügung:
- linux
- freebsd
- iphone
Die Auswahl der Browser-Code wiederum ist ein ganzes Stück umfangreicher; ein Auszug:
- ie5: Internet Explorer 5.x
- ff3_5: Firefox 3.5
- opera10: Opera 10.x
- webkit oder safari: Safari, Google Chrome
- safari3: Safari 3.x
- chrome: Google Chrome
Unnötig zu sagen, dass OS- und Browser-Code natürlich miteinander verknüpft werden können:
.win.ie8 .box {
font-weight: bold
}
Hierbei muss beachtet werden, zwischen dem Selektor für Betriebssystem und Browser kein Leerzeichen zu machen.
Im Einsatz sieht man das Ganze auf der offiziellen Website. Je nach verwendetem Browser/Betriebssystem hat das Quadrat am Anfang der Seite eine andere Farbe. In meinem Fall – Firefox unter Windows – ist es rot, im Internet Explorer wäre es orange oder gelb (IE7) und in einem Webkit-Browser (Safari) schwarz. Auf dieser Seite findet sich weitere unten auch eine Übersicht über sämtliche Codes.
So ist es einfach möglich, jeder erdenklichen Kombination von Browser und Betriebssystem mit einer eigenen CSS-Anweisung beizukommen.
Die Einsatzgebiete
Alles schön und gut mag man sich nun denken, doch wie sieht dessen Einsatz in der Praxis aus, gibt es konkrete Anwendungsgebiete? Ja, laut meinen bisherigen Erfahrungen drei:
Conditional Comments im Entwicklungsbetrieb
Die für mich sinnvollste ergibt sich im Zusammenspiel mit Conditional Comments und dem Internet Explorer. Da die Handhabung von zwei unterschiedlichen CSS-Dateien – eine für moderne Browser, eine für IE(6) – im Entwicklungsbetrieb dann doch relativ aufwändig und fehleranfällig ist, bin ich zu folgender Vorgehensweise übergegangen: in Fall der Notwendigkeit einer IE-spezifischen CSS-Deklartion schreibe ich diese zuerst unter Verwendung der vom CSS Browser Selector zur Verfügung gestellten Klasse in die allgemeine CSS-Datei.
Der allgemeine Aufruf in “styles.css”:
.bullet {
padding-left: 12px;
background: url(bullet.png) no-repeat;
}
Der gleich im Anschluss folgende Aufruf für den Internet Explorer 6:
.ie6 .bullet {
background-image: url(bullet.gif);
}
Hier bekommt der Internet Explorer 6 beispielsweise eine eigene Grafik spendiert, da er die PNG-Version nur unzureichend darstellt.
Erst wenn ich mit allen CSS-Deklarationen auf diese Weise verfahren bin, kopiere ich sämtliche der IE6-spezischen in dessen eigene CSS-Datei (“styles_ie6.css”), die ich, wie oben beschrieben, mittels Conditional Comments eingebunden habe. Um das später auch nachvollziehen zu können, füge ich in der generellen CSS-Datei einen Kommentar hinzu, der mich auf diese alternativen Selektoren hinweist.
.bullet {
padding-left: 12px;
background: url(bullet.png) no-repeat;
} /* IE6 */
So ist man, speziell beim Testen, wie sich ein Problem im Internet Explorer am besten lösen lässt, weitaus schneller, als immer zwei CSS-Datei parallel zu bearbeiten.
Der kleine aber feine Browser-Unterschied
Das zweite Einsatzgebiet ist ein eher kosmetisches. Auch wenn ich mittlerweile selbst der Auffassung bin, dass Websites in unterschiedlichen Browsern nicht genau gleich aussehen müssen, gibt es doch Fälle, wo die Unterschiede so groß sind, dass man sie nicht tolerieren möchte. Ab und zu ist aber auch schlicht der Jagdinstinkt geweckt und man will, dass dieses eine Seitenelement auch wirklich überall gleich aussieht und erlebt werden kann.
Bisher war es aber sehr schwer bis unmöglich, Firefox, Opera oder Safari für sich alleine anzusprechen und schon gar nicht die unterschiedlichen Versionen. Gerade letzterer weist in seinen Versionen für Windows und Mac OS aber oft gravierende Unterschiede auf, die man nicht einfach so ignorieren kann oder will. Mithilfe des CSS Browser Selectors ist es nun aber ganz leicht möglich, mittels der Klassen “gecko”, “.opera” oder “.safari” auf diese Browser zuzugreifen.
Zudem kommt es immer wieder vor, dass der Internet Explorer 8 oder generell die IE-Familie so ihre Eigenheiten haben, es sich aber nicht lohnt, extra unter Zuhilfenahme der Conditional Comments und nur wegen ein paar Deklarationen ein eigenes Stylesheet anzulegen. Auch hier kann der CSSBS gute Dienste leisten, indem man diese Browser spezifisch mit “.ie8″ oder allgemein mit “.ie” anspricht.
Schöne, neue Welt: CSS3
Darüber hinaus kann der CSS Browser Selector auch im Hinblick auf neue CSS3-Eigenschaften zum Einsatz kommen. Im Grunde ist es hier zwar leicht, da nicht unterstützte, etwa “border-radius”, einfach nicht angezeigt werden. Andere wiederum werden von älteren Browsern nicht oder nur fehlerhaft unterstützt.
Beispiel “display: inline-block”: Während Firefox, Opera und Safari in den aktuellsten Versionen keine Probleme damit haben, wird diese Eigenschaft von Firefox 2 und Internet Explorer < 8 nicht ausreichend unterstützt. In diesem Fall greift man einfach auf mittels CSS Browser Selector eingefügten Klassen “.ff2″ bzw. “.ie6″/”.ie7″ zu und kann leicht alternative Eigenschaften, wie etwa “float: left” oder “display: inline”, anwenden. So muss man nicht auf erweiterte CSS3-Eigenschaften verzichten, nur weil ältere Browser diese mangelhaft darstellen.
Soll ich oder soll ich nicht?
Natürlich funktioniert all das nur bei eingeschaltetem JavaScript und ist im Grunde auch nur ein Hack, die Vorteile entschädigen dafür aber. Zudem ist JS heutzutage in etwa 95% der Fälle eingeschaltet und viele andere Features, die in modernen Websites zu finden sind, funktionieren ohne diese Programmiersprache ebenso nicht.
Hauptsächlich hängt der Einsatz des CSS Browser Selectors davon ab, welche Unterschiede sich in der Darstellung zwischen den einzelnen Browsern ergeben und wie groß die Motivation ist, diesen nachzugehen. Handelt es sich lediglich um kleine Ungereimtheiten, die die Benutzbarkeit der Website nicht beeinträchtigen oder man nicht den Anspruch hat, auf Browserunterschiede groß eingehen zu müssen, dann fällt die Daseinsberechtigung des Scripts schnell weg.
Stößt man hingegen auf Probleme, die große optische Unterschiede mit sich ziehen oder gar die Funktionalität der Website beeinträchtigen, geht die Motivation schnell flöten, wenn es keinen Weg gibt, diesen einfach beizukommen. Hat man doch einen nicht unbeträchtlichen Teil seiner Zeit damit verbracht, ein Design zu erstellen, das nun auch überall möglichst gleich angezeigt werden sollte. Gerade bei größeren Projekten mit umfangreichen Stylesheets gibt es nicht selten solche Fälle, in denen man einfach nicht tolerieren kann oder will, dass es auf unterschiedlichen Plattformen teils zu massiven Unterschieden kommt – und das trotz sorgfältig und standardkonform umgesetztem HTML-Code.
Anders sieht die Sache aus, wenn Ungereimtheiten innerhalb der Internet Explorer-Familie auftreten. Hier sind Conditional Comments klar die bessere Wahl, da sie an keinerlei Voraussetzungen gebunden sind und den offiziellen Weg für den Umgang mit solchen Problemen darstellen. Den Komfortzuwachs in Verbindung mit dem CSS Browser Selectors sollte man aber nicht unterschätzen.
Auf jeden Fall stellen sowohl Conditional Comments als auch das CSS Browser Selector-Script mächtige Werkzeuge im Kampf gegen allseits präsente Browserunterschiede dar, speziell in Kombination. Der Einsatz ist einfach und die Unterstützung bereits da bzw. schnell eingerichtet, es gibt also fast keinen Grund, der unter gegebenen Umständen gegen einen Einsatz spricht.
(sl)
Christian Krammer
Christian Krammer ist als Art Director für das Design des Onlineauftritts der österreichischen Tageszeitung Kleine Zeitung unter www.kleinezeitung.at verantwortlich. Das umfasst nicht nur die optische Komponente, sondern auch den zugrunde liegenden HTML-Code inkl. CSS
Also, ich kann mich an einige Sites ansprechen, wo der IE 6 die Ifs auf der Webseite im Klartext angezeigt hat. Da standen dann mitten im Text so sinnige Sachen wie “If support empty Paras endif”. Ich habe einige Jahre gebraucht, um die Ursache des Problems zu entdecken, offenbar ist das word-eignes Markup, das bei Copy and Paste in den WYSIWYG-Editor mitkopiert wurde. Bleibt die Frage, warum der IE 6 Markup im Browser anzeigt, der Firefox aber nicht.
Lange Rede, kurzer Sinn, bleibt die frage, ob die Ifs auch im IE 6 laufen.
JavaScript ist ein signifikantes Sicherheitsrisiko (vergl. z.B. heise Security) und deshalb – anders als behauptet – bei sicherheitsbewussten Usern (und fast allen Firmen) ausgeschaltet.
Wer gleichbleibende Darstellung wünscht und vielleicht auch noch berücksichtigt, dass heute User gleichermaßen mit PDA, Handy, Netbook und hochauflösenden Monitoren jenseits 22 Zoll surfen, wird ohnehin schnell begreifen, dass es zeitgemäßere Lösungen braucht und nach diesen Ausschau halten, bevor er über den Einsatz zweifelhafter Hacks nachdenkt.
PS: Wer aber als Art Director für das Design eines Onlineauftritts verantwortlich sein will, sollte erklären, weshalb der W3C Markup Validation Service 651 Errors / 399 warnings für eben diesen Onlineauftritt meldet. Anschließend sollte er diese (und andere) Fehler beseitigen und den ambitioniert neugierigen Besucher DIESER Website mit seinem dummen Geschwätz verschonen!
Ich weiss ja nicht wieso sich heutzutage noch jemand die Mühe machen will für so ein Geschwür wie den IE6 zu coden.
@Bernd: Javascript kann sicherlich ein Sicherheitsrisiko bedeuten, aber ich denke, Verursacher sind hier eher “einschlägige” Seiten, die bei Unternehmen nicht im Focus sind.
Es kommt letztlich auf Aufwendung und Zielgruppe an. Jedenfalls glaube ich, dass im Zeitalter von Ajax & Co. nicht mehr pauschal Javascript deaktiviert wird. Da greifen andere Mechanismen, um möglichen Sicherheitsrisiken vorzubeugen. Web 2.0 ist längst da, und die Entwicklung geht weiter. Tatsache ist nun mal, dass ohne Javascript ein großer Teil des Webs nicht nutzbar ist. Und das sage ich als jemand, der beim coden Javascript nach Möglichkeit vermeidet.
Das dritte Code-Bsp. (“Zusätzliche CSS-Datei, nur für IE6:”) ist flasch. Es müsste dort [if IE6] heißen. So wie es aktuell geschrieben ist, wäre es für alle IEs.
@Mark: Wollen und müssen sind zwei verschiedenen Dinge :-/
Wenn bei dem Kunden noch 25% der Zugriffe via IE6 erfolgen (kein Witz, vor wenigen Wochen erlebt), kannst Du dem gerne etwas von Web2.0, modernen Browsern und Geschwüren erzählen … es wird ihn wohl schlicht nicht interessieren – und das ja nicht zu unrecht.
“… da “height” in der standardkonformen Auslegung im Grunde der Eigenschaft “min-height” entspricht.”
Das ist genau falsch – nur in der Auslegung von IE6 entspricht height der Eigenschaft min-height, was so gar nicht standardkonform ist. Standardkonform ist es, wenn das Element auf die Höhe fixiert wird und unabhängig vom Inhalt weder grösser noch kleiner gemacht wird. D.h. die height-Angabe könnte in standardkonformen Browsern durch identische min-height und max-height Angabe ersetzt werden, was ja von der Theorie her auch Sinn macht (in der Praxis natürlich nicht).
IE6 vergrössert Elemente automatisch, wenn der Inhalt nicht mehr reinpasst, deshalb funktioniert height als min-height Ersatz – eine feste Höhe für ein Element erreicht man im IE6 nur, wenn noch an anderen CSS-Eigenschaften etwas verändert wird (wie z.B. overflow).
Und übrigens ist das Beispiel “IE7 für Mac” sehr weit hergeholt ;-) Evtl. wären da tatsächlich mögliche Browser+Betriebssystem-Kombinationen besser.
@Brot
Von wg. “… und fast allen Firmen …”: In sämtl.(!) Firmen – darunter größere (> 800 MA) und auch DAX-Konzern – mit denen ich die letzen Jahre zu tun hatte, war NIRGENDS JavaScript abgeschaltet. Aber IE6 als Standard ist nach wie vor oft anzutreffen, gerade bei den großen.
Zitat Wikipedia:
- JavaScript-Navigation: Barrierearme Webseiten zeichnen sich dadurch aus, dass sie auch bei abgeschaltetem JavaScript möglichst uneingeschränkt navigierbar bleiben. Oft schränkt das nicht aktivierte JavaScript die Benutzbarkeit einer Webseite ein.
- Bei anfälligen Webanwendungen kann JavaScript auch von Dritten missbraucht werden, etwa per XSS (Codeeinschleusung).
Ich verwende den Opera (der ist sicherer als FF/IE und kennt die genannten Darstellungs-Probleme nicht) und es gibt nur sehr wenige Ausnahmen, bei denen ich JavaScript einschalte.
Übrigens: Die Qualität der hier veröffentlichten Artikel hat in den letzten Jahren die Schublade ganz unten erreicht. Frage mich, wer für diesen ganzen Müll Geld bezahlt.
Wir haben noch 35% Geschwürbrowsernutzer. Ich frag mal meinen Cheffe nach seiner Meinung, wenn ich ihm 35% weniger Umsatz beschere, weil ich den IE6 nicht leiden kann.
Was Microsofts Drecksbrowser den Unternehmen kostet ist ein Waaaaaaahnsinn! Bin gerade dabei den doofen IE6 auch im Relaunch unserer Seite wieder zu berücksichtigen….
Hüüüüülfe :-(
Durch die zusätzliche Nennung von weiteren “Methoden” innerhalb eines CSS könnte dieser Artikel für Anfänger nützlich sein. Ich meine z.B. folgendes
Chrome und Safari
body:first-of-type element.klasse {
attribut:wert;
}
oder
@media screen and (-webkit-min-device-pixel-ratio:0) #id element { attribut:wert; }
oder etwas anders
@media all and (-webkit-min-device-pixel-ratio:10000), not all and (-webkit-min-device-pixel-ratio:0){
#id element { attribut:wert; }
}
hinzu kommt natürlich noch
* html .klasse element kindelement {attribut:wert;}
*+ html .klasse element kindelement {attribut:wert;}
und so weiter und sofort…
Ich finde man sollte keien älteren Browser mehr supporten. IE7+ ist gerade noch im Rahmen aber was man für IE6 an Design einbußen bzw. extremem Mehraufwand hinnehmen müsste ist schlicht inakzeptabel. Im Übrigen nutzen weit weniger als 35% IE6.
http://www.w3schools.com/browsers/browsers_stats.asp
es sind für alle 3 35%. Dieser Anteil an IE6 Nutzer entsteht fast nur dadurch das dämliche Firmen ihre Mitarbeiter nicht aufrüsten lassen. Ein Grund mehr für den IE6 body{display:none} zu schreiben, denn wenn die Mitarbeiter keine Webrecherchen mehr durchführen können müssen die Firmen fast ausnahmslos reagieren.
Zur Verteidung Mircosofts:
Außerdem sollte man sehen das als der IE6 rauskam er sowas wie Safari 4 oder FF 3.5 war. In 10 Jahren würden wir uns auch beschweren warum der Scheiss FF3.5 kein CSS 5 kann.
Desweiteren tut Microsoft ja(endlich) etwas dafür uns das Leben leichter zu machen ->Superpreview sei erwähnt, und wer sich den IE9 mal genauer ansieht muss zugeben das er bsw. nur 4 CSS3 Selektoren weniger findet als der FF(der findet alle 578) und auch ansonsten viel richtig macht. Das Antibeispiel hierzu stellt wohl der Opera 10 dar, der viel versucht aber fast nichts schafft(vorallem die vermurkste JS-Engine die bei normalen “validem” jQuery-Code (bsw. Validation Plugin) zig Fehler erzeugt.
Gruß
Alex
Nochmal etwas zu JS und Barriere-Freiheit:
Warum soll ich Einschränkungen im Design hinnehmen nur weil 0.00x% meiner User den Content dann nicht auslesen können? Ein Behinderter muss nunmal mit Einschränkungen Leben, zum Beispiel(angenommen er ist Blind) das er eben die Animation nicht erkennen kann. Glücklicherweise gibt es auch nur einen sehr zu vernachlässigenden Teil an Usern die so beschränkt sind wie #9 Martin Koehler, Denn wer JS ausschaltet hat nicht verstanden was das Web ist und welche Möglichkeiten es bietet. Eine Seite ohne JS(ausnahme RIAs) ist höchstens 75% so gut wie eine mit JS. Abgesehen davon das Opera nicht als Browser sondern eher als mutierendes Anti-Standart-Monster bezeichnet werden kann.
@Bernd das Brot
Ein Art-Director ist für das Design und nicht die Umsetung zuständig….
JS ist kein “Signifikantes Sicherheitsrisiko” es könnte(!) eines sein, aber dann würden ja 95% der User einem deiner Darstellung nach untragbarem Risiko unterliegen, aber den 95% scheint es nicht so schlecht zu gehen mit diesem Risiko.
http://www.w3schools.com/browsers/browsers_stats.asp
(weiter runterscrollen)
Das Gerede vom “unsicheren” Javascript ist so eine Art “Beisskrampf” in der Szene; wenn man an Flash und Pdf ähnliche Ansprüche in punkto Sicherheit stellen würde, dann gute Nacht.
Vielen Dank für euer Feedback.
@domingos
Deshalb stehen die Conditional Comments ja in einem HTML-Kommentar. Falls Sie trotzdem sichtbar sind, wurde das vermutlich nicht berücksichtigt.
@Bernd das Brot
Das kann ich leider nicht nachvollziehen. Wenn ich mir die Statistiken unserer Website http://www.kleinezeitung.at ansehe, und die hat mehrere Mio. PIs pro Monat, dann haben um die 95% JavaScript eingeschaltt. Und wie Flavour richtig schreibt: In Zeiten von Ajax und Web 2.0 benötigen viele andere Inhalte ebenso JavaScript. Abgesehen davon: Wenn man auf den angesprochenen CSS Browser Selector vertraut und JavaScript ausgeschalten ist, ist das ja kein Beinbruch, denn die Website bleibt ja trotzdem benutzbar.
Zu den angesprochenen 651 Errors / 399 warnings kann ich leider nur so viel sagen, dass ich das nicht beeinflussen kann. Alle HTML-Templates verlassen meinen Arebitsplatz mit validem HTML und CSS. Was die die “Techniker” im Anschluss daran machen, kann ich leider nur sehr begrenzt beinflussen. Glaub mir, es wäre auch mir ein Anliegen, eine “reine” Website zu haben.
@mark
Doch, auch heute ist es nötig, speziell auf den IE6 Bedacht zu nehmen. Durchschnittlich 15% unserer User surfen nach wie vor damit, und die kann man ja schlecht vor den Kopf stoßen.
@Stefko
Danke für den Hinweis, ist korrigiert.
@Andreas
Ich habe diese Aussage etwas deutlicher gemacht. Abgesehen davon ist das Ansichtssache: Im Grunde ist es ja so, dass height für den IE6 ist, was min-height für andere Browser darstellt. Eine Fehler ist es natürlich so oder so.
Stimmt, der IE7 unter Mac OS ist vielleicht kein praxisnahes Beispiel, sollte aber einfach klar verdeutlichen, was theoretisch möglich wäre.
@Mediengestalter
Ich weiß jetzt nicht genau, worauf du hinaus willst. Du meinst, es wäre einfacher, unterschiedliche Browser mit deinen Methoden anzusprechen? Habe damit leider keine guten Erfahrungen gemacht, da man nie weiß, wie zukünftige Versionen eines Browser auf solche “Angaben” reagieren.
Also mit dem IE6 halte ich es so: Explizite Berücksichtigung des IE6 vermeide ich wo es geht und empfehle sie meinen Kunden auch nicht mehr. Wenn ein Projekt groß genug ist, dass man eine Version für mobile Browser anbieten kann wird der IE6 eben in diesem Rahmen berücksichtigt.
Man sollte aber bedenken, dass in anderen Teilen der Welt durchaus noch uralte Browser weit verbreitet sind. Neulich im Urlaub bin ich tatsächlich noch auf einen Firefox 1.5 gestoßen. Je internationaler das Projekt und je breiter die Zielgruppe desto sinnvoller ist es, auch uralte Browser noch irgendwie zu berücksichtigen.
Öhm warum mit JS den Browser auslesen wenn das auch mit php geht ($_SERVER['HTTP_USER_AGENT'])?
was ist wenn die Webseite offline zu nutzen ist – da hast Du kein php…
@Christian Krammer
Genau, height ist im IE6 wie min-height – dafür gibt es kein tatsächliches height im IE6 :-) Wobei das für die meisten Webprojekte vermutlich nicht so relevant ist.
Bezüglich der ganzen Diskussion wegen IE6 oder nicht – meiner Meinung nach reicht es, wenn die Seite im IE6 benutzbar ist, das ist mit relativ geringem Aufwand erreichbar (wenn man sich schon etwas mit den Mängeln von IE6 auskennt). Wenn die Darstellung nicht pixelgenau ist, kann man das mittlerweile übersehen. Ebenso kann man z.B. durchaus transparente PNGs verwenden – sehen im IE6 nicht so schön aus, aber sind trotzdem gut identifizierbar und ändert nichts an der Benutzbarkeit der Seite.
Ein guter Test ist übrigens auch, die eigenen Seiten mal mit IE4 oder IE5 anzuschauen, und auch mit reinen Textbrowsern – wenn man eine Seite damit noch bedienen kann (ohne dass man dafür optimiert hat o.ä.), dann hat man eine wirklich gut strukturierte und bedienbare Seite. Darauf kommt es viel mehr an als dass die Darstellung exakt stimmt.
Ich verstehe das ganze Gejammer um den IE6 nicht.
Ok für Anfänger bzw. Gelegenheitscoder öffnen sich so manche Hürden, aber wenn gestandene Webworker immer noch massive Probleme haben, dann sollte man doch nochmal das ein oder andere Buch über HTML und CSS inhallieren.;-)
Vielleicht git es ja eins zu Weihnachten.
Frohes Fest
Guter Beitrag. Wesentliche Probleme aufgezeigt und Lösungsansätze geboten.
Danke!
ledzep
Eine sehr interessante (und für mich: bessere Variante ist dieses hübsche Tool hier):
http://www.conditional-css.com/index
Ein kurzer Blick hinein schadet auf keinen Fall ;)
Also für mich als Anfänger ist das ein wirklich informativer Artikel, der mir weiterhilft. Ich finde außerdem, dass man nicht jedes mal wieder die IE6 und Javascript ja/nein Streiterei anfangen muss. Im Artikel werden die Vor- und Nachteile ja schon diskutiert.
Nach einem halben Jahr intensiver Auseinandersetzung mit ‘barrierefrei’ und css habe ich den Eindruck, daß sich hier Leute, die normalerweise für Farben, Formen, Zeitgeist zuständig sein sollen, einen undurchsichtigen Codesalat zurechtgelegt haben und damit endlich das Gefühl geniessen wollen, als ‘Pogrammierer’ durchzugehen.
CSS. So eine von Grund auf verballerte Darstellungssprache kann doch nicht von konzeptionell-strategisch handelnden Fachleuten entwickelt worden sein. Dabei wäre dieser “neue Wurf” nie nötig gewesen, denn mit SVG/xml (sgml) und der pixelgenauen Druckersprache latex, bzw tex ist eigentlich schon seit ca 24 Jahren alles vorhanden und bietet weit mehr Möglichkeiten als das derzeitige css, viel kontinuierlicher in der Kodierung, intuitiver in der Anwendung. Die Umsetzung scheiterte nicht nur an der Industrie, allen voran des Microsoftkonzerns, auch die Webdesigner sind im Gro dermaßen phlegmatisch, daß man ihnen zuerst nur mit ein bischen css, dann ein Häppchen mehr und jetzt das voll-Stoff-total-css beikommen mußte. Ich habe diese Verrenkungen nach den Doofen und den Geldgieren so satt. Übrigends mit smil, auch ein svg/xml, wäre flash, ajax und javascript völlig überflüssig. Es sind im Prinzip alles Unterformen und Dialekte des sgml, und damit wäre für jeden sozusagen nur eine Basis zu erlernen gewesen – und jetzt? Jetzt bleibt auch mir nichts anderes übrig als dieses Hüpfekästchen mitzuspielen. Was will mein Artikel, außer: Es könnte auch alles viel einfacher sein und das seit einem viertel Jahrhundert:
Solange halt Ignorantentum wegweisend Webseiten gestalten darf und ie6 mit einbezieht, bleibt allen anderen auch nichts anderes übrig. Aber warum eigentlich nur ie6, alle ie stellen falsch dar. Hier ist keine Weiterentwicklung im Blick, einfach nur eine Unart sich abzuschotten.
Abstand zu Konkurenten zu gewinnen ist ein sportliches, gutes Ziel, aber bitte mit Innovationen. Man kann doch nicht einfach als Riesenkonzern mal eben Ampeln herstellen, die von Lila über Ocker nach Orange den Verkehr stoppen. Es ist gut dass alle Welt bei Rot anhält und bei Grün weiterfährt, da braucht es niemanden, der mit wunderschönen anderen Farben unseren Verkehr was bunter macht. Unsere Gesellschaften haben, mit Hängen und Würgen, endlich alle Lesen und Schreiben gelernt (94% aller über 18jährige). das hat mit zu großem Wohlstand beigetragen. Nun leben wir in einer Informationsgesellschaft, Informationen müssen übersichtlich, augenfreundlich aufbereitet und möglichst überall abrufbar sein. Das wird unserem zukünftigen Wohlstand eine wichtige strategische Stütze sein. Aber was passiert? Da tanzen ganze Gruppen von Konzernen aus niederen Beweggründen und auf Kurzsichtigkeit bedacht auf unseren Möglichkeiten herum, und eine riesige Schar unglaublich lernunwilliger Webdesigner hüpfen hinterher, ja sogar das W3C-Konsortium hat davor kapituliert und die lang erhoffte xml-Revolution begraben, noch bevor sich davon auch nur ein Krümelchen in die dumpfen Weiten kleiner Designerköpfe niederlassen konnte. Und es ärgert mich diesen Leuten folgen zu müssen, denen ich sonst so kunstvoll ausweichen kann, wenn ich meine Informationen ins Internet barrierefrei eingeben will – natürlich barrierefrei, wenn es irgendwie möglich ist und das ist es ja.
Den Spruch, “Behinderte müssen eben mit Behinderung leben” (hier irgendwo geschrieben worden) ist so dermaßen … ich denke, ich höre jetzt mal besser auf und hoffe, daß es unter den Webdesignern bitte endlich mehr gibt, die mal über ihren Tellerrand blicken und sich nicht mehr von Konzernen ihre Arbeitsmittel diktieren lassen, nur weil die da kurzfristig eine Marge ausschöpfen können.
Dieses ganze CSS und Browsergeblähe ist hoffnungsloser Mist, Informationsaufbereitung und -einstellung wird damit künstlich barriiert und das ganze auch noch als Fortschritt verkauft, Webdesigner bekommen auf Kosten der Informationsgesellschaft eine Art Renomee des Programmierers, haben aber sonst nichts davon. Behielte man die einfachen gut erprobten Mittel zur Informationsgerstaltung, könnte sicherlich jeder einfach Informationen aufbereiten, so wie jeder eben auch Lesen und Schreiben kann. Es wird auch dann große Unterschiede zwischen Profis und Amateuren geben, das Lesen und Schreiben macht auch nicht aus jedem einen Journalisten, oder guten Autoren.
Wenn man einigermaßen eine Webseite an ein Content Management System anpasst, kann man dies auch ohne die Browser anzusprechen.
Außerdem wie viele Leute hier schreiben, sind bei vielen Usern Javascript ausgeschalet, da es ein großes Sicherheitsrisiko ist.
Meiner Meinung nach sollte man mit den “Hacks” nicht arbeiten!
Ob nun Javascript in der einen Statistik bei 95% in der anderen 75% ist doch irrelevant. Das gleiche gilt denk ich auch für IE6-Nutzer etc.
Die Frage die sich jeder stellen sollte ist doch wohl eher: Wie sieht es bei meinen (zukünftigen) Usern aus (und wie groß ist die Bereitschaft JS/Cookies einzuschalten (Bsp. personalisierter Content, Userpages etc.))?
Meine persönliche Meinung zu Javascript: Default-Einstellung aus; seitenspezifisch einschalten. (was Opera ja auch schon Ewigkeiten unterstützt, FF hat da ja IIRC mit 3.0 nachgezogen)
Ich denk auch die Entscheidung zwischen CCs und Hacks ist Projekt- und Erfahrungsabhängig. Eben je nach Umfang der “Fehler”, zusätzlicher Requests etc.
@ 23:
“Dabei wäre dieser “neue Wurf” nie nötig gewesen, denn mit SVG/xml (sgml) und der pixelgenauen Druckersprache latex, bzw tex ist eigentlich schon seit ca 24 Jahren alles vorhanden und bietet weit mehr Möglichkeiten als das derzeitige css, viel kontinuierlicher in der Kodierung, intuitiver in der Anwendung.”
Zwei Anmerkungen:
1. LaTeX ist eine DRUCKERsprache, schön beschrieben.
2. LaTeX ist das in keiner Weise intuitiv oder kontinuierlich. Wenn man sich damit nur minimal auseinander gesetzt hätte, würde man merken, dass man a) für jeden Mist ein eigenes Paket braucht, b) bei jedem Paket eine eigene Benennungsstrategie herrscht,
Außerdem will man auf einem Bildschirm ja gerade KEINE pixelgenauen Layouts, da man diese nicht skalieren kann.
Hallo alle, danke erstmal CK für die nette Lösung. Allerdings wäre es fein, wenn man FF AB v 3.5 selektieren könnte (also auch 3.6 mit erwischt). Der wird nämlich bis jetzt wie 3.0 erkannt.
Hintergrund: Verwendung von @font-face, was meines Wissens erst ab 3.5 – und eben auch in 3.6 – läuft.
Mir ist es zwar gelungen das js soweit anzupassen, dass es 3.6 erkennt – aber nicht 3.5 UND 3.6. Dazu reichen meine äußerst dürftigen js-Kenntnisse leider nicht aus…
Ansonsten denke ich, dass die Diskussion, ob man dererlei ÜBERHAUPT anwendet, hier fehlplaziert ist.
Sonnige Grüße aus Berlin
Nachsatz: Hat sich erledigt! Habe nur dies hier:
:is(‘firefox/3.6′)?g+’ ff3 ff3_5′
nach dem hier:
:is(‘firefox/3.5′)?g+’ ff3 ff3_5′
ins js eingefügt.
Ginge sicher auch eleganter (kürzer) aber – alles gut…