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

Habe gerade einen netten Trick bei maddesign.de gefunden (bzw. wurde von Twitter mit der Nase darauf gestoßen ), wie man eine optionale Trennung in Menü-Einträgen erlauben kann. Es funktioniert über das Entity ­ (optionale Trennung) – an sich nichts besonderes, aber bisher ziemlich unbekannt, weil es nicht von allen Browsern unterstützt wurde. Aber mittlerweile funktioniert es in allen wichtigen Browsern (Übersicht gibts bei quirksmode.org) 

Der Clou ist aber, für das Menü die beiden Felder »Seitentitel« und »Navigationstitel« umgekehrt zu verwenden. Üblicherweise wird der Seitentitel als Navigationseintrag und für die URL verwendet; dieser erlaubt aber im Gegensatz zum Navigationstitel weder HTML noch Entities. Im Navigationstitel kann man das Entity eintragen, allerdings kann man den Seitentitel nicht leer lassen, deshalb muss der Entwickler dafür sorgen, dass im Menü der Navigationstitel bevorzugt herangezogen wird. Also so: 

anstatt wie üblich in der anderen Reihenfolge. 

Eigentlich wäre es sinnvoll, das Entity auch im RTE anzubieten (in der Sonderzeichen-Palette), aber im Moment gibts das leider noch nicht. 

Weiterführende Links: 

• Meine Quelle: optionale Silbentrennung für den TYPO3-Redakteur von Sven Wolfermann
• The wbr-Tag bei quirksmode.org (Überblick, welche Browser den wbr-Tag und ­ unterstützen)
• Silbentrennung in Webseiten mit dem Hyphenater von Google (hier im Blog eingesetzt, wie man unschwer an den Trennungen in den deuschsprachigen Absätzen sehen kann).  
• Das Problem mit dem Zeilenumbruch im HTML – ein Artikel, den ich seit Jahren kenne (ungefähr seit der Einführung von HTML 4) und über den ich jetzt eben bei meinen Google-Recherchen zu dem Thema wieder gestolpert bin. Da kommt schon fast Nostalgie auf …  
• Und der ist natürlich auch wichtig: Silbentrennung und bedingter Zeilenumbruch in HTML-Dokumenten von Hyperkontext, bei dem ich eigentlich den Hyphenator das erste mal gesehen habe. 

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.