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 :)
- 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