Objektorientiertes CSS

[Ole]

Guten Morgen :)

seit einiger Zeit stolpere ich immer wieder über "Objektorientiertes CSS".
Aktuell gibt es einen Beitrag bei Webkrauts zu diesem Thema.

Der Ansatz klingt interessant. Was haltet ihr davon?

Gruß
Ole

[suit]

Der Ansatz klingt interessant. Was haltet ihr davon?

Ich verstehe nicht, was das mit Objektorientierung zu tun hat. Es scheint schlicht eine Möglichkeit zu sein, CSS sinnvoll zu gestalten.

Gleichzeitig wird aber verlangt, die Präsentation und Inhalt zu trennen aber die Sache "modular" zu gestalten, was dazu führt, dass man viele redundante HTML-Elemente hinzufügt.

"1. Vermeide einen Zusammenhang zwischen Elementen und Klassendeklarationen"

Warum? Wenn ich möchte, dass span-Elemente der Klasse .warnhinweis rot hinterlegt und Kursiv sind und div-Elemente der Klasse .warnhinweis einen dunkelroten Rahmen haben und eingerückt sind, ist es doch sinnvoll den Elementnamen in den Selektor aufzunehmen?

Natürlich sollten überflüssige Selektorketten vermieden werden - was das mit Objektorientierung zu tun hat, versteh ich immer noch nicht.

2. Vermeide Deklarationen, die an einen Elementbaum gebunden sind
Warum? Was spricht gegen html[lang="en"] .klasse {}?

3. Minimiere den Einsatz von CSS-Selektoren
Eh klar - aber was hat das mit Objektorientierung zu tun?

4. Vermeide die Verwendung von ID Selektoren für inhaltliche Elemente
Den versteh ich nicht. Klärt mich auf.

Ich habe irgendwie das Gefühl, dass diese "Objekte" dazu führen können, oft gebrauchte eigenschaften sinnloserweise zu gruppieren.

Besonders wenn ich sowas sehe ...

<div class="mod">  
        <div class="inner">  
                <div class="hd">Block Head</div>  
                <div class="bd">Block Body</div>  
                <div class="ft">Block Foot</div>  
        </div>  
</div>

... habe ich das Gefühl, da könnte sowas rauskommen:

.box {  
  border: 1px solid blue;  
  background: green;  
}  
  
.text {  
  color: white;  
}

<div class="box">  
  <div class="text">  
    foo bar  
  </div>  
</div>  

Auf der Seite sieht mann dann auch noch solche Glanzstücke:

<div class="leftCol myColumn"> ... </div>  

leftCol? Wie war das mit Darstellung und Inhalt trennen?

Darunter steht dann "Is this semantic? Will I end up with classes like .formYellow or tinyBlueH2?":

So wie ich das lese bläht sich das HTML durch die "Module" unnötig auf, das CSS schrumpft im Vergleich zu einem vernünftigen CSS unwesentlich bis garnicht oder wird sogar größer.

[molily]

Auf der Seite sieht mann dann auch noch solche Glanzstücke:

<div class="leftCol myColumn"> ... </div>

>   
> leftCol? Wie war das mit Darstellung und Inhalt trennen?  
  
Ich habe noch keine (größere) Site gebaut, wo man nicht mit solchen generischen Darstellungs-Klassen auskommt, vor allem für das Spaltenlayout. Meist hat man ja ein ungefähr ähnliches Spalten-Raster (z.B. drei Spalten mit bestimmter Aufteilung), darin gibts aber viele Kombinationen auf einer Seite (ein Teil geht über die ersten beiden Spalten, dann ein Teil über drei, dann ein Teil über die letzten beiden usw.).  
  
Wenn ich dutzende Seiten habe, wo das immer variiert, dann ist da selten ein gemeinsames Muster drin. Es macht i.d.R. keinen Sinn, das alles inviduell auszuzeichnen (also mit sprechenden IDs, die den Inhalt bezeichnen) und individuell zu stylen (höchstens \*zusätzlich\* zur Klasse, die die Styles erbt). Manchmal ist da auch gar keine Semantik drin, sondern die dieselben Inhalte sind nur aus Gründen der kompakten Präsentation über mehrere Spalten verteilt.  
  
Mathias

-- 
[JavaScript-Erweiterung für das SELFHTML-Forum](http://molily.de/selfhtml-forum-js/)

[suit]

Ich habe noch keine (größere) Site gebaut, wo man nicht mit solchen generischen Darstellungs-Klassen auskommt, vor allem für das Spaltenlayout. Meist hat man ja ein ungefähr ähnliches Spalten-Raster (z.B. drei Spalten mit bestimmter Aufteilung), darin gibts aber viele Kombinationen auf einer Seite (ein Teil geht über die ersten beiden Spalten, dann ein Teil über drei, dann ein Teil über die letzten beiden usw.).

Ich komme auch mit generischen Bezeichnern bei mehrspalten Layouts aus - bei mir heißen die aber #col1, #col2 usw - es kommt ab und an vor, dass das Layout geändert wird und die Linke Spalte plötzlich rechts ist oder umgekehrt - aber bezeichner wie "leftCol" halte ich für "gefährlich".

Manchmal ist da auch gar keine Semantik drin, sondern die dieselben Inhalte sind nur aus Gründen der kompakten Präsentation über mehrere Spalten verteilt.

Aber auch dann haben sie eine logische Abfolge, die mit #col1, #col2 und #col3 gut ausgezeichnet ist.

Ob die erste "Spalte" dann oben Quer ist und die anderen beiden drunter und nebeneinander oder alle drei nebeneinander sind spielt dann keine Rolle.

Es gibt dann kein #obenquer, #links und #rechts oder #links, #mitte, #rechts.

[Tobias Hahner]

Hallihallo!

Ich komme auch mit generischen Bezeichnern bei mehrspalten Layouts aus - bei mir heißen die aber #col1, #col2 usw - es kommt ab und an vor, dass das Layout geändert wird und die Linke Spalte plötzlich rechts ist oder umgekehrt - aber bezeichner wie "leftCol" halte ich für "gefährlich".

Manchmal ist da auch gar keine Semantik drin, sondern die dieselben Inhalte sind nur aus Gründen der kompakten Präsentation über mehrere Spalten verteilt.

Aber auch dann haben sie eine logische Abfolge, die mit #col1, #col2 und #col3 gut ausgezeichnet ist.

Noch sinnvoller ist es IMHO, die IDs und Klassen streng nach dem Inhalt zu benennen:
#hauptmenue, #untermenue, .aktuell usw.
Ich hatte bisher eigentlich keinen Fall, wo das nicht möglich gewesen wäre.

Nur so hat man meiner Meinung nach eine Chance, der Seite ein neues Layout zu verpassen, ohne das Markup grossartig verändern zu müssen, oder, was noch schlimmer wäre: das CSS in seinen Bezeichnern völlig zu entstellen.

Beste Grüße,
   Tobias Hahner

[LX]

Die Realität zeigt nun mal immer wieder, wie es mit solchen Konzepten ist: gesunder Menschenverstand schlägt selbst die besten Konzepte.

Ich sehe derartige Anleitung übrigens gern als den Versuch, Entwickler für PHBs vorhersagbarer zu machen, bzw. dem Pointy Haired Boss einen Hebel zu geben, den er beim eigenen Versagen beim Entwickler anwenden kann: "der Code muss noch Objektorientierter werden...".

Gruß, LX

[mrjerk]

Moin,
Ich denke, es geht eher darum, die objektorientierte Denkweise und die Grundprinzipien in das CSS-Design zu übernehmen - dass das dann in Einzelfällen durchbrochen werden kann & sollte, steht ausser Frage, ebenso wie man die objektorientierten Entwurfsmuster in der SW-Entwicklung durchbrechen kann (und machmal muss), wenn es sinnvoll ist.
Neu ist der Ansatz allerdings in der Tat nicht, denn für mich sind viele OO Konzepte in CSS an sich inhärent (Vererbung, Kappselung,...)

Warum? Wenn ich möchte, dass span-Elemente der Klasse .warnhinweis rot hinterlegt und Kursiv sind und div-Elemente der Klasse .warnhinweis einen dunkelroten Rahmen haben und eingerückt sind, ist es doch sinnvoll den Elementnamen in den Selektor aufzunehmen?

Betrachtet man CSS und HTML als völlig unabhängig Einheiten Inhalt vs. Präsentation), so dürfen diese - streng genommen - nicht in Beziehung gesetzt werden.
Eine CSS-Deklaration hat es (zumindest wenn man so denken will) nicht zu interessieren mit welchem Inhalt sie verknüpft wird, also hat (wieder streng genommen :)) ein Elementname darin nichts verloren.

Natürlich sollten überflüssige Selektorketten vermieden werden - was das mit Objektorientierung zu tun hat, versteh ich immer noch nicht.

ACK. Es ist ein Grundprinzip der Software-Entwicklung an SICH, dass man wiederverwendbar programmiert. Eine Funktion, ein Objekt, eine Prozesdur,... sollte IMMER so generisch wie möglich gehalten werden und so wenig wie möglich mit anderen Strukturen "verwoben" sein, damit eine universelle Einsetzbarkeit gegeben ist.
Mit OO hat das nichts zu tun, das gilt für die prozedurealen Programmierung, für CSS-Design und HTML-Auszeichnung ebenso - nur schreiben es sich die Objekt-Jongleure halt besonders gern auf die Fahne :)

4. Vermeide die Verwendung von ID Selektoren für inhaltliche Elemente
   Den versteh ich nicht. Klärt mich auf.

Mein Hirngespinnst dazu:

<li id="listenElement_3" class="listenelement">...</li>

mit

  
.listenelement {color: red;}  

könnte man sich vielleicht irgendwie so denken:

class Listenelement extends li {
   public void listenelement() {this.style.color = "red";}
}

Listenelement listenElement_3 = new Listenelement();

Nimmt man jetzt eine CSS-Definition wie

  
#listenelement_3 {font-weight: bold;}  

dann wäre das etwas wie:
listenElement_3.setFontWeight("bold");

Tja, ist dies nun aus objektorientierter Sicht "unschön"?
Wäre es schöner zu schreiben:

<div class="listenelement">
   <li id="listenElement_3" class="specialElement">...</li>
</div>

  
.specialElement {font-weight: bold;}  

(die mangelnde Validität von divs in ULs lasse ich an dieser Stelle unter den Tisch fallen :) )

respektive:

class SpecialElement extends Listenelement {
   public void listenelement() {this.style.fontWeight = "bold";}
}

Listenelement listenElement_3 = new SpecialElement();

?
*am-kopf-kratz* ich weiß es nicht...

So wie ich das lese bläht sich das HTML durch die "Module" unnötig auf, das CSS schrumpft im Vergleich zu einem vernünftigen CSS unwesentlich bis garnicht oder wird sogar größer.

Nun ja, "schöne Objektstrukturen" bauschen Sourcecode zunächst einmal immer mehr auf. Sparsamer wird der Code erst dadurch, dass man wiederverwenden kann (und will :) ).

Die Frage ist, wie der Tradeoff zwischen "aufgeblähtem Quellcode" und "sauberen Objektstrukturen" zu bewerten ist.
Ich glaube, die Frage muss man von Fall zu Fall entscheiden.

So long,
Jörg

[Gunnar Bittersmann]

@@suit:

nuqneH

Was spricht gegen html[lang="en"] .klasse {}?

So einiges.

Qapla'

[suit]

So einiges.

Natürlich hast du recht - der Selektor ist verbessernugsbedürftig :)

[Malcolm Beck´s]

hi,

seit einiger Zeit stolpere ich immer wieder über "Objektorientiertes CSS".
Aktuell gibt es einen Beitrag bei Webkrauts zu diesem Thema.

Da gibt es einen sehr interessanten Artikel zu diesem Thema, hat aber mit der Bezeichnung "Objektorientiertes CSS" nichts zutun.
Ich denke mal, man versucht hier mit dem Begriff "OOP" interesse für diese Technik zu erwecken, warum auch immer.

Der Ansatz klingt interessant. Was haltet ihr davon?

Gibt mittlerweile soviele Ansätze, dass ich garnicht mehr weiss, wo ich ansetzen soll.

mfg

[Ole]

Hi,

Gibt mittlerweile soviele Ansätze, dass ich garnicht mehr weiss, wo ich ansetzen soll.

Da Frau Sullivan "Performance Engineer & International Evangelist" bei Yahoo! ist, dürfte es relativ wahrscheinlich sein, dass sie bei ersterem auch die Finger mit im Spiel hatte.

Außerdem sind grade diese beiden Ansätze nicht wirklich weit voneinander entfernt :)

Gruß
Ole

[Malcolm Beck´s]

hi,

Außerdem sind grade diese beiden Ansätze nicht wirklich weit voneinander entfernt :)

Das vereinfacht die Optimierung ;)

Das zweite ist die ablöse des ersten -- yslow wird seit FF 3.5 nicht mehr weiter entwickelt, dafür aber Pagespeed.

mfg

[Malcolm Beck´s]

hi,

yslow wird seit FF 3.5 nicht mehr weiter entwickelt, dafür aber Pagespeed.

Korrektur: gab gerade ein Update für YSlow, allerdings funktioniert das Tool -- zumindest bei mir -- nicht mehr richtig; Bspw. der Button "Run test" funktioniert nicht, nur "Autorun" funktioniert.

mfg

[Gunther]

Hallo Ole.

Der Ansatz klingt interessant. Was haltet ihr davon?

Da könnte ich jetzt auch einen ellenlangen Kommentar mit meiner Meinung & meinen Ansichten zu dem Thema verfassen, was aber aus Zeitgründen nicht geht.

Zusammengefasst lässt sich meine Meinung aber ungefähr mit einem Satz aus Wikipedia - Deklarative Programmierung formulieren:"Deklarative[1] Programmierparadigmen stehen insbesondere imperativen und objektorientierten Paradigmen in ihrer Akzeptanz nach. Man spricht gern von sogenannten Akademiker-Sprachen.". Und für diese "Zielgruppe" mag das ein "interessanter" Ansatz sein - für mich nicht.

[1] Cascading Style Sheets (Abk.: CSS, [kæsˌkeɪdɪŋˈstaɪlʃiːts]) ist eine deklarative Stylesheet-Sprache für strukturierte Dokumente. (http://de.wikipedia.org/wiki/Cascading_Style_Sheets)

Gruß Gunther

[Ole]

Hallo Gunther

Der Ansatz klingt interessant. Was haltet ihr davon?

"[...]Man spricht gern von sogenannten Akademiker-Sprachen.". Und für diese "Zielgruppe" mag das ein "interessanter" Ansatz sein - für mich nicht.

Ich bin kein Akademiker :( ... ;)

Ich habe nicht den Eindruck, dass Frau Sullivan eine Theoretikerin ist, die Ansätze jenseits der Realität entwirft (ich weiß, das hast du auch nicht behauptet :)). Vielleicht ist für (einige von) uns das Konzept nicht das Wahre, weil es so wie ich verstanden habe für Webseiten konzipiert wurde die i.d.R. nichts mit dem zu tun haben, dass wir konzepieren und/oder betreuen (mehrere Zehntausend Unique User und mehrere Millionen Zugriffe).

Gruß
Ole

[Gunther]

Hallo Ole!

Ich bin kein Akademiker :( ... ;)

Ich auch nicht. ;-)

Ich habe nicht den Eindruck, dass Frau Sullivan eine Theoretikerin ist, die Ansätze jenseits der Realität entwirft (ich weiß, das hast du auch nicht behauptet :)). Vielleicht ist für (einige von) uns das Konzept nicht das Wahre, weil es so wie ich verstanden habe für Webseiten konzipiert wurde die i.d.R. nichts mit dem zu tun haben, dass wir konzepieren und/oder betreuen (mehrere Zehntausend Unique User und mehrere Millionen Zugriffe).

Ich habe mich jetzt doch entschlossen, einen etwas ausführlicheren Kommentar dazu zu schreiben. Allerdings habe ich das direkt auf Webkrauts gemacht (siehe Kommentar Nr. 10 - kann man leider nicht direkt verlinken).

Gruß Gunther

[Malcolm Beck´s]

hi,

(siehe Kommentar Nr. 10 - kann man leider nicht direkt verlinken).

Doch, kann man -- nur hat wohl Zensursula zugeschlagen, denn es geht nur bis Comment 9.

Hier wäre dir sowas ja nicht passiert ;)

mfg

[Gunther]

Hi,

(siehe Kommentar Nr. 10 - kann man leider nicht direkt verlinken).

Doch, kann man -- nur hat wohl Zensursula zugeschlagen, denn es geht nur bis Comment 9.

Stimmt, jetzt hab' ich es auch kapiert. Bei mir ist er auch nachwievor vorhanden: Mein Kommentar auf Webkrauts

Gruß Gunther

[Malcolm Beck´s]

hi,

Stimmt, jetzt hab' ich es auch kapiert. Bei mir ist er auch nachwievor vorhanden: Mein Kommentar auf Webkrauts

Lösche mal deinen Cache und alle Cookies -- und um ganz sicher zu gehen im Anschluss „Strg + F5“.

mfg

[Gunther]

Hi,

Lösche mal deinen Cache und alle Cookies -- und um ganz sicher zu gehen im Anschluss „Strg + F5“.

jo, wech isser!
Und jetzt hab' ich ihn nur zu Hause auf dem Rechner abgespeichert. Mal gucken, wenn er bis heute Nachmittag dort nicht (wieder) auftaucht, dann poste ich ihn halt hier nochmal.

Vielleicht war er den Webkrauts auch zu "laienhaft"? ;-)

Gruß Gunther

[Gunther]

Hi,

ich nochmal. Kommentare werden moderiert auf Webkrauts, wofür ich auch vollstes Verständnis habe. Als Autor ist der Kommentar aber immer sichtbar, auch wenn er noch nicht freigeschaltet ist.

Jetzt ist er also für Jedermann sichtbar und unter http://www.webkrauts.de/2009/07/06/objektorientiertes-css-eine-einfuehrung/#comment-26564 zu finden.

Sorry for the confusion.

Gruß Gunther

[Detlef G.]

Hallo Gunther

Ich habe mich jetzt doch entschlossen, einen etwas ausführlicheren Kommentar dazu zu schreiben. Allerdings habe ich das direkt auf Webkrauts gemacht (siehe Kommentar Nr. 10 - kann man leider nicht direkt verlinken).

Bitte stelle deinen ausführlicheren Kommentar auch hier ein, wenn es dir ohne zu großen Aufwand möglich ist, Webkrauts hat er wohl so missfallen, dass es ihn dort überhaupt nicht gibt.

Auf Wiederlesen
Detlef

[Struppi]

Der Ansatz klingt interessant. Was haltet ihr davon?

Es ist immer wieder erstaunlich, wie mit Hilfe von irgendwelchen Buzzwords, Selbstverständlichkeiten und in diesem Fall eine völlig aus der Luft gegriffene Begrifflichkeit verwendet wird und dann sich eine Szene drauf stürzt um das hypen.

Ich seh das was suit. Was soll der Begriff OO im zusammenhang mit CSS? Er macht keinen Sinn, denn alles einer HTML Seite ist ein Objekt, aber es gibt hier keine Kapselungsmöglichkeiten und mit Vererbung muss man bei CSS sehr vorsichtig sein. Kapselung und Vererbung sind aber die wichtigsten Begriffe der Objektorientierten Programmierung. Was bleibt also an OO übrig? In meinen Augen nichts. Im gegenteil, OO ist im zusammenhang mit CSS sogar eher gefährlich, wenn ich z.b. an Vererbung oder Polymorphie denke, dabei kommt es immer wieder zu Problemen, z.b. wegen der Spezifität.

OOCSS halte ich für Unsinn.

Struppi.

[hotti]

Full ack Struppi, btw., seit Jahren setze ich Webprojekte um, aber dass ich das objektorientiert mache, hab ich erst vorn paar Tagen erfahren ;-)

Hotte

[LX]

Objektorientierung ist ein Konzept. Wie alle Konzepte hat es Vor- und Nachteile.

Der Kernpunkt besteht darin, zu wissen, wann man Vorteile daraus hat, ein bestimmtes Konzept einzusetzen. Unreflektiertes Umsetzen von Konzepten schafft üblicherweise mehr Probleme als es löst.

Gruß, LX

[Klawischnigg]

Hi there,

Der Ansatz klingt interessant. Was haltet ihr davon?

Gar nichts. CSS ist keine Programmiersprache und selbst dort sind objektorientierte Verrenkungen oft ein Graus. Abgesehen davon, was wäre nicht objektorientiertes CSS? CSS, das sich mit nichts, nicht einmal mit der Darstellung von HTML-Objekten beschäftigt?

[suit]

CSS ist keine Programmiersprache

Das hatten wir doch schon :) CSS ist eine deklarative Sprache - man kann zwar nicht viel damit Programmieren, aber ein paar Dinge gehen schon :)