28. May 2010

Kurz erklärt: OOCSS von Nicole Sullivan

Webdesigner kämpfen immer wieder damit, ihre CSS-Dateien ordentlich zu halten. Eine Möglichkeit ist, viele kleine CSS-Dateien zu erstellen, die dann für jeweils einen bestimmten Bereich der Website das Design zur Verfügung stellen. Diese Möglichkeit schützt allerdings nicht vor doppelten Angaben innerhalb des Stylesheets. Dafür gibt es jetzt Object Oriented CSS (kurz OOCSS) von Nicole Sullivan.

Ausgangslage

Normalerweise wird eine Box mit rosa Hintergrund und schwarzer Rahmenlinie so definiert:

.boxmitrosarahmen {
  background: #8f0824; /* oder irgendetwas anderes rosa farbenes */
  border: 1px solid black;
  padding: 10px;
}

Im HTML greift man mittels dieses Konstrukts auf die eben festgelegten Formatierungen zurück:

<p class="boxmitrosarahmen">Lorem ipsum…</p>

Einen zweiten Kasten mit anderen Farbwerten kann man analog zum ersten Beispiel erstellen. Wenn man das gemacht hat, fällt auf, dass gewisse Formatierungen der Boxen doppelt definiert wurden:

  • Der Innenabstand, der zweimal 10px beträgt
  • die Rahmenstärke und der Rahmentyp

Und wo bleibt jetzt das Object Oriented CSS?

Hier setzt OOCSS von Nicole Sullivan an. Es überträgt den Hintergedanken von Objektorientierung (von Programmiersprachen) auf CSS. Ein Gedanke von Objektorientierung ist die Modularisierung: Alles wird auf kleinste Teilchen reduziert, die dann erweitert werden. Unmittelbar damit verbunden ist das sogenannte DRY-Prinzip. “DRY” steht für “Don’t repeat yourself” und fordert, dass nichts doppelt notiert wird. Unser Ausgangsbeispiel verstößt also ganz radikal gegen das DRY-Gesetz.

Wie können wir dem begegnen? Mit Object Oriented CSS. Überlegen wir uns also, wie wir die doppelten Angaben vermeiden. Wir könnten eine Art Basisklasse festlegen, die die grundlegenden Formatierungen für die Boxen festlegt, und einige andere Klassen, die diese Basisklasse erweitern. Die Basisklasse könnte .box heißen und so aussehen:

.box {
  padding: 10px;
  border-style: solid;
  border-width: 1px;
}

Die Erweiterungsklassen könnten nach folgendem Muster angelegt werden:

.rosablack {
  background: #8f0824; /* Den Kommentar dazu spare ich mir hier. wink */
  border: 1px solid black;
}

Diese Namensgebung der Erweiterungsklassen (erst der Hintergrundname in einem Wort und dann die Farbe der Rahmenlinie) widerspricht zwar dem uralten Grundsatz, dass man sprechende Klassennamen wie .note oder .important verwenden soll, weil man aus .rosablack nur schwer ablesen kann, wofür diese Klasse zuständig ist. Natürlich könnte man die Klasse auch .note oder .important nennen. Aber für mich war diese Namensgebung praktischer, weil bei mir eine grüne Box (grüner Hintergrund und grüner Rahmen) nicht automatisch eine “Irgendetwas-ist-gut-gelaufen-Box” heißt.

Im HTML greift man dann auf beide Klassen (Basis- und Erweiterungsklasse) gleichzeitig zu, ganz nach Motto:

<p class="box rosablack">Lorem ipsum…</p>

Vor- und Nachteile von OOCSS

Nach dieser ersten Demonstration stellt sich vielleicht die Frage nach den Vor- und Nachteilen von OOCSS.

Ein Nachteil von OOCSS ist sicherlich, dass man mehr schreiben muss (weil die sogenannten short hands im CSS nicht mehr vorhanden sind, bzw. gemäß dem DRY-Prinzip nicht mehr angewendet werden dürfen). Das betrifft allerdings nicht nur das CSS, sondern auch das HTML.

Der Vorteil jedoch ist, dass man nichts mehr doppelt schreibt und so später einmal bei allen Boxen auf einmal, egal welcher Farbe, die Rahmenstärke ändern kann. Dieser Vorteil der Modularisierung des CSS hat mich voll überzeugt und mich dazu bewogen, das Konzept in Maßen auch auf meiner eigenen Website einzusetzen; ich benutze es bei den Kästen, die manchmal im Fließtext auftauchen, und bei den Erfolgs- und Fehlermeldungen beim Kontaktformular.

Ich hoffe, eine gute kleine Einführung in das Thema gegeben zu haben. Vielleicht regt mein Blogeintrag den ein oder anderen Webdesigner, der meine Website besucht, dazu an, doch mal sein CSS und HTML noch mal zu überdenken und OOCSS bei zukünftigen Projekten konsequent einzusetzen.

Weblinks zum Thema

19. May 2010

Kaum onlinegestellt, schon vollgespammt: Mein Weblog ertrinkt in einer Spamflut!

Man muss doch aufpassen, wenn man ein neues Weblog ins Netz stellt. Aufpassen im Sinne von Spam-Filter einbauen! Es spielt nämlich keine Rolle, ob Wordpress oder Expression Engine im Hintergrund werkelt, die Spamkommentare werden an alle verschickt.

Tatsache! Mein Weblog kaum weniger als zwei Wochen online, schon wird es mit Spamkommentaren nur so vollgemüllt! Da sieht man mal wieder: Es macht für die Spambots keinen Unterschied, ob Wordpress oder Expression Engine das CMS der Website ist.

Hier habe ich offenbar zu spät an die Nachrüstung eines Anti-Spam-Plugins für Expression Engine gedacht. Gut, ist hiermit getan: “Low NoSpam” heißt das Plugin und soll in Zukunft über meinen API-Key von Akismet, das ich schon unter Wordpress benutzt habe und das mich vor rund 130 Spamkommentaren bewahrt hat, meinen Blog sauber von Spam halten. Mal sehen, ob es wirkt!

11. May 2010

Meine Website in neuem Gewand: Der Relaunch

Jetzt habe ich es endlich geschafft: Das Relaunch meiner Website, Codename <Wonder>, ist online. Basierend auf Expression Engine und YAML, wartet es mit einem modernisierten Design auf und zahlreichen kleinen Javascript-Effekten. Ich habe die Geschichtsaufsätze nun vollständig in die Website integriert und auch eine eigenständige Geschäftswebsite erstellt.

Endlich. Der Relaunch. Was soll ich sagen? Angefangen hat alles im Sommer 2009 mit dem Besuch der Sitepoint-Website. Deren Navigation hat mich so fasziniert, dass ich diese ohne Umschweife als Grundstock für meine Website genommen habe. Nach einer Weile ist daraus dann die Website geworden, die Sie jetzt hier sehen: schlicht, aber doch ergreifend, oder? Schauen Sie sich einfach mal um und schreiben Sie mir ein kurzes Feedback.

Vorteile, die ich mir von dem Relaunch verspreche

Einmal wäre da sicherlich das mordernisierte Design, das ich komplett selbst gemacht habe, was heißt, dass ich jetzt die volle Kontrolle darüber habe, soweit man das behaupten kann.
Zum Anderen aber auch die Performance: Die ist bei der Expression Engine nämlich um Welten besser als bei Wordpress - glaube ich zumindest. Und da Google kürzlich beschlossen hat, die Performance einer Website als Ranking-Faktor mit einzubeziehen, schadet eine schnellere Seite auch nichts.
Des weiteren ist das Templating-System der Expression Engine einfach ganz wunderbar intuitiv, es macht Spaß, damit zu arbeiten und geht schnell von der Hand - was man bei Wordpress-Templates nicht behaupten kann.
Weiteres zur Website und was dahinter werkelt, können Sie auf der “Behind-The-Site”-Seite lesen.

Was noch fehlt

  • Einige der alten Blogeinträge müssen noch importiert werden.
  • Der Spruch des Tages muss wieder rein.
  • Die Abkürzungen müssen noch gekennzeichnet werden.
  • target=“blank” in Links entfernen und durch jQuery ersetzen. -> wartungsfreundlicher.
  • DIN berücksichtigen, was Gedankenstriche und danachfolgende Leerschritte angeht.