BlogHouse

Immer wieder kommt es vor dass man eine CSS Regel schreibt und sich wundert wieso die erstellten Anweisungen auf der Webseite keine Auswirkungen zeigen. Der Grund hierfür ist in vielen Fällen die falsche Gewichtung, der Ursprung, die Spezifität und / oder die Reihenfolge.

In den letzten beiden Ausgaben des Webstandards Magazin war ein sehr interessanter Artikel darüber. Damit auch die wenigen unter euch die dieses hervorragende Magazin nicht regelmäßig lesen, und damit auch ich im Zweifelsfall weiß wo ich noch mal nachlesen kann, schreibe ich das mal hier in Kurzform zusammen.

Die Ausführungsreihenfolge der CSS Eigenschaften läuft in 4 Stufen ab.

Stufe 1: Die Gewichtung
Stufe 2: Der Ursprung
Stufe 3: Die Spezifität der Selektoren
Stufe 4: Die Reihenfolge der Selektoren

Den Ursprung kann man kurz folgendermaßen zusammen fassen:
Das Browser-Stylesheet bestimmt als erstes wie eine Seite aussehen soll. Allerdings nur rudimentär mit Anweisungen zu Schriftgrößen, Farben, Links, Formularen usw.
Neuere Browser gestatten es dem Benutzer aber auch eigene Browser-Stylesheets anzulegen. So genannte Benutzer-Stylesheets.
Als drittes gibt es dann noch die Autoren-Stylesheets. Das sind alle CSS-Anweisungen die von uns Webworkern definiert werden.

Daraus ergibt sich schon mal folgende Reihenfolge für die Gewichtung der einzelnen Stylesheets. (more…)

Mit gerade mal 109 Byte in Revision 1 und 74 Byte in Revision 2 stellt Tomas Caspers das kleinste und vor allem valide CSS-Framework der Welt vor.

Perfekt um minimalistische Webseiten zu schaffen

Update:
Wie ich gerade erfahren habe, ist Dirk Jesse, der Erfinder des genialen CSS-Frameworks YAML, für die 74 Byte verantwortlich.
@Andreas Danke für den Hinweis

Die Umfrage CSS-Hacks vs. Conditional Comments ist vorüber.

Mit 58% haben die Conditional Comments gewonnen.
Wie bereits gesagt sicherlich nur ein Trend aber doch interessant.
Die Ausführliche Auswertung findet ihr bei Vladimir Simovic

Ich hatte ja schon vor einiger Zeit einen Beitrag zu dem Thema geschrieben ob man lieber CSS-Hacks oder Conditional Comments nutzen soll.

Jetzt hat Vladimir Simovic eine Umfrage zu genau diesem Thema gestartet.
Ich bin ja mal gespannt was dabei heraus kommt. Obwohl ich mir durchaus bewusst bin dass das Ergebnis lediglich einen Trend darstellen kann.

Jeder hat sicherlich schon mal das von Michael Preidel, in seinem Blog, beschriebene Verhalten beobachtet.

Da hat man ein zentriertes und mit viel Mühe erstelltes Layout und dann erscheint dieser unschöne Nebeneffekt wenn man zwischen Seiten mit mehr und weniger Inhalt umschaltet.
Das Layout verschiebt sich horizontal da Raum für den entstehenden Scrollbalken geschaffen werden muss. Auch in dem Unternehmen in dem ich arbeite, existieren unterschiedliche Meinungen darüber ob man nun das Springen verhindern soll, in dem man per CSS immer Platz für einen Scrollbalken vorhält, oder nicht.

Update:

Gerade lese ich in den Kommentaren von Michales Artikel das es mit der CSS3 Anweisung overflow-y am Body Element möglich ist den Scrollbalken, bei Bedarf, inaktiv darzustellen. Diese Anweisung wir vom Firefox und Safari interpretiert. Da der IE ja ohnehin den Platz vorhält, ist das eine gute Lösung.

Jeder der sich mit der Entwicklung von Webseiten beschäftigt kommt um CSS Hacks nicht herum.
Meist handelt es sich um Hacks für das Wekzeug des Teufels, dem Internet Explorer. Aber auch für andere Browser kann es in seltenen Fällen von Nöten sein eine Spezial Behandlung zu definieren.
In der Regel nutze ich für den IE eine eigene IE-Hack.css die ich über so ein Conditional Comment einbinde. In letzter Zeit liest man aber  immer wieder mal dass die, durch diese Comments, verursachten zusätzlichen HTTP Requests unnötigen Traffic verursachen und man könnte die Ausnahmen direkt in der CSS Datei definieren. Das ist sicherlich richtig und für andere Browser als den IE mache ich das auch. Eine schöne Auflistung der unterschiedlichen Schreibweise für die verschiedensten Browser schreibt Dirk Ginader in seinem Artikel “CSS Voodoo – Die dunkle Kunst der CSS Hacks“.

Ich bin allerdings der Meinung dass eine CSS Datei, übersät mit Ausnahmen für den Internet Explorer sehr schnell unleserlich und dadurch unwartbar wird. Deswegen werde ich auch weiterhin für diesen Browser eigene CSS Dateien nutzen. Ich glaube die Performance Einbußen sind zu vernachlässigen.

Ich habe die Hoffnung auch noch nicht aufgegeben das mit dem IE8 alles besser wird.

mit dem Artikel “Why CSS should not be used for layout” hat Ron Garret eine erneute Diskussion über das für und wider von CSS Layouts angestoßen.
In den Kommentaren geht es mitunter wirklich sehr hitzig und teilweise beleidigend zu, bringen allerdings keine neuen Erkenntnisse. Alles schon mal gehört oder gelesen.

Das ganze hat aber offensichtlich so viel Emotionen ausgelöst das Ron Garret in zwei Folgeartikeln (“CSS and the meaning of life ” und “On the semantics of HTML“) die Diskussion am laufen hält.

Ich bleibe trotzdem dabei und werde meine Layouts weiterhin mit CSS erstellen.
Alles andere wäre aus meiner Sicht ein großer Schritt zurück in die 90er.

Heute ist mir ein Fehler in FF3 in Verbindung mit der “clearfix” Methode aufgefallen. Eine Methode zum clearen von Float Elementen ohne zusätzliches Markup. Beschrieben in Big Johns Artikel “How To Clear Floats Without Structural Markup”.
Eine deutsche übersetzung dieses Tutorials gibt es hier.

Normalerweise stellt der Browser DIV Element ohne Größenangaben in der maximal möglichen Breite da.
Nutzt man im FF3 die beschriebene Methode zum clearen von Float-Elementen, wird das äußere Div nur so breit aufgezogen wie es nötig ist um alle Inhalte darzustellen.
Der CSS Code

<style type="text/css">clearfix:after {
content: ".";
display: block;
height: 0;
clear: both;
visibility: hidden;
}

/* Diese Angabe benötigt der Safari-Browser zwingend !! */
.clearfix { display: block; }

/* for IE-mac */
.clearfix {display: inline-block;}

/* Hides from IE-mac \*/
* html .clearfix {height: 1%;}
/* End hide from IE-mac */
</style>

Das Ergebnis im Firefox 3

Man sieht sehr gut das die blau umrahmte Box nicht die Breite der ganzen Seite beansprucht.

Der selbe Code im Firefox 2

Hier wird die Box auf die volle Breite gezogen. genau so wie man es erwartet.

UPDATE:

Mittlerweile habe ich heraus gefunden dass es sich um keinen Fehler handelt, sondern an folgender Zeile liegt.
display: inline-block;
Der Firefox 3 interpretiert das Attribut inline-block laut Spezifikation.
Da hierbei der Block selbst als Inline Element behandelt wird, dehnt er sich nur so weit aus wie der Inhalt es benötigt. Also ein völlig korrektes Verhalten. Aber mal ehrlich, wer von euch wusste auswendig was dieses Attribut bewirken soll?

Heute Morgen (1. April) ist mein Feed-Reader voll mit Meldungen die darüber berichten dass CSS-Hacks gegen den, erst kürzlich in Kraft getretenen, Hackerparagraph verstoßen.

Also ich glaube (hoffe) ja das es sich hier um einen Aprilscherz handelt.
Denn sollte so ein Blödsinn wirklich Realität sein ………
Ich will gar nicht darüber nachdenken.

Also noch einen schönen 1. April euch allen da draußen.

Wer sich wie ich schon immer, wie ich, darüber geärgert hat gerade mal wieder nicht genau zu wissen welcher Browser welche CSS-Eigenschaft unterstützt, der findet bei CSS contents and browser compatibility eine hilfreiche Auflistung.

Wie man sieht scheint es beim IE7 auch noch nicht sehr viel besser geworden zu sein.

Na ja, ist ja noch Beta, obwohl das Gefühl habe ich beim IE6 ja auch immer .