Letzten Samstag habe ich auf dem Barcamp in Leipzig einen kleinen Vortrag zu CSS-Frameworks gehalten. Ich habe versucht zu beschreiben, was ein CSS Framework von herkömmlichen Layoutvorlagen unterscheidet und die meiner Meinung nach wichtigsten Vertreter YUI Grids, YAML und Blueprint etwas ausführlicher vorgestellt. Ich habe dabei die Gelegenheit genutzt, auch einige Vorurteile anzusprechen, die mit der Nutzung von CSS-Frameworks immer wieder verbunden werden. Meine Folien stehen bei SlideShare unter Creative Commons Lizenz bereit.

| View | Upload your own

Vielen Dank auch nachträglich nochmal an Oliver, meinem Retter aus Reihe 1, der mir kurzfristig sein Notebook für den Vortrag zur Verfügung gestellt hat. Mein eigenea Notebook wurde aus unerfindlichen Gründen über 15 Minuten lang von Skype vollständig blockiert. Ohne Skype und Murphy’s Gesetz wäre die Welt auch wirklich nicht halb so spannend.

Noch ein Wort zum Barcamp. Die Organisation war hervorragend und auch die Location fand ich ausgesprochen einladend. Als keinen Makel empfinde ich allerdings, dass bei 200 Anmeldungen am Samstag Vormittag gerade einmal die Hälfte den Weg zum MediaCampus gefunden hat. Schade ist das vor allem für diejenigen, die gern teilgenommen hätten, aufgrund der seit Wochen vollen Anmeldeliste es jedoch nicht konnten. Ich hoffe, dass sich dieses “mein Handtuch ist mein Platzhalter” Vorgehen nicht noch weiter um sich greift, denn dazu ist diese Veranstaltungsreihe zu schade und den Organisatoren macht man nur unnötig das Leben schwer. 

Dieser Beitrag ist meinem Freund und Kollegen Ansgar gewidmet.

#1 @charset

Über die @charset Regel kann optional die Kodierung einer CSS-Datei angegeben werden. Zur Auswahl stehen hier zahlreiche ISO-Kodierungen (z.B. ISO-8859-1), wie auch Unicode-Kodierungen (z.B. UTF-8). Bei der Anwendung gibt es jedoch zwei wichtige Regeln zu beachten:

1. @charset muss immer in der ersten Zeile eines Stylesheets stehen, andernfalls ignorieren Browser wie der Safari den kompletten Inhalt der Datei.
2. Es darf immer nur eine @charset Regel in einer Datei stehen. Andernfalls ignorieren einige Browser alle CSS-Regeln ab dem zweiten Auftreten von @charset.

Der zweite Punkt ist besonders wichtig, wenn verschiedene Stylesheets optimiert und zu einer Datei zusammengefasst werden sollen. Die wenigsten CSS-Optimierer beachten die @charset Regel, wodurch diese plötzlich mehrfach vorkommt der Browser das Stylesheet ignoriert.

#2 @import

Über die @import Regel lassen sich externe Stylesheets in ein anderes Stylesheet. Auf diese Weise lassen sich CSS-Deklaration sauber nach Funktionen in verschiedene Dateien zerlegen und unabhängig pflegen. Auch bei der Verwendung von @import gibt es einige Punkte zu beachten.

1. @import muss immer vor allen anderen Regeln stehen (ausgenommen @charset). Der Aufruf mehrerer @import-Regeln hintereinander ist möglich.
2. Innerhalb einer @media-Regel ist @import nicht zulässig. Das wäre eine Verletzung von Regel 1, weshalb Firefox, Safari, Opera und alle anderen modernen Browser die @import-Regel in diesem Fall ignorieren.
3. So verlockend die optionale Angabe des Ausgabemediums auch ist (z.B. @import (mein.css) screen,projection), der IE6 kommt mit den Ausgabemedien nicht klar und ignoriert das externe Stylesheet. Schade eigentlich, aber solange der IE6 in signifikanter Größenordnung genutzt wird, ist diese Option so gut wie unbrauchbar.

Speziell Punkt 3 hat mich vor wenigen Tagen wieder zur Verzweiflung getrieben. Manchmal denke ich, das Internet käme schneller voran, wenn Microsoft den IE8 einstampfen würde und stattdessen damit beginnen würde, das Verständnis für CSS2(.1) des IE6 auf ein annehmbares Niveau zu patchen. Denn dieser Browser klebt der Welt wie Sch**** am Schuh und will einfach nicht verschwinden und so wie Vista nicht XP verdrängt, wird es der IE8 vermutlich auch den IE6+7 nicht endgültig zur Strecke bringen.

#3 @media

Zum Abschluss noch ein paar Worte zur @media Regel, über welche der Wirkungsbereich von CSS-Deklarationen auf vordefinierte Medientypen beschränkt werden kann.

1. Einer der häufigsten Fehler in der Anwendung dieser Regel ist, dass die schließende geschweifte Klammer vergessen wird, denn die CSS-Eigenschaften jedes Selektors werden ebenso in geschweiften Klammern zusammengefasst. Im ungünstigsten Fall ignorieren Browser wie der Firefox daraufhin den kompletten Inhalt der Regel.
2. Vertrauen Sie nicht dem Medientyp handheld. Zwar wurde es speziell für mobile Geräte in den Standard CSS Mobile Profile 1.0 aufgenommen, doch bis heute wird er von kaum einem Gerät unterstützt. Auch für die Ausgabe auf Mobilgeräten kommt in der Regel der Medientyp screen zum Einsatz. 

Das war’s. Ich mach dann mal Feierabend.

Gestern Abend bei Peter Kröner entdeckt, den IETester. Ein kleines aber feines Tool, welches die Rendering- und JavaScript-Engine von IE 5.5, 6.0, 7 und 8beta1 in einer Oberfläche zusammenfasst und auf diesem Wege eine wunderbar einfache Kontrolle der jeweiligen Renderingergebnisse erlaubt.

Besonders interessant ist, dass der IETester ohne weiteres unter Vista läuft und somit einen sehr leichten Zugang zu den älteren IE-Versionen bietet, den man ansonsten nur über eine VM bekommt. Zwar fehlt mir im Moment noch der IE5.0 (der Vollständigkeit halber), doch dafür ist der IE5.5 dabei und funktioniert sogar. Die bisher bei mir genutzte Version von Tredosoft glänzte auf meinem Rechner immer nur durch sofortigen Absturz. Kurzum: Der IETester liegt in einer sehr frühen Version 0.2.1 vor und weiß schon jetzt zu begeistern. 

Microsoft produziert mit dem kommenden IE8 derzeit Schlagzeilen am Fließband. Los ging es mit einer Meldung Ende letzten Jahres, nachdem die Entwicklerversion des IE8 den ACID2-Test bestanden hätte. Auf den Jubel der Webentwickler folgte die Ernüchterung und harrscher Protest als Microsoft seine Pläne zum Version Targeting vorstellte, welches den IE8 erst durch einen zusätzlichen Meta-Tags zu einem standardkonformen Rendering bewegen sollte. Per Voreinstellung sollte sich der IE8 wie ein IE7 verhalten.

Der Proteststurm der Entwicklergemeinde hat Microsoft offensichtlich nachhaltig beeindruckt. In einem ersten Schritt wurde das Version Targeting entschärft und der IE8 wird per Voreinstellung ein standardkonformer Browser werden. Und heute erfährt die Community auch, woher die IE-Entwickler die Zuversicht haben, dieses ehrgeizige Ziel zu schaffen. Seit einiger Zeit wissen wir schon, dass der IE8 eine vollkommen neue Rendering-Engine erhalten wird. Jetzt ließen die Entwickler im IE-Blog einen tieferen Blick in die Internas zu und ließen damit die nächste Webstandards-Bombe platzen. Der IE8 wird auf der Webkit-Engine aufbauen, Microsoft hat diese bereits vor einiger Zeit lizensiert und mit der Entwickler-Community ein umfangreiches Kooperationsabkommen geschlossen. Dieses garantiert den Webkit-Entwicklern, dass Microsoft - genaus wie Apple es mit Safari seit einiger Zeit betreibt - eigene Weiterentwicklungen ind Patches wieder an Webkit zurückliefert und sich damit aktive an der Weiterentwicklung der Engine beteiligt.

Damit schießt Mircosoft die eigene Rendering-Engine entgültig in den Wind und stützt sich in Zunkunft auf eine der modernsten schnellsten Engines. Gleichzeitig legt der Software-Dino innerhalb kürzester Zeit zum zweiten Mal eine Rolle Rückwärts hin, und beide Male zu 100% im Sinne der Webentwickler und der weiteren Verbreitung von Webstandards. Wird am Ende etwas doch alles gut? Man mag es kaum glauben. 

Das Entwicklerteam des Opera-Browsers ist ausgesprochen aktiv und immer um die Weiterentwicklung ihres Browsers bemüht. Erst gestern meldete das Opera Desktop Team 100 von 100 möglichen Punkten im ACID 3 Test des Webstandards Projects (im Wettrennen mit Safaris Webkit-Engine) und darf sich nun feiern und auf die Schulter klopfen lassen.

Sehr schön, wirklich. Allerdings kontrolliert der ACID3-Test offensichtlich nicht Ergebnisse grundlegender Rechenoperationen, die jeder Browser beherrschen sollte (sowas wird allgemein nach der Grundschule vorausgesetzt). Und so passiert es, dass der Opera seit Jahren nicht dazu fähig ist, Prozentangaben als reelle Zahlen zu verarbeiten. Stattdessen schneidet er beständig auch in der neuesten Beta-Version Nachkommastellen einfach weg und behandelt Breiten- und Höhenangaben in Prozent als Integerwerte.

Das W3C legt in der CSS2 Spezifikation in Abschnitt 4.3.3 fest:

The format of a percentage value (denoted by <percentage> in this specification) is an optional sign character (’+’ or ‘-’, with ‘+’ being the default) immediately followed by a <number> immediately followed by ‘%’.

Die Definition für <number> findet sich in Abschnitt 4.3.1, die wichtigen Passagen sind markiert:

Some value types may have integer values (denoted by <integer> ) or real number values (denoted by <number>). Real numbers and integers are specified in decimal notation only. An <integer> consists of one or more digits “0” to “9”. A <number> can either be an <integer>, or it can be zero or more digits followed by a dot (.) followed by one or more digits. Both integers and real numbers may be preceded by a “-” or “+” to indicate the sign.

Die Auswirkungen dieses Bugs bekommt man bei der Positionierung von Containern mit flexiblen Spaltenbreiten oder -höhen, sowie bei der Skalierung von Schriftgrößen (man denke an krumme Werte infolge Vererbung) zu spüren, denn wo selbst der IE5 (FF und Safari natürlich ebenso) bei der Rechnung 66.666% + 33.333% = 99.999% (bei Layoutbreiten unter 100.000 Pixeln also effektiv 100 Prozent) errechnen, landet Opera bei 99 Prozent denn er macht daraus 66%+33%. Aus dieser Eigenart ergeben sich dann plötzlich Abstände und Zwischenräume im Layout wo keine sein dürften. Für Webdesigner entstehen hingegen Fragezeichen über dem Kopf und unnötiger Anpassungsaufwand, denn patchen lässt sich dieser Bug leider nicht.

Also liebe Opera-Entwickler: Wenn Ihr mit dem Feiern fertig seid wäre es wirklich ein Segen, wenn ihr Euch dieses Problems endlich mal annehmen könntet. Ich war auch diesmal so freundlich, einen Testcase zu bauen, extra für Euch.

Auf der anderen Seite zeigt sich für mich mal wieder, dass auch die ACID-Tests (mittlerweile in der 3. Generation) für den Alltag nicht die Praxisnähe haben, die man sich eigentlich wünschen würde, um die Rendering-Qualität von Browsern korrekt einschätzen und vergleichen zu können.