Terrific und OOCSS

Wie im letzten Terrific-Post angetönt, geht es in dieser Episode ein bisschen ans Eingemachtere… also dann, auf gehts…

Wieso OOCSS?

Terrific basiert auf OOCSS. Um die Vorteile von OOCSS zu begreifen, muss man zuerst die Schwachstellen und Probleme von CSS verstehen.

Code ist sehr „fragil“
Eine falsche Änderung kann durch die Kaskadierung unvorhersehbare Effekte hervorrufen – zum Beispiel Layoutfehler auf Seite xx.

Parallele Entwicklung im Team ist extrem schwierig
Die CSS-Regeln beeinflussen sich gegenseitig. Ohne genaue Kenntnisse über die Arbeit der Teamkollegen, ist die parallele Entwicklung praktisch unmöglich.

Code-Reuse ist sehr selten
Wir „vertrauen“ nicht auf den Code von anderen. Dies nicht aufgrund egomanischen Zügen, sondern weil uns die Erfahrung gelehrt hat, dass wir oftmals eleganter und schneller zum Ziel kommen, wenn wir CSS-Code von Grund auf selber schreiben. Nicht selten bedient man sich dabei stark gekapselten CSS-Selektoren à la „#id .class“, die einen Reuse wegen ihrer hohen Spezifität und Individualität praktisch ausschliessen.

Konsequenzen

  • Code wird unübersichtlich und unstrukturiert
  • Der Code wächst linear zur Projektgrösse = Performanceprobleme

Beides hat zur Folge, dass die Fehleranfälligkeit stark ansteigt und der Code unwartbar wird.

Wie macht man es besser?

OOCSS wurde von Nicole Sullivan (Yahoo) entwickelt und stellt einen wiederverwendbaren Baukasten an CSS-Klassen zur Verfügung. Oberstes Ziel von OOCSS ist es, vorhersagbares Verhalten ohne Seiteneffekte sicherzustellen. Dies wird erreicht, indem das Markup und die dazugehörigen CSS-Klassen stark standardisiert werden.

Alle Terrific Komponenten werden entsprechend den OOCCS-Regeln umgesetzt:

Elements

Grundlegende Definition der HTML Elemente

/* Link */
a.base, a.base:link, a.base:visited {
    color: #434343;
    text-decoration: underline;
}

Als Namenskonvention wird.base verwendet. Dadurch kann man von Module zu Module selbst entscheiden, ob man den Basisstyle eines Elements verwenden will oder nicht.

Layout

Aufteilung in einzelne, voneinander getrennte Bereiche (z.B. Header, Footer, 3 Spalten)

2126-Terrific-Layout-thumb-500x241-2125.png

Das zugehörige Markup ist beinahe selbsterklärend:

<div class="page">
<div class="head">
<h2>Head</h2>
</div>
<div class="body">
<div class="leftCol">
<h2>Left Column</h2>
</div>
// more leftCols
<div class="rightCol">
<h2>Right Column</h2>
</div>
// more rightCols
<div class="main">
<h2>Main Content</h2>
</div>
</div>
<div class="foot">
<h2>Foot</h2>
</div>
</div>

Mit den OOCSS-Klassen page, head, foot, leftCol, rightCol und main lassen sich in kürzester Zeit Layouts erstellen, die bis und mit IE 5.5 abwärtskompatibel sind.

Grid

Seitenspezifische Unterteilung in Lines und Units

2129-Terrific-Grid-thumb-500x189-2128.png

Und das Markup? Et Voilà!

<div class="line">
<div class="unit size1of5">
<h3>1/5</h3>
</div>
// repeat 3 times
<div class="unit size1of5 lastUnit">
<h3>1/5</h3>
</div>
</div>
<div class="line">
<div class="unit size2of5">
<h3>1/5</h3>
</div>
<div class="unit size3of5 lastUnit">
<h3>1/5</h3>
</div>
</div>

Lines und Units können beliebig verschachtelt werden. So können auch komplexeste Grids mühelos erstellt werden. Lediglich bei den Units muss darauf geachtet werden, dass die Summe aller Breitenangaben nicht die umgebendende Line sprengt. Mit den von OOCSS mitgelieferten size-Klassen (size1of5, size3of5 etc.) wird dieses Problem durch prozentuale Breitenangaben umgangen. Bei eigenen Grids muss dieser Umstand jedoch berücksichtigt werden.

Modules

Module sind in Terrific das zentrale Thema. Praktisch sämtliche Inhalte und Funktionalitäten stammen aus den Inhaltsmodulen.

Beispiel: Currency Converter

2131-Terrific-Module.png

Um den Entwickler nicht einzuschränken, gibt OOCSS nur die Wrapper-Divs vor. Terrific erweitert das ganze noch durch eine modulspezifische Klasse (modCurrencyConverter), welche für die Kapselung des CSS und das Terrific JavaScript System benötigt wird.

<div class="mod modCurrencyConverter">
<div class="inner">
<div class="bd"><!-- 1-n times --> ...</div>
</div>
</div>

Sämtliche CSS-Regeln werden mit der spezifischen Modulklasse prefixed. Die Kaskade von CSS übernimmt also quasi die „Objektorientierungs“-Rolle.

.modCurrencyConverter .bd {
    background: #fff;
    padding: 10px 10px 18px 10px;
}
...

Skins

Skins bieten die Möglichkeit, das Aussehen von Modulen gezielt zu überschreiben. So können zum Beispiel mandantenfähige Systeme problemlos umgesetzt werden – ein Modulegrundstyle und ein Skin pro Mandant – ohne sämtlichen Code duplizieren zu müssen.

2137-Terrific-Skin-thumb-400x194-2134.png
<div class="mod modCurrencyConverter
       skinCurrencyConverterHighlighted">

<div class="inner">
<div class="bd"><!-- 1-n times --> ...</div>
</div>
</div>

Der Skin erbt sämtliche Regeln des Moduls. Um den Hintergrund zu verändern, muss im Skin-CSS also lediglich die entsprechende Regel überschrieben werden:

.skinCurrencyConverterHighlighted .bd {
    background: #aebbcb;
}

Skins sind auch nützlich, um „ähnliche“ Inhalte in einem einzigen Modul zusammenzufassen. Die voneinander abweichenden Definitionen werden dabei in die Skins ausgelagert.

Wie weiter?

Die HTML/CSS Problematik wird von OOCSS sauber gelöst. Das beschriebene 5-Komponenten-Prinzip von Terrific unterstützt dabei die modularisierte Frontendentwicklung optimal.

Aber wie sieht es mit dem JavaScript Part aus? Mehr dazu im nächsten Terrific-Post!

Weitere Terrific Informationen

Open Source Projekt: Terrific und TerrificJS

Terrific – Modulare Frontendentwicklung
Terrific und OOCSS
The Terrific Way Of JavaScript
Terrific im Projekprozess

3 Gedanken zu “Terrific und OOCSS

  1. Wenn ich Nicole Sullivan richtig verstanden habe, sollte die Basis nicht „a.base“, sondern nur „a“ oder nur „.base“ sein. Ich möchte sicher nicht zukünftig alle meine Links noch zusätzlich mit einer Klasse versehen müssen… ;)

  2. Danke für den fundierten Beitrag Remo. Schön auch so tolle, konstruktive Kommentare und angeregte Diskussionen mit super Verbesserungsvorschlägen zu sehen.

  3. @Martin:
    Richtig, Nicole Sullivans OOCSS-Vorschlag sieht keine .base-Konvention vor.
    Nicole Sullivan geht jedoch auch davon aus, dass das Aussehen von Elementen wie h2, h3, a etc. innerhalb eines Designs immer identisch ist und nur in seltenen Ausnahmefällen voneinander abweicht.

    Aus diesem Blickwinkel betrachtet macht die .base-Konvention zugegebenermassen nur begrenzt Sinn, da fürs Resetten der CSS-Definitionen im entsprechenden „Ausnahme“-Modul relativ wenig Aufwand anfällt. Doch auch hier besteht die Gefahr, dass bei einer Änderung der Grunddefinition (z.B. h2) die entsprechende Reset-Anpassung im „Ausnahme“-Modul vergessen geht.

    Analysiert man jedoch bestehende, anspruchsvolle Designs, so stellt man fest, dass unterschiedliche optische Ausprägungen von Elementen eher die Regel als die Ausnahme darstellen. Somit würde die Pflege der Reset-Rules definitiv mehr Aufwand erfordern als die Einhaltung der .base-Konvention und zudem das potentielle Fehlerrisiko drastisch erhöhen.

    Deshalb haben wir uns nach intensiver Diskussion und mehreren alternativen Vorschlägen für die .base-Konvention entschieden. Eine retrospektive Analyse der ersten Terrific Projekte gibt uns dabei recht.

Hinterlasse eine Antwort

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *

*

*

Du kannst folgende HTML-Tags benutzen: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>