#: Keine Stylesheets zu sehen

Das kann verschiedene Ursachen haben:

1/ NN4 only: Netscape 4-Browser benützen zur Darstellung der Stylesheets die interne JavaScript-Engine. Wenn diese z.B. aus Sicherheitsgründen ausgeschaltet ist, kann auch kein CSS angezeigt werden.

2/ NN4 only Bei externen Stylesheets: Bei der Einbindung der Stylesheets mit Hilfe des HTML-Elementes LINK, kann auch das Attribut MEDIA verwandt werden. Wenn dieses Attribut aber ungleich "screen" ist (also z.B. "all", oder "print"), wird es von Netscape 4 ignoriert. Ist neben dem "IMPORT-Trick" eine weitere Möglichkeit NN4-spezifische Stylesheets einzubinden. [NN4.x]

3/ Externes Stylesheet only: Möglicherweise wird das Stylesheet vom Browser nicht verstanden, da es nicht als CSS- sondern als Textdokument vom Browser geliefert wird. Siehe weiter unten. Für diese Sensibilität sind einige Versionen des Mozilla-Browsers (und damit Netscape 6.x und des IBM-Browsers) bekannt.

#: Einiges CSS nicht zu sehen

Eine Zeit lang war in den CSS-Standards des W3Cs festgeschrieben das Underscores ("_", Unterstrich) als Zeichen in Class-namen nicht erlaubt seien. Darauf haben viele Browserhersteller reagiert (z.B. N6) und solche CSS-Klassen ignoriert.

Inzwischen gibt es jedoch ein "Errata" zu den entsprechenden W3C-Spezifikationen, die den Einsatz von Underscores wieder erlauben. Nun müssen noch die Browserhersteller nachziehen... (siehe Mozilla)

#: Netscape Navigator 4

Pauschal lässt sich kein Urteil bilden, wo das Problem liegt. Allerdings ist es bekannt dass Netscape 4 grosse Probleme mit dem "Verstehen" von CSS-Code besitzt. Seine grössten Schwachstellen sind der Umgang mit margin, padding sowie Positionierung, sowie die Anwendung auf bestimmte Inline-Elemente wie IMG.

Hier einige Links mit weiterführenden Hinweisen:

• http://www.saila.com/usage/layouts/nn4-layouts.shtml
• http://www.mark.ac/web/cssnn4.php
• http://css.nu/pointers/bugs-nn.html#NN4
• http://www.utoronto.ca/ian/books/xhtml2/exerpt/css-4a.html#three
• http://developer.netscape.com/support/bugs/known/css.html
• http://www.richinstyle.com/bugs/netscape4.html
• http://www.mako4css.com/Issues.htm
• http://www.bobsawyer.com/nn4css.html
• http://www.macedition.com/cb/nn4crashers/index.html
• http://www.websitetips.com/css/

[NN4.x]

#: Microsoft Internet Explorer 6 / Windows

• Guillotine-Bug: siehe CSS > Layout > Guillotine-Bug
• Sprünge beim Resizing: siehe CSS > Layout > Rundungsfehler

[IE6/Win]

#: Opera

• Das overflow-Attribut ist nur eingeschränkt einsetzbar. overflow: scroll; wird wie overflow: hidden; gehandlet, overflow: auto; wird wie overflow: visible; gehandlet. [Op3, 4, 5]

#: IE6: Plötzlich wird die Seite abgeschnitten (Guillotine-Bug)

Beispiel: Man hat eine sehr lange Seite. Man hovert über einen Link, der die Hintergrundfarbe des Links (background-color) ändert verändert. Plötzlich wird die Seite unten abgeschnitten, und man kann z.B. nicht weiter runterscrollen.

Vermutliche Ursache: Wenn dynamisch (z.B. bei Hover oder via Script) Layout-CSS-Attribute (background, padding, margin, display) verändert werden, scheint IE6 den Content neu und unvollständig einfliessen zu lassen. Dies trifft wohlgemerkt nur im "standard mode" zu.

Workaround: 1/ Inhalte via CSS auf position: relative; setzen (P, DIV-Elemente), 2/ BODY auf position: absolute; setzen (was wiederum zu Problemen mit N6+ führen kann), 3/ Wenn das Problem in Verbindung mit float auftritt, am Ende des float-Contents eine zusätzliche Zeile mit clear: left; (oder right) setzen

Links: Evolt, Dreamworker, LANtastic

[IE6/Win]

#: IE: Beim Verändern der Browsergrösse "springen" einige Objekte.

Bei Maßen die in Prozenten angegeben sind, rechnet der IE die Maße in Pixel um und rundet dabei kaufmännisch ab. Dabei entstehen Situationen in denen Objekte eben nicht 100% breit sind, sondern 100% + 1 Pixel.

[IE]

#: Unsichtbarer Rand an den Seiten

CSS-Alternativen zu den HTML-Attributen marginheight, topmargin etc...?

Von Hause aus stellt jeder Browser eine HTML-Seite mit einigen Pixeln Abstand zum Browser-Fenster dar. Um diesen Abstand wegzubekommen, hat Netscape zwei eigene Attribute und Microsoft zwei eigene Attribute für das BODY-Element eingeführt: topmargin, leftmargin bzw. marginheight und marginwidth. Diese wurden allerdings nie in den offiziellen HTML4-Standard aufgenommen, stattdessen wurde eine CSS-Alternative empfohlen.

Die Alternative setzt das CSS-Attribut margin und padding (für Opera) für das BODY-Element auf 0.

body {margin: 0; padding: 0;}

Dummerweise sind die Netscape 4-Browser nur sehr begrenzt in der Lage diese beiden CSS-Attribute korrekt darzustellen. Daher gibt es eine weitere Alternative, die allerdings zu Nebenwirkungen führen kann, und daher mit Vorsicht zu geniessen ist:

body {position:absolute; top:0; left:0;}

#: Rahmen bei verlinkten Bildern entfernen

Wenn Bilder verlinkt werden (<A href="test.html"><IMG src="test.gif"></A>) werden automatisch Rahmen in der Linkfarbe um diese Bilder herum gezeichnet. Das IMG-Element kennt das border-Attribut dass sich auf Null setzen lässt (border="0") und dadurch solche Rahmen verschwinden lässt.

Das border-Attribut ist aber im HTML4-Standard "depreciated", also unerwünscht. Stattdessen soll man zur CSS-Alternative greifen.

Und die lautet: a img {border:none; color:white}. Als Selektor wird a img benützt. Das heisst es werden die Attribute von allen IMG-Elementen gesetzt, die in A-Elementen geklammert sind, also verlinkte Bilder eben. Border wird mit dem Wert none ausgeschaltet. Da NN4-Browser ihre Probleme mit dem Border-Attribut in CSS haben, wird zusätzlich die Rahmenfarbe auf weiss gesetzt (vorausgesetzt der Seitenhintergrund ist weiss), so dass NN4 zwar immer noch einen Rahmen zeichnet, der aber unsichtbar, weil in Hintergrundfarbe gezeichnet. Diese Methode hat aber bei NN4-Browsern den Nachteil das pixelgenaue Layouts auseinanderfliegen, da der Rahmen eben doch gezeichnet wird, und dadurch sich ein Abstand von 2 Pixel ergibt.

#: Wie kann ich Objekte zentrieren?

Es kommt darauf an, was wo wie zentriert werden soll...

Inline-Objekte horizontal zentrieren

Eim einfachsten ist es wenn Text oder anderer "Inline"-Content horizontal zentriert werden soll: der "übergeordnete Container" braucht ein text-align: center; (als IE5-Hack). Einige schwören darauf das zusätzlich der Container selber noch ein margin-left: auto, margin-right: auto braucht.

Block-Elemente horizontal zentrieren

Block-Elemente können zentriert werden mit: margin-left: auto; margin-right:auto; [N6, IE55+/Win, IE5/Mac, Op3+]

Inline-Elemente Vertikal zentrieren

Hierfür gibt es bereits eine CSS-Property, die allerdings nur auf Inline-Elemente und seit CSS-2 auch auf Tabellenzellen-Inhalte anwendbar ist:

vertical-align: middle. Siehe auch CSS > Code > vertical-align

Block-Elemente Vertikal zentrieren

Dies ist der Fall der am meisten Kopfschmerzen bereitet. Als Hintergrundinformation: Mit CSS-2 wurde eine neue Vorschrift eingeführt die besagt: Ein "Container" ist nur so groß wie sein Inhalt (mindestens aber so groß wie die Zeilenhöhe line-height). Das Vertikal-Zentrieren scheitert hier also bereits an dem Umstand, dass man den den Inhalt umgebenden "Container" gar nicht so hoch aufgespannt bekommt, wie man es gerne möchte, um z.B. ein Bild auf einer HTML-Seite zu zentrieren.

Es gibt zwar eine Reihe von Workaround, aber noch nichts was den Konsensus der CSS-Gemeinde gefunden hätte. Für CSS-3 steht zwar ein "richtiges" vertical-align und ein min-height in Aussicht, aber selbst wenn CSS-3 2002 noch abgesegnet wird, bis es aufgrund der Verbreitung von CSS-3-fähigen Browsern praktikabel ist, dürfte es noch bis ca. 2008, 2009 dauern...

Workaround: body { margin: 0px auto;}

Workaround: img { margin: 0px auto; }

Workaround: display-Type der Elemente von block auf table setzen und dann mit vertical-align arbeiten [Mozilla, Opera]

Workaround: <div style="position:fixed; top:50%; left:50%;">
<div style="position:relative; top:-50px; left:-100px;">
<img src="bild.jpg" width="200" height="100">
</div>
</div>
Dieser Hack funktioniert nicht in IE4/Win - IE6/Win, da dort position:fixed; nicht unterstützt wird. Aber es gibt einen JavaScript-Hack.

#: Wie kann ich mit CSS eine "frame-likes" Menü einrichten, also ein Menü das an seiner Position "kleben" bleibt, egal wie ich die Seite scrolle.

Mit position: fixed. Leider funktioniert es in keinem Windows-IE, auch nicht IE6. Aber es gibt einen JavaScript-Hack um dieses Problem zu umgehen.

#: Gibt es einen Workaround um position:fixed; auch unter IE6/Win laufen zu lassen?

Ja, es gibt einen JavaScript-Hack von Andrew Clover: http://and.doxdesk.com/software/js/fixed.html

#: Kann ich unter NN4.x Bildern einen Rahmen geben?

Ja, via HTML mit <IMG border="1"<. Die CSS-Lösung mit border= solid black 1px; funktioniert im NN4 nur wenn es auf einen DIV-Container angewandt wird, nicht auf das IMG-Element selber!

#: Meine Links reagieren nicht auf das Rüberrollen der Maus (Hover-Effekt)

Ein Anfänger-Fehler ist die falsche Reihenfolge der "Pseudo-Klassen". Da die Pseudo-Klassen sich "gegenseitig überschreiben", sollte das Ereignis was die "höhere Priorität" hat, später definiert werden. Beispiel für das Überschreiben: Bei einem Rollover über ein bereits besuchten Link, werden zwei Pseudo-Klassen gleichzeitig angesprochen: hover und visited. In der falschen Reihenfolge gesetzt, wird auf den Link die Definition für hover und dann visited angewendet. visited überdeckt also hover. Daher kommt zuerst die Definition für alle Links, die linked-Pseudo-Klasse, dann für die bereits besuchten Links (visited), dann für das Rollover-Ereignis (hover) und zuletzt das Klick-Ereignis (active).

a:link { color: #666; }
a:visited { color: #666; }
a:hover { color: #fff;}
a:active { color: #666; }

#: Fontgrösse in Pixel oder em oder Prozent?

Früher war man aufgrund starker Unterschiede in der Darstellung gerade zu gezwungen "Pixel" zu nehmen, statt einer relativen Grössenangabe. Heute stellt sich die Situation etwas differenzierter dar.

Vor-/Nachteile von Pixel

-: IE/Win (bis inkl. v6) können Texte nicht mehr zoomen.

Vor-/Nachteile von relativen Angaben (Prozent, em)

+: Die Schriftgröße passt sich den Voreinstellungen des Users an, der z.B. die Schriftgrösse seines Browsers auf einen höheren Wert als 16px eingestellt hat, um Texte in seinem hochauflösenden Monitor besser lesen zu können.

-: NN4 und IE5/Win unterscheiden sich sehr stark in der Darstellung von Prozenten.

Vor-/Nachteile von Schlüsselwörter (small, medium etc...)

-: IE4 - 5.5/Win rendert diese Schriftgrössen falsch. Opera kopiert aus Kompatibilitätsgründen das falsche Verhalten.

#: IE5/Mac: Fonts nicht grösser als 255 Pixel?

Es sieht so aus, als würde der IE5/Mac Schriftgrössen in einem Byte abspeichern. D.h. Schriften grösser als 255 Pixel werden wieder beginnend bei 0 Pixel dargestellt: 256 Pixel = 0px, 257px = 1 px etc... [IE5/Mac]

#: In welcher Relation stehen HTML-Inhalte, das BODY-, das HTML-Element, und die Browsergrösse zueinander?

Die HTML-Seite besitzt folgenden Aufbau:

<HTML>
   <BODY>
      Content
   </BODY>
</HTML>

Der Browser kennt zwei Grössen-Werte: 1/ Die Grösse der Webseite die durch das HTML-Dokument generiert wird, 2/ Der "Viewport": der Ausschnitt der von der Seite gerade dargestellt wird (in Abhängigkeit wie groß der Browser aufgezogen ist).

Alle Elemente im HTML der Webseite, generieren "Container", sogenannte Blocks die teils untereinander abfolgen, teils ineinander verschachtelt sind. Es gibt nun in den CSS2-Standard wiedersprüchliche Informationen und Auslegungen welches der alleroberste Block, der "Ursprungsblock", ist. Mal ist es der sog. "initial containing block" (ICB). Mal ist es "Root" (also das HTML-Element).

Das Problem scheint die Auslegung der entsprechenden Passi in dem CSS-Standard (CSS-2) zu sein, da sich Punkt 9.1.2 und 10.1 in dem Punkt widersprechen, wo der ICB liegt. Ob der ICB in Root liegt, oder umgekehrt...

Interpretation nach 9.1.2: Hier erzeugt Root den ICB. Root, die Spitze des "document tree" wird durch das HTML-Element definiert. Die Breite des ICBs kann durch das width-Attribut des HTML-Elementes definiert werden.

Interpretation nach 10.1: Der ICB wird vom User-Agent definiert, ist daher nicht standardisiert. Root liegt im ICB. Im Root liegen die anderen Blocks. Die Positionierung der Blocks geschieht in Abhängigkeit ihres "Parent-Blocks". Wenn der Block das Attribut position: fixed; enthält, wird ein Block gemäß des viewports positioniert. Wenn der Block das Attribut position: absolute; enthält, wird der Block gemäß des "Großeltern-Blocks" positioniert.

Konsequenz: Es bestehen verschiedene Interpretationen darüber, was passiert wenn man Root/HTML auf height: 100% setzt. Im Falle von 9.1.2 ist die Root-Höhe nicht spezifiziert, im Falle von 10.1 ist die Root-Höhe abhängig von den Browsern.

Interpretations-Konsens bei den Auguren vom W3C ist dass die height des ICBs undefiniert ist. Wer die Höhe eines Containers in Abhängigkeit der Browser-Höhe, also des viewports machen will, kann das nur über position: fixed; erreichen.

Link: W3C-Thread "% height on html"

#: Die Browser benützen eigene CSS-Attribute. Welche? Warum?

Irgendwann sahen die Browser-Hersteller die Notwendigkeit, CSS um eigene Attribute zu erweitern. Sei es, weil man Lücken in den CSS-Spezifikationen sah, sei es weil man solche Attribute zu internen Zwecke braucht. Mozilla, zum Beispiel, zur Darstellung der Benutzeroberfläche.

In Absprache mit dem W3C wurden für proprietäre CSS-Properties die Benamung nach dem Schema "MinusstrichHersteller-Property" vorgesehen, also so wie es Mozilla umgesetzt hat ("-moz-binding").

Dies wirft einige programmiertechnische Probleme auf, da sich dadurch eine Property "-moz-dingenskirchen" schwer von einem Minuswert "-123" unterscheiden lässt. Daher hat sich das W3C breitschlagen lassen und auch noch den "underscore" zur Einleitung von browser-proprietären Browsern zugelassen: "_kai-dingenskirchen". Das W3C wird keine offiziellen CSS-Attribute mit "underscore" beginnen lassen. (Quelle: www-style)

Mozilla, Netscape 6+, Opera: Diese Erweiterungen wurden von den Entwicklern als eine Art "Hack" benützt um bestimmte browserinterne Funktionalitäten zu erreichen.

Mozilla/Netscape besitzt verschiedene Kategorien von proprietären Attributen. Ein Teil der Attribute wird intern zur Darstellung des Browser-Interfaces benötigt. Ein anderer Teil der Attribute nimmt zukünftige CSS3-Entwicklungen vorweg. Alle diese Attribute haben ein -moz- vorneweg.

Hier z.B. die Attribute die für das Interface verwendet werden: -moz-binding, -moz-border-radius, -moz-border-radius-[Corner], -moz-border-[Side]-colors, -moz-opacity, -moz-outline, -moz-outline-color, -moz-outline-style, -moz-outline-width, -moz-user-focus, -moz-user-input, -moz-user-modify, -moz-user-select

Darüber hinaus gibt es acuh eine Anzahl eigener Properties für standardisierte Attribute. Mehr Infos zu dem proprietären Mozilla-CSS hier.

Opera benützt drei eigene Properties in einem eigenen, internen Stylesheet zur Verarbeitung von XML bzw. WML-Dokumenten. Opera empfiehlt ausdrückliche diese Attribute nicht zu verwenden [1]. Die Attribute werden mit - eingeleitet.

Microsoft: Etwas anders verhält es sich bei den Microsoftschen Erweiterungen (Übersicht). Diese werden nicht für interne Zwecke benötigt, und sind von Microsoft ausdrücklich zur Verwendung durch Entwickler freigegeben. Von diesen Erweiterungen sind nur ein Teil inzwischen dem W3C zur Abnahme übergeben worden, aber alle MS-Erweiterungen halten sich leider nicht an der Nomenklatura mit dem einleitenden "Minuszeichen" oder "Underscore".

Nicht dem W3C vorgeschlagen: text-underline-position, word-wrap, layout-flow, scrollbar-3dlight-color, scrollbar-arrow-color, scrollbar-base-color, scrollbar-darkshadow-color, scrollbar-face-color, scrollbar-highlight-color, scrollbar-shadow-color, text-overflow, zoom

Dem W3C vorgeschlagen, aber noch nicht in den CSS-Standard aufgenommen: behavior, ime-mode, layout-grid, layout-grid-char, layout-grid-line, layout-grid-mode, layout-grid-type, line-break, text-autospace, text-justify, text-kashida-space, word-break, writing-mode, background-position-x, background-position-y, overflow-x, overflow-y

#: CSS-Attribut vertical-align richtet Inhalte nicht vertikal aus

vertical-align legt fest wie Inline-Elemente zueinander vertikal ausgerichtet sind und nicht wie die Elemente innerhalb eines Containers ausgerichtet sind! Das Attribut ist also vergleichbar mit dem align-Attribut des IMG-Elementes in HTML.

Darüberhinaus lässt sich vertical-align auch für Inhalte von Tabellenzellen anwenden.

Es gibt derzeit (Stand CSS-2, Browserimplementationen Stand Sommer 2002) keine Möglichkeit ausschließlich per CSS Elemente vertikal in einem Container zu zentrieren! Siehe auch CSS > Layout > Inhalte zentrieren.

#: Der CSS-Validator zeigt mir folgende Fehlermeldung: "I/O error: Unknown Mime type: text/plain;charset=iso-8859-1"

Das deutet daraufhin dass der Webserver nicht korrekt konfiguriert ist. Damit Browser wirklich alle Daten korrekt verarbeiten können, werden diese Daten kategorisiert. Dies geschieht mit Hilfe von MIME-Types. Es kommt häufiger vor das CSS als MIME-Typ "text/plain" oder "application/octet-stream" angeliefert wird. Der korrekte Typ ist allerdings "text/css", und muss entsprechend so auch im Webserver eingestellt sein.