Webkrauts Logo

Webkrauts Webkrauts Schriftzug

- für mehr Qualität im Web

Objektorientiertes CSS  – Eine Einführung

Objektorientiertes CSS  – Eine Einführung

Frontendentwickler haben in der Regel mit Objektorientierung nicht viel zu tun. Bei OOCSS geht es genau darum: Es gilt auf wiederverwendbare Objekte in CSS zu setzen, anstatt seiten- oder modulbasiert zu denken. Olaf Gleba stellt den Konzeptansatz vor.

Um performante und skalierbare Webseiten zu erstellen, ist ein durchdachtes Konzept in der HTML- und CSS-Erstellung unerlässlich. Nicole Sullivan stellt mit Objektorientiertem CSS (OOCSS) einen Ansatz vor, der die Idee der Objektorientierung, wie sie aus Programmier- und Scriptsprachen wie Java, PHP u.ä bekannt ist, für HTML/CSS adaptiert.

Die Anforderungen an HTML- und CSS-Dateien sind vielfältig: Der Quelltext soll semantisch sauber, standardkonform, skalierbar, wiederverwendbar und stabil sein und gleichzeitig schnelle Ladezeiten garantieren. Er soll so komplex wie nötig und so einfach wie möglich sein, um Teammitgliedern unterschiedlicher Kompetenz in die Pflege/Erweiterung einbeziehen zu können und zudem kurze Produktionszyklen ermöglichen, um betriebswirtschaftlich im grünen Bereich zu bleiben.

Was ist Objektorientiertes CSS?

OOCSS beschreibt zunächst einen Konzeptansatz. Um Beispiele und Standardansätze darzustellen, hat Nicole Sullivan auf ihrer Github Projektseite einen Vorschlag für ein Framework bereitgestellt. Dieses hat, worauf sie an verschiedenen Stellen hinweist, Entwurfcharakter und ist zudem in Teilen noch nicht vollständig. Auf der Projektseite finden sich ausführliche Informationen zum Projekt und eine Präsentationsfolie. Daneben existiert eine auf Yahoo Developer Network veröffentlichte Videopräsentation des Konzeptes, das Nicole Sullivan auf der Web Directions North Anfang des Jahres zum ersten Mal vorstellte. Auch eine Google Group existiert zum Projekt.

Um das Konzept von OOCSS zu verstehen, empfehle ich, im Anschluss an die Lektüre des Artikels zuerst die Videopräsentation des Konzeptes anzuschauen und sich dann mit den zum Download bereitgestellten Dateien vertraut zu machen. Dieser Artikel soll und kann nur einen ersten, groben Überblick über einige markanten Merkmale und Aussagen des Konzeptes geben.

Modularität  – Ausgangslage und Problemstellung

What is the most important mistake talented coders are making? Writing really clever modules. (Nicole Sullivan)

Arbeitsweisen von Front-Entwickler sind stark geprägt von alltäglichen Anforderungen. So haben nur die wenigsten die Gelegenheit und Zeit die eigene Arbeitsweise unabhängig vom Tagesgeschäft kontinuierlich zu hinterfragen. Nehmen wir ein Beispiel aus der Praxis: Ein Kunde wünscht sich eine neue Teaser-Box für ein Produkt; diese Box soll nur auf der Startseite angezeigt werden. Da der Messetermin kurz bevor steht, es also mal wieder schnell gehen muss, neigen wir dazu, den Code ohne Bezug zum übergreifenden Seitenkontext zu erstellen. Wir setzen Identifier ein, nutzen ausgiebig Kontext-Selektoren und schaffen so eine Insel, die extrem pfiffig in ihrem Aufbau ist, super aussieht und perfekt den Anforderungen des Kunden entspricht…

Was aber, wenn der Kunde so so begeistert von unserer Teaser-Box ist, dass er sie zu einem späteren Zeitpunkt dann doch – in einem anderen strukturellen Kontext und mit anderen Inhalten versehen – haben möchte?

Die fehlende Trennung von Inhalt und Struktur und die Kapselung durch extensiven Einsatz von Kontextselektoren führt dazu, das wir im Idealfall das HTML und die CSS Anweisungen duplizieren und die Deklarationen an die neuen Bedürfnisse anpassen. Unsere CSS-Datei(en) wachsen also linear im Verhältnis mit den der Seite hinzugefügten HTML-Elementen. Was bei kleineren Seiten vielleicht nur marginale Bedeutung hat, bedeutet für Seiten, die eine hohe Besucherquote und damit eine hohe Last haben, ein Sterben auf Raten. Die Performance (und mittelfristig damit auch die Besucherzahl) sinkt linear zur Ausbaustufe der Seite – Krisengespräche zwischen Agentur und Kunde (der vormals so begeistert über unsere Arbeit war) sind vorgezeichnet.

Wäre es nicht eine interessante Idee, die inhaltlichen- und strukturellen Elemente einer Webseite auf den kleinstmöglichen Nenner zu bringen? Anstatt seiten- oder modulbasiert zu denken unser Seitenkonzept auf wiederverwendbaren Objekten aufzubauen, durch deren Kombination sich komplexe und performante Seitenkonzepte – ohne die genannten Fallstricke – erstellen lassen?

Hier setzt das Konzept von Nicole Sullivan an.

Was ist ein Objekt innerhalb OOCSS?

Die Begrifflichkeit Objekt kann im Zusammenhang mit OOCSS als eine Einheit verstanden werden, die in Ihrer Semantik und Deklaration unabhängig von weiteren Objekten ist.

Ein Objekt besteht aus folgenden Teilen:

  1. HTML (mindestens ein DOM-Knoten)
  2. CSS Deklaration für den DOM-Knoten
  3. Komponenten (Präsentationselemente wie Hintergrundbilder etc. per CSS)
  4. Javascript Event listeners und Methoden, die an das Objekt gekoppelt sind (optional)

Ein Objekt wird also grundsätzlich durch mindestens einen DOM-Knoten repräsentiert. So kann ein Objekt durch ein sogenanntes Modul repräsentiert werden, das aus einem Rahmenelement besteht und weitere DOM Knoten beinhaltet.

Beispiel 1: Ein Standard-Modul

Block Head
Block Body
Block Foot

Das Beispiel zeigt ein Standard-Modul aus dem bereitgestellten Framework von Nicole Sullivan. Als Objekt wird hier das Rahmenelement mit der Klasse mod definiert. Es enthält vier weitere, strukturelle DOM-Elemente, die in Abhängigkeit zum Elternobjekt stehen, wobei die Elemente mit den Klassen inner und bd in ihrem Konzept zwingend erforderlich, die beiden anderen Klassenelemente (hd und ft) optionalen Charakter haben.

Aber auch Überschriften, Listen, Absätze u.ä – als einfachste Form eines Objektes – können so genannte seitenübergreifende Objekte repräsentieren.

Generelles Ziel der Definition von Objekten ist es, Abhängigkeiten zwischen HTML-Elementen und CSS-Deklarationen weitestgehend zu vermeiden. Hierzu empfiehlt Nicole Sullivan unter anderem folgende Grundsätze zu beachten:

1. Vermeide einen Zusammenhang zwischen Elementen und Klassendeklarationen
Deklariere .klassenname {...} statt div.klassenanme {...}
2. Vermeide Deklarationen, die an einen Elementbaum gebunden sind
Deklariere .klassenname {...} statt body #main #content .klassename {...}
3. Minimiere den Einsatz von CSS-Selektoren
Deklariere .klassenname {...} statt * .klassename {...}
4. Vermeide die Verwendung von ID Selektoren für inhaltliche Elemente
Deklariere .klassenname {...} statt #klassenname {...}

Die zwei Grundprinzipien von OOCSS

  1. Separiere die Struktur vom Erscheinungsbild/Aussehen
  2. Separiere Rahmenelemente von den Inhalten

Was sich auf den ersten Blick doch recht prosaisch und fast wie ein wir postulieren das Offensichtliche liest, ist ein einfacher, aber grundsätzlich vollständiger Ansatz, aus dem sich sämtliche Programmatik des Konzeptes ableiten lässt.

Prinzip 1: Separiere die Struktur vom Erscheinungsbild/Aussehen

Man findet auf fast allen Webseiten Boxen, die mit unterschiedlichen Inhalten unterschiedliche Funktionalität abbilden. Sei es eine Box, die die letzten fünf News-Meldungen anzeigt, Funktionen und Inhalte für die Anzeige von Wetterdaten beinhaltet, oder auch nur aus ein wenig Text plus einem fetten Button Jetzt kaufen besteht.
Allen dreien gemeinsam ist der Rahmen, der die Inhalte umgibt. Im OOCSS Ansatz würde dieser ein Strukturobjekt repräsentieren. Deklarationen für Strukturobjekte beziehen sich immer auf das Strukturobjekt allein. Hier werden Browser-Unterschiede ausgeglichen und grundsätzliche Darstellungen der Struktur festgelegt,- beispielsweise könnten wir unserer Box gerundete Ecken spendieren. Möchten wir nun zu einem späteren Zeitpunkt die gleiche Box für die Darstellung von Wetterdaten nutzen, deren Gestaltung aber einen blauen Hintergrund und 100px mehr Breite verlangt, erweitern wir das ursprüngliche Strukturobjekt um eine entsprechende Klasse. Diese Klasse erbt alle Eigenschaften unseres Strukturobjektes und nimmt die spezifischen, zusätzlichen Deklaration für die Wetterbox auf. So wird Redundanz vermieden und die Wiederverwendbarkeit gewährleistet, da wir weiterhin das gleiche Strukturobjekt nutzen.

Beispiel 2: Strukturobjekt erweitern

HTML:

...
...

CSS:

.box {width:300px;} .boxWeather {width:400px; background-color: blue;}

Prinzip 2: Separiere Rahmenelemente von den Inhalten

Nehmen wir als Beispiel wieder das eben erwähnte Box-Modul, dessen äußeres Rahmenelement das Strukturobjekt definiert und innerhalb des Modulrahmens beispielsweise mit einer Überschrift zweiten Grades und einem Absatz zwei inhaltliche, seitenübergreifende Objekte enthält. Diese beiden Objekte sollten unabhängig von den Deklarationen des Strukturobjektes, in dessen Kontext wir sie einsetzen, definiert sein. Legen wir zukünftig eine (News)Box an, die die gleiche Überschrift nutzen soll, können wir den zuvor erstellten Code einfach kopieren und an gewünschter Stelle innerhalb des neuen Moduls einsetzen, ohne neue Styles definieren zu müssen. Die Überschrift wird sich exakt so verhalten, wie wir es erwarten, da sie unabhängig vom jeweiligen Strukturobjekt deklariert ist. Gleiches gilt für Hyperlinks, Listen, Absätze und weiteren Elemente, die seitenübergreifend konsistent in Ihrer Ansicht sein sollen.

Beispiel 3: Wiederverwendung von seitenübergreifenden Objekten

CSS:

h2 {font-color: red; ...} p {line-height: 1.2em; ...}

HTML:

Überschrift im Standardmodul

Ein bischen Fliesstext

Eine Überschrift im abgeleiteten News Modul

Ein bischen Fliesstext

Wie beeinflusst OOCSS die Arbeitsweise von Entwicklern?

Während meiner Beschäftigung mit dem Konzept war ich beim Betrachten der CSS-Dateien aus dem bereitgestellten Framework zunächst etwas irritiert, dort fast ausschließlich Deklarationen ohne Kontext zu sehen. Es sah mir schlicht zu simpel aus und ich war kritisch, wie mit diesem Ansatz komplexe Anforderungen an den Seitenaufbau und die Gestaltung abgebildet werden können. Je länger ich mich aber mit dem Konzept auseinander setzte, desto deutlicher wurde, das es im Konzept um nichts anderes geht: Simplifizierung.

Wir Entwickler müssen uns im Rahmen dieses Ansatzes von dem Gedanken verabschieden, dass Komplexität und Flexibilität nur durch entsprechend komplexe Deklaration möglich wird. Gleichzeitig müssen wir lernen, alle inhaltlichen und strukturellen Teile einer Seite konsequent als voneinander unabhängig zu sehen. Nicole Sullivan nennt diese Teile Objekte, analog zum OO-Ansatz.

Hat man dieses erst einmal verinnerlicht, wird deutlich, in welchen Widerspruch dieser Ansatz zu der Arbeitsweise vieler Entwickler steht. Bedingt durch die Möglichkeiten, die uns die Sprache CSS mit kontextorientierten Deklarationen bietet, haben wir gelernt, diese auch – mehr oder weniger ausgeprägt – zu nutzen.

Die oftmalige Folge hiervon ist es allerdings, das unsere Dateien immer weniger universal werden und damit viele von uns gewünschten Merkmale – einfache Pflegbarkeit, Wiederverwendbarkeit, Skalierbarkeit u.a. – dadurch nicht mehr gewährleistet werden können.

Fazit

OOCSS zu verstehen bedeutet sich auf eine Anfangs flache Lernkurve einzulassen. Man wird konfrontiert mit neuen Begrifflichkeiten wie Objekte, Module, Skins, Komponenten und einem für Webentwickler ohne Programmierhintergrund ungewöhnlichen Ansatz. Hat man sich aber eingelesen, ist das Konzept verblüffend simpel und transparent. Während meiner Lektüre und dem Herumspielen mit dem bereitgestellten Framework war ich immer wieder erstaunt über die erreichbare Komplexität, resultierend aus wenigen Grundsätzen.

Vieles wird uns bekannt vorkommen und wir werden es mit einem "Kenn ich doch"–Kopfnicken aufnehmen. Dennoch ist es erfrischend und sehr informativ, Bekanntes in einem anderen Kontext zu lesen. Nicole Sullivan erfindet das Rad nicht neu, bietet uns aber eine neue, sich lohnende Sichtweise hierauf.

Videopräsentation des OOCSS Konzeptes auf der Web Direction North

Kommentare

Chris
am 06.07.2009 - 14:28

Super Artikel über ein Thema, das es in sich hat. Werd mir das in nächster Zeit ansehen und schön objekt-orientiert coden ;)
Vielen Dank!

Permanenter Link

Joker
am 07.07.2009 - 09:54

Sorry Jungs, aber das ist ja nun wirklich keine Neuigkeit. Bin bis zu diesem Artikel eigentlich davon ausgegangen, dass ein guter Coder sowieso auf diese Art und Weise sein css gestaltet. Finde es gerade echt erstaunlich, dass das nicht der Fall ist.

Permanenter Link
Jens Grochtdreis

Jens Grochtdreis (Webkraut)
am 07.07.2009 - 10:10

Neuigkeit ist in dem Sinne sicher der falsche Begriff. Ich finde es nicht falsch, sich mal Gedanken über die eigene Herangehensweise und den eigenen Codestil zu machen. Man muss dem Ganzen keinen neuen Namen geben - außer man ist Ami :-) Die dahinterstehenden Gedanken sind aber meiner Meinung nach für die meisten neu und im Projektalltag sicher auch immer wieder eine Herausforderung.

Permanenter Link

Peter Müller
am 07.07.2009 - 10:18

Interessanter Artikel von Kevin Yank dazu bei Sitepoint:

- First Look: Object Oriented CSS

Auch die Kommentare sind zum Teil lesenswert, z. B. der von Autistic Cuckoo aka Tommie Olson und die Antwort von Kevin Yank.

Permanenter Link

Ole
am 07.07.2009 - 10:23

Ich beschäftige mich auch seit ein paar Wochen mit dem Thema. Bisher habe ich bei großen Projekten auch modulbasiert (also die "Insellösung") gearbeitet, da es in Verbindung mit CM-Systemen einfacher zu handeln ist.

Der Vorteil bei der Insellösung ist ganz klar, daß ich nicht jedem Element einen Klassennamen zuweisen muß. Somit erhalte ich eine kompaktere HTML-Struktur, was wiederum den Vorteil der einfacherern Wartbarkeit mit sich bringt (siehe: Jens Meiert Blogpost). Denn am teuersten wird es immer dann, wenn man Änderungen am HTML Code machen muß.

Bei der modulbasierten Entwicklung sieht das dann so bei mir aus:

Überschrift im Standardmodul
Ein bischen Fliesstext

Ich spare mir 2 Container divs und einen Klassennamen, da ich alle Elemente innerhalb der Box über die Klasse "mod" ansprechen kann.

Das gleiche Objekt könnte bei einer komplexen Webseite mit der OOP Technik so aussehen:

Überschrift im Standardmodul

Ein bischen Fliesstext

...oder so ähnlich. Für meinen Geschmack zu viele Klassennamen (wie war dfas mit der sog. Klassitis?)!

Allerdings gehe ich komplett D'Accord mit der einfacheren Arbeit im Team, da es ganz klare Regeln gibt und man den Code leichter wiederverwenden kann.

Permanenter Link

Ole
am 07.07.2009 - 10:27

Sorry für den doppelpost, aber die Codebsp. wurden nicht richtig angezeigt...

Ich beschäftige mich auch seit ein paar Wochen mit dem Thema. Bisher habe ich bei großen Projekten auch modulbasiert (also die "Insellösung") gearbeitet, da es in Verbindung mit CM-Systemen einfacher zu handeln ist.

Der Vorteil bei der Insellösung ist ganz klar, daß ich nicht jedem Element einen Klassennamen zuweisen muß. Somit erhalte ich eine kompaktere HTML-Struktur, was wiederum den Vorteil der einfacherern Wartbarkeit mit sich bringt (siehe: Jens Meiert Blogpost). Denn am teuersten wird es immer dann, wenn man Änderungen am HTML Code machen muß.

Bei der modulbasierten Entwicklung sieht das dann so bei mir aus:


<div class="mod">
<div>
<h2>Überschrift im Standardmodul</h2>
<p>Ein bischen Fliesstext</p>
</div>
</div>

Ich spare mir 2 Container divs und einen Klassennamen, da ich alle Elemente innerhalb der Box über die Klasse "mod" ansprechen kann.

Das gleiche Objekt könnte bei einer komplexen Webseite mit der OOP Technik so aussehen:


<div class="mod roundedCorners weather">
<div class="inner">
<div class="hd">
<h2 class="bg sizeXL">Überschrift im Standardmodul</h2>
</div>
<div class="bd">
<p class="bold italic">Ein bischen Fliesstext</p>
</div>
</div>
</div>

...oder so ähnlich. Für meinen Geschmack zu viele Klassennamen (wie war dfas mit der sog. Klassitis?)!

Allerdings gehe ich komplett D'Accord mit der einfacheren Arbeit im Team, da es ganz klare Regeln gibt und man den Code leichter wiederverwenden kann.

Permanenter Link

LX
am 07.07.2009 - 11:16

Zunächst einmal ist dieser Ansatz schon seit mehreren Jahren bei vielen guten Entwicklern Normalität.

Zum anderen sehe ich Konzepte wie Objektorientierung teilweise kritisch - solange man sie als Konzepte begreift und sich somit die Fähigkeit behält, von ihnen abzuweichen, wenn es die Situation erfordert, ist alles in Ordnung. Wenn man jedoch anfängt, sie als Dogmen zu betrachten, hat man ein Problem.

Gruß, LX

Permanenter Link
Jens Grochtdreis

Jens Grochtdreis (Webkraut)
am 07.07.2009 - 12:21

@LX: Na, das würde mich ja mal interessieren, in welchen Projekten Du oder jemand anders diesen Ansatz schon eingesetzt hast. Das würde mich ehrlich interessieren. Ich habe bislang nicht den Eindruck gehabt, als würden Agenturen oder Freelancer in eine solche Richtung denken oder coden.

Ich mag mich täuschen. Deshalb wär ich für Anschauungsmaterial dankbar.

Permanenter Link
Olaf Gleba

Olaf Gleba (Autor)
am 07.07.2009 - 12:24

Zunächst einmal ist dieser Ansatz schon seit mehreren Jahren bei vielen guten Entwicklern Normalität.
Du glaubst gar nicht, was viele gute Entwickler in durchaus renommierten Agenturen so alles machen (müssen), um Deadlines einzuhalten und ggf. dem Chef noch ein Lächeln aufs Gesicht zu zaubern.

Aus meiner Sicht wichtig ist es, das vorgestellte Konzept tatsächlich nur als Ansatz verstehen. So ist das bereitgestellte Framework nur geeignet einen ersten Eindruck der praktischen Umsetzung zu bekommen. Letztlich sehe ich es aber nur als Aufforderung, sich innerhalb formaler Kriterien, die der Konzeptansatz beschreibt, sein eigenes Framework aufzubauen.

Permanenter Link

Gunther
am 07.07.2009 - 23:16

Ich möchte das Ganze mal aus dem Blickwinkel eines Laien betrachten (ich betreibe "Webpublishing" als Hobby und verdiene nicht meine Brötchen damit).

Meiner Meinung nach stimmt an dem Ansatz/ Konzept schon der Ausgangspunkt der Betrachtung nicht. Hier wird sozusagen vom CSS aus angefangen und das HTML "drumherum gebaut".

Der "klassische" Weg ist aber imho:
Informationen/ Daten -> Strukturierung durch(semantisch korrektes) (X)HTML -> Darstellung (je nach Ausgabemedium) per CSS

Der Fluch & Segen von CSS zugleich ist doch gerade der Kaskadeneffekt (Kaskade), der eine Eigenschaft, die einmal an einer gewissen Stelle vorgenommen wurde, ohne weiteres Zutun automatisch an alle anderen Unter-/ Kindelemente weitergibt (vererbt).

Will ich den "Fluch" (also die ggf. ungewollte Vererbung) vermeiden, muss ich aber auch gleichzeitig auf den "Segen", nämlich die kontextabhängige Darstellung, verzichten. Aber genau das ist imho eine der wesentlichsten und vorteilhaftesten Eigenschaften von CSS. Denn muss Darstellung nicht letztendlich auch immer kontextabhängig sein?

Es ist natürlich relativ einfach, genau dieses zu verhindern, indem ich quasi jedes Element "isoliere" und ihm eine eigene Klasse zuweise. Der daraus resultierende Quellcode erinnert mich zumindest stark an "DIV-Suppe".

Noch "unübersichtlicher" scheint mir die Sache zu werden, wenn ich das Ganze auch noch um die ggf. erforderlichen Teile ergänze, die für verschiedene Ausgabemedien erforderlich sind (worauf in den Beispielen wohlweislich verzichtet wurde).

"Verkauft" werden solche Dinge dann immer gerne mit so plakativen Argumenten wie "bessere Wartbarkeit des Codes" oder "größtmögliche Flexibilität und Wiederverwendbarkeit".

Bei vielen dieser und ähnlicher Argumentationen habe ich immer den Eindruck, dass davon ausgegangen wird, man würde heutzutage immer noch jede HTML-Seite einzeln (statisch) händisch erstellen. Aber wer bitte macht denn das? Der Normalfall dürfte doch wohl eher der sein, dass Seiten per Skript dynamisch "zusammengebaut" werden. Und genau hier halte ich den Ansatz wiederum für "probelamtisch". Denn hierbei muss mein Skript nicht nur "wissen" um welche Art "Objekt" es sich handelt, sondern um die korrekten Klassen zuweisen zu können, muss es zusätzlich auch noch den jeweiligen Kontext kennen.

Das ganze führt daher imho eher zu einer Verlagerung des Arbeitsaufwands von einer Seite auf die andere. Vergleichbar etwa mit dem Hebelgesetz, dessen wesentlichste Schlussfolgerung die ist:"Das heißt, eingesparte Kraft geht auf Kosten des Weges, die zu leistende Arbeit wird keineswegs weniger."

Unsere CSS-Datei(en) wachsen also linear im Verhältnis mit den der Seite hinzugefügten HTML-Elementen.

Nein, nur wenn man die Kaskade nicht richtig einsetzt/ verwendet. Egal welches "System" man nun seiner CSS-Datei zugrundelegt, jedes "Darstellungs-Objekt" braucht für jeden Kontext seine entsprechenden Eigenschaften, die einmal definiert werden müssen. Ich würde aber bspw. mal mit ziemlicher Sicherheit behaupten, dass das CSS für eine recht "einfache" Seite wie diese hier, nach dem "klassischen" Ansatz kleiner ist, als nach dem OOP Ansatz. Vom Quellcode ganz zu schweigen.

Was bei kleineren Seiten vielleicht nur marginale Bedeutung hat, bedeutet für Seiten, die eine hohe Besucherquote und damit eine hohe Last haben, ein Sterben auf Raten. Die Performance (und mittelfristig damit auch die Besucherzahl) sinkt linear zur Ausbaustufe der Seite

Auch das halte ich für ein häufig gebrauchtes Argument, welches imho heutzutage auch nur, wenn überhaupt, eine untergeordnete Rolle spielt. Denn dank weit verbreiteter Caching-Methoden und -möglichkeiten, in Verbindung mit immer schnelleren Servern und Übertragungsleitungen, sind ein paar KB mehr oder weniger an CSS-Datei wohl kaum ein Argument (verglichen bspw. mit einem einzigen Image auf einer Seite). Viel wichtiger erachte ich in diesem Zusammenhang den Punkt der Anzahl an Requests, vorallem der Unnötigen!

Und last but not least glaube ich noch nichtmal, dass das System eche Vorteile bei der Teamarbeit bietet (siehe 'Hebelegesetz'). Denn letztlich ist es doch auch immer ein "Henne - Ei" Problem. HTML-Code und CSS hängen nunmal untrennbar voneinander ab. Und ich code dann lieber erstmal abhängig von den jeweiligen Informationen/ Daten meinen HTML-Code und "baue" dann das CSS drumherum, als umgekehrt.

Zum Schluss möchte ich noch ein Beispiel anfügen, um evt. einen weiteren Blickwinkel/ eine weitere Perspektive aufzuzeigen:
Wenn du Architekt bist, und jeder Bauherr sein ganz eigenes Häuschen haben will, dann musst du jedes einzelne Haus von Grund auf neu planen, zeichnen, die Statik berechnen, etc. -> nix mit "Wiederverwendbarkeit"!

Vielleicht sollten "Webdesigner" sich auch mal mit dem Gedanken anfreunden, dass jede Website ein höchst individuelles Gebilde ist, und sich von daher von dem Gedanken/ Wunsch/ der Vorstellung verabschieden, dass Code wiederverwendbar sein muss/ soll?

Denn wenn ich "falsche Anforderungen" an etwas stelle, und es anschließend so weit "verbiege", bis es diese erfüllt, muss das nichts Positives sein.

Fazit:
Der Ansatz beinhaltet einige mehr oder weniger eigentlich selbstverständliche Grundlagen für das Erstellen von CSS. Darüber hinaus macht er den eigentlichen Vorteil von CSS zunichte. Es mag vielleicht einige wenige Ausnahmen geben, wo ein solcher Ansatz Vorteile bringt. Für die absolute Mehrheit (der One-Man Coder) wage ich das zu bezweifeln.

Permanenter Link

Dirk Jesse
am 08.07.2009 - 09:39

@Gunther

Bei vielen dieser und ähnlicher Argumentationen habe ich immer den Eindruck, dass davon ausgegangen wird, man würde heutzutage immer noch jede HTML-Seite einzeln (statisch) händisch erstellen. Aber wer bitte macht denn das? Der Normalfall dürfte doch wohl eher der sein, dass Seiten per Skript dynamisch "zusammengebaut" werden.

Genau das ist ein entscheidender Grund dafür, das zugrunde liegende Markup - entsprechend dem hier vorgestellten Konzept - vorausschauend zu planen. Denn während Änderungen in statischen HTML-Seiten vielleicht mühsam, aber meist dennoch relativ problemlos möglich sind, sieht es bei komplexen Content Management Systemen und deren Templateverwaltung schon deutlich schwieriger aus. Hier ist meist spezielles Fachwissen der Administratoren gefragt, demzufolge werden Änderungen dadurch aufwändiger und somit auch kostspieliger.

Denn dank weit verbreiteter Caching-Methoden und -möglichkeiten, in Verbindung mit immer schnelleren Servern und Übertragungsleitungen, sind ein paar KB mehr oder weniger an CSS-Datei wohl kaum ein Argument ...

Der oftmals so wichtige "erste Eindruck" entsteht beim ersten Besuch einer neuen Seite. Und in diesem Fall greifen Caching-Mechanismen im Client eben nicht. Und "ein paar Kilobyte" bedeuten für ISDN-Kunden oder auf Mobilgeräten mal schnell "ein paar Sekunden" mehr an Wartezeit. Ganz so einfach sollte man es sich in dieser Diskussion dann doch nicht machen.

Wenn du Architekt bist, und jeder Bauherr sein ganz eigenes Häuschen haben will, dann musst du jedes einzelne Haus von Grund auf neu planen, zeichnen, die Statik berechnen, etc. -> nix mit "Wiederverwendbarkeit"!

Und ob: Kein Architekt denkt sich jedesmal neu aus "wie" der Dachstuhl statisch funktioniert. Der Häuslebau ist - Individualität hin oder her - ein Musterbeispiel für das Baukastenprinzip und die Wiederverwendung bewährter Techniken und Systeme, zumindest aus meiner Sicht als Bauingenieur.

Der Ansatz beinhaltet einige mehr oder weniger eigentlich selbstverständliche Grundlagen für das Erstellen von CSS. Darüber hinaus macht er den eigentlichen Vorteil von CSS zunichte.

Hier widerspichst Du Dir selbst. Wenn es sich um selbstverständliche Grundlagen für die Anwendung von CSS handelt, wie können diese dann gleichzeitig jeden Vorteil nehmen?

Permanenter Link

Nils
am 08.07.2009 - 10:43

Sehr interessanter Artikel und für mich viele neue Dinge. Hab mich bisher noch nicht mit dem Thema beschäftigt, wenn ich aber hier die Kommentare so lese, dann sollte ich es aber bald mal tun.

Permanenter Link

Ingo
am 08.07.2009 - 17:25

Sehr interessanter Ansatz. Ist es meiner Meinung nach auf alle Fälle wert, sich damit auseinanderzusetzen.

Permanenter Link

Gunther
am 09.07.2009 - 16:25

@Dirk

Genau das ist ein entscheidender Grund dafür, das zugrunde liegende Markup - entsprechend dem hier vorgestellten Konzept - vorausschauend zu planen.

Noch so ein "frommer Wunsch"! ;-)
Wenn man immer und überall sein Markup und sein CSS-Code so vorausschauend planen könnte, hätte man ja gar kein Problem mit nachträglichen Änderungen. Ich glaube aber, dass die Praxis eben (meistens) anders aussieht.

Denn während Änderungen in statischen HTML-Seiten vielleicht mühsam, aber meist dennoch relativ problemlos möglich sind, sieht es bei komplexen Content Management Systemen und deren Templateverwaltung schon deutlich schwieriger aus. Hier ist meist spezielles Fachwissen der Administratoren gefragt, demzufolge werden Änderungen dadurch aufwändiger und somit auch kostspieliger.

Den letzten Teil verstehe ich nicht. Von wem reden wir hier denn die ganze Zeit, der Änderungen am Markup und CSS-Code vornehmen soll? Ist dafür nicht so oder so "Fachwissen" erforderlich?

Der oftmals so wichtige "erste Eindruck" entsteht beim ersten Besuch einer neuen Seite. Und in diesem Fall greifen Caching-Mechanismen im Client eben nicht. Und "ein paar Kilobyte" bedeuten für ISDN-Kunden oder auf Mobilgeräten mal schnell "ein paar Sekunden" mehr an Wartezeit. Ganz so einfach sollte man es sich in dieser Diskussion dann doch nicht machen.

Ich mache mir die Diskussion nicht einfach, aber sie wenig bis gar nichts mit dem eigentlichen Thema des Artikels zu tun, weshalb ich darauf nicht weiter eingehen wollte. Nur soviel: Was ist dir denn auf Dauer (und nur so kann man das imho betrachten, da man nie mit Sicherheit vorhersagen kann, über welche Seite ein Besucher auf die Site gelangt) lieber? Ein System, welches jede ausgelieferte HTML-Seite (unnötig) vom Quellcode her aufbläht, oder eine CSS-Datei, die ggf. ein paar KB mehr enthält?

Und ob: Kein Architekt denkt sich jedesmal neu aus "wie" der Dachstuhl statisch funktioniert. Der Häuslebau ist - Individualität hin oder her - ein Musterbeispiel für das Baukastenprinzip und die Wiederverwendung bewährter Techniken und Systeme, zumindest aus meiner Sicht als Bauingenieur.

Von jedes Mal "das Rad neu erfinden" war auch keine Rede! Das musst bei HTML, CSS & Co. genausowenig. Unter Wiederverwendbarkeit verstehe ich aber zumindest, dass ich Codezeilen ohne jegliche Änderung/ Anpassung 1:1 übernehmen kann. Und das wird imho bei CSS so gut wie nie der Fall sein!

Hier widerspichst Du Dir selbst. Wenn es sich um selbstverständliche Grundlagen für die Anwendung von CSS handelt, wie können diese dann gleichzeitig jeden Vorteil nehmen?

Nicht im Geringsten. Und das geht ganz einfach. Wenn du deine Tapete weiß streichen willst, kannst du nach Belieben weiße Wandfarbe verwenden. Sobald du aber auch nur kleinste Mengen einer anderen (Abtön)Farbe dazu mischt, hast du kein Weiß mehr. Und genau so ist meine Aussage zu verstehen. Dieses System verwendet ca. 5 Liter Weiß (~ selbstverständliche Grundlagen) und mischt dann aber noch eine/ mehrere andere Farbe(n) dazu (~ darüber hinaus macht er den eigentlichen Vorteil von CSS zunichte), sodass man im Endeffekt eben kein Weiß mehr hat. Ich sehe da keinen Widerspruch.

Permanenter Link

shorty
am 10.07.2009 - 11:24

Sorry Jungs, aber das ist ja nun wirklich keine Neuigkeit. Bin bis zu diesem Artikel eigentlich davon ausgegangen, dass ein guter Coder sowieso auf diese Art und Weise sein css gestaltet. Finde es gerade echt erstaunlich, dass das nicht der Fall ist.

kann ich nur so bestätigen hab nie groß was von dem "body #main #content .klassename" gehalten.

Permanenter Link

Johannes
am 11.07.2009 - 09:39

Also wenn das hier schon "objektorientiert" ist, dann ist BlueprintCSS das schon längst. Irgendwie kann ich dem Prinzip nicht viel neues abgewinnen (das ein oder adnere Detail ist ja sicher sinnvoll, aber nicht revolutionär...)

Permanenter Link

hans
am 13.07.2009 - 16:07

äh, das mache ich schon lange so. "objektorientiert" heißt das also ... aha *g* voll der hit.

Permanenter Link

dorni
am 15.07.2009 - 20:25

Ja, das ist auch nichts neues für mich... mach ich schon ne ganze Weile so.

Permanenter Link

Gunther
am 15.07.2009 - 21:24

@alle, die das "mache ich schon lange so" geschrieben haben
Mich würde ja sehr interessieren, wo ihr das schon lange so macht.

Auf den jeweils verlinkten Seiten nämlich mit Sicherheit nicht.

Mir persönlich ist nämlich bisher auch weder ein (halbwegs verbreitetes) Weblog-Script, noch ein CMS über den Weg gelaufen, welches alleine schon vom Markup her die nötigen Voraussetzungen für eine derartige Anwendung, bzw. einen derartigen OO Aufbau des zugehörigen CSS mitbringen würde.

Also wäre ich wirklich mal an praktischen Beispielen interessiert. Zumal hier ja gleich mehrere geschrieben haben, dass sie das schon lange so machen. Dann zeigt mal her - danke.

Permanenter Link

Holger
am 16.07.2009 - 08:18

Ich kann die Einwände von Gunther sehr gut verstehen.
Zwar ist der berühmt-berüchtigte CSSZengarden ein vielleicht schlechtes Beispiel, weil sehr speziell, aber ich kann mir eine Relisierung dieser Seite in OOCSS nicht wirklich vorstellen.
Ich mein, gerade die Kombination aus IDs und den kaskadierenden Klassen ist doch das, was CSS ausmacht und eben die schon zitierte "größtmögliche Flexibilität" ausmacht.
Bitte korrigiert mich ob meiner naiven Sicht.

Viele Grüße
Holger

P.S. würde mich auch für Links interessieren, wo OOCSS schon sinnvoll eingesetzt wird.

Permanenter Link

Otto
am 17.07.2009 - 08:32

@dorni

Ja, das ist auch nichts neues für mich… mach ich schon ne ganze Weile so.

Das nimmt dir aber keiner wirklich ab, wenn man deinem SEO-Spam-Link folgt, die Quelltexte der referenzierten Seiten mal näher besieht, Nils.

Permanenter Link

Eric
am 28.07.2009 - 17:00

Wer sich mal damit beschäftigt hat wie css/html von browsern interpretiert wird, sollte wissen dass es auf jeden Fall sinnvoller ist ein paar Zeilen im CSS File zu haben und genauere Selektoren zu schreiben anstatt auf beliebig tief verschachtelte Element nur mit einer Klasse zuzugreifen.

Theoretisch ist es natürlich eine gute Überlegung, auch wenn es tatsächlich absolut nichts neues ist, praktisch aber eher ungeeignet.

Permanenter Link

Eric
am 28.07.2009 - 17:12

… ein paar Zeilen mehr im CSS File …

Permanenter Link

Die Kommentare sind geschlossen.