TYPO3@lisardo

Mit less kann die Entwicklung von umfangreichen CSS-Strukturen vereinfacht werden: Es ermöglicht den Variablen, Operationen und Funktionen innerhalb einer CSS-Datei. So können zum Beispiel zu Beginn der CSS-Datei Farben, Maße und andere einheitliche Elemente definiert und anschließend als Variablen (oder eigentlich eher als Konstanten) verwendet werden. Mit Hilfe von »nested rules« kann man (wie im Typoscript) auf die lästigen Selektoren verzichten und statt dessen die CSS-Regeln einfach ineinander verschachteln. Und vieles mehr – bitte einfach auf der Originalseite nachlesen, es gibt da eine gute Dokumentation aller Techniken. 

Obwohl mich less fasziniert, seit ich es zum ersten Mal gesehen habe (was für eine Zeitersparnis beim Entwickeln!) setze ich es bisher nicht ein, da die less-Dateien natürlich irgendwie aufbereitet werden müssen, bevor der Browser sie interpretieren kann. Das funktioniert entweder direkt im Bowser über JavaScript oder serverseitig über ein Ruby-Skript.

Genauer erklärt ist das Ganze hier: less: The dynamic stylesheet language. 

Nun ist Ruby nicht auf allen Servern installiert und der Einsatz im Browser über JavaScript schmeckt mir auch nicht. Also war das für mich bisher ein interessanter Ansatz, aber mehr auch nicht. Bis mir das hier untergekommen ist: less.app for Mac OS X. Die App funktioniert so: ich versehe meine CSS-Datei mit der Endung .less und arbeite darin mit den less-Befehlen, wie üblich in Textmate. Vorher übergebe ich den ganzen Prohekt-Ordner an die less-App, teile der App mit, in welchen Ordner die CSS-Dateien kompiliert werden sollen, und jedes Mal wenn ich jetzt die less-Datei speichere, wird die CSS-Datei kompiliert, auf Wunsch auf minifiziert. Da die Datei geparst wird, werden dabei auch gleich noch alle kleinen Syntaxfehler gefunden ... Schöner gehts nicht; das wird in Zukunft verwendet!

Auf der Seite gibts ein kurzes Video, das den Einsatz erklärt. 

Weiterführende Links

• less: The dynamic stylesheet language
• less.app for Mac OS
• Less.app for Windows (Sort of)
• Less Framework 4

Die Internet Explorer zeigen auch bei kurzen Seiten rechts einen inaktiven, abgedimmten Scrollbalken. Sinn ist, dass die Darstellung nicht springt, wenn die Seiten z. B. im Browserfenster zentriert dargestellt werden und manche eben länger und andere kürzer sind. In Safari und Firefox dagegen erscheint der Scrollbalken nach Bedarf, was eben dazu führt, dass die Seiten beim Blättern waagrecht springen. 

Abhilfe: 

Eigentlich ist das Problem ganz einfach: relative Angaben wie 100% werden in CSS immer auf den umgebenden Container bezogen. Bekommt ein Container also eine Höhe von 100%, so wird er auf die Höhe des übergeordneten Conainers hochgezogen. Kein Problem, wenn der umgebende Container eine absolute Höhe in Pixeln hat. Aber was, wenn ein Container die Höhe des Fensters haben soll? 

Dann müssen alle dazwischen liegenden Container ebenfalls eine Höhe von 100% erhalten, so dass sich die relative Höhe vom Fenster bis zum gewünschten Container vererben kann. Um also einen DIV mit der ID »page« auf 100% Höhe des Fensters zu bringen, muss sowohl der Container »html« wie auch »body» 100% Höhe erhalten. Richtig ist also: 

Das klappt in allen Browsern.  

Mir ist aufgefallen, dass die Standardschriften, die unter Windows in den IEs für die Darstellung von monospaced-Schriften verwendet werden, nicht besonders gut aussehen und schlecht lesbar sind. Zudem gibt es eine Standardeinstellung in den IE, die verhindert, dass eine bestimmte Minimalgröße unterschritten wird. Und da ich heute vormittag ein bisschen was über Webfonts gelesen habe, wollte ich es gleich ausprobieren. 

Erster Schritt: eine vernünftige Schrift finden, die ich auch verwenden darf, also Open Source. Da gibts nicht gerade viel Auswahl, aber gerade im Bereich monospaced gibt es doch ein paar. Die »Inconsolata« von Ralph Levien hat mir gut gefallen: frei verwendbar, gut lesbar auch in kleinen Schnitten und sauberes Schriftbild in den wichtigsten Browsern. 

Zweiter Schritt: die Schrift liegt nur als Opentype vor, also konvertieren in die passenden Webformate, und zwar mit FontSquirrel, einem Online-Service zum Konvertieren von Schriften. Der Dienst arbeitet perfekt und bequem: ich erhalte ein zip-Archiv mit vier Schriftdateien: eot für die Internet-Explorer, svg fürs iPhone, ttf für Safari und woff für Firefox. (Es ist wirklich genau so bescheuert, wie es sich anhört ...). Ausserdem eine Demo-Datei mit den passenden CSS-Einträgen.

Und so werden die Fonts eingebunden: 

Danach können die entsprechenden Absätze mit dieser Schrift formatiert werden: 

Eine schöne Anleitung ist im Artikel »Cross Browser Font Embedding« (Englisch) zu finden. Der Autor erläutert genau die Bedeutung der einzelnen Abschnitte im CSS-Code. Insbesondere die url-Angaben sind wichtig, damit die ganze Sache funktioniert. 

Zu sehen ist die eingebettete Schrift hier recht unspektakulär in den Abschnitten mit dem Soruce-Code, z. B. die Zeilen oben. Damit umgehen können alle modernen Browser und auch die weniger modernen Internet Explorer ... 

Achtung: Schriften so einbetten ist natürlich ein Lizenzproblem. Die meisten Schriften dürfen nicht so ohne weiteres eingebunden werden, da die Besucher die Schrift ja herunterladen und bei sich im System installieren könnten. Es müssen deshalb Open Source Schriften sein, von denen es nicht gerade viele gibt (Google bietet zum Beispiel einige).

Allerdings entstehen gerade einige Web-Services (unter anderem sogar mit Linotype-Schriften), die eine Einbettung von DRM-geschützten Schriften ermöglichen. Dazu muss man sich bei diesen Anbietern anmelden und in seinem Account dort die Schriften zusammenstellen und das CSS generieren lassen. Um die Dateien möglichst klein zu halten, können bei manchen Anbietern sogar die Zeichen zusammengestellt werden, die die Schrift zur Verfügung stellen soll. Die Schriften werden auf diese Art nicht vom eigenen Server geladen sondern von den Servern dieser Dienste. Ein paar Links zu solchen Webfont-Services habe ich hier zusammengestellt. Die meisten bieten einen Demo-Account, mit dem man ein- oder zwei Schriften testen kann, ansonsten berechnen sie ab ca 20,– USD im Jahr für beliebig viele Schriften pro einer Domain. Die Kosten sind überschaubar: TypeKit verlangt z. B. 99 USD / Jahr für beliebig viele Schriften, eine beliebige Anzahl Domains und bis zu 100.000 Aufrufe im Monat. Wie sich die Performance entwickelt, kann man jetzt allerdings noch nicht sagen. 

Viele de Code-Zeilen im Blog hier sind zu lang für die relativ schmale Mittelspalte, das gibt insbesondere ein Problem, wenn die Wörter zudem sehr lang sind, oder wenn sie nur mit Punkten getrennt werden, wie üblich in Programmiersprachen. Die meisten Browser brechen nur um, wenn nach dem Punkt ein Leerzeichen folgt. Insbesondere im IE 6 gibt es zusätzlich das Problem, dass zu breite Zeilen die mittlere Spalte nach unten verdrängen, also unter die rechte Spalte. 

Allerdings gibt es mit CSS3 hier Abhilfe. Und da es sich um ein Feature handelt, das eigentlich von Microsoft stammt, funktioniert es als praktisch einziges CSS3-Feature auch im Internet Explorer 6: 

Bekannt und nervend ist das Problem auch bei E-Mailadressen – die überraschenderweise sehr lang werden können und gerne die schmalen Seitenspalten sprengen.