Sagen wir, Sie haben ein Modul. Jede Website hat Module, oder?
<div class="module">
</div>Perfekt! Wir haben es geschafft!
Aber jetzt kommt eine neue Situation™. Dieses Modul wird nicht exakt so funktionieren, wie es ist. Es ist ziemlich nah dran, aber in dieser neuen Situation™ benötigt das Modul einen zusätzlichen unteren Rand.
Wie gehen Sie damit um? Lassen Sie uns einige Möglichkeiten erkunden.
Body-Klasse beeinflusst es
Sind alle Module auf einer bestimmten Seite oder in einem bestimmten Bereich Ihrer Website so? Vielleicht können Sie dieser Seite (oder diesem Bereich) eine Klasse hinzufügen.
<body class="books-page">
...
<div class="module">
</div>.module {
/* normal style */
}
body.books-page .module {
/* variation styles */
}Sie müssen die .books-page nicht wirklich mit einem Tag versehen, aber ich mache das oft, weil es in diesem Fall keine große Sache ist und mich daran erinnert, was vor sich geht.
Sass ist in diesen Situationen nützlich, da die Verschachtelung den Raum irgendwie zusammenbindet.
.module {
/* normal style */
aside.books & {
/* variation style */
}
}Ganz neue Klasse
Vielleicht ist der neue Stil anders genug, dass Sie ihm einen anderen Namen geben werden.
<div class="solitary-module">
</div>.module {
/* normal style */
}
.solitary-module {
/* alternate style */
}Wenn die Stile ziemlich ähnlich sind, könnten Sie
.module, .solitary-module {
/* normal style */
}
.solitary-module {
/* variation styles */
}Was genau macht @extend in Sass
.module {
/* normal style */
}
.solitary-module {
@extend .module; /* could be a %placeholder selector */
/* variation style */
}Klassen verdoppeln
Vielleicht erstellen Sie eine zusätzliche Klasse, aber diese Klasse ist nicht dazu gedacht, eigenständig zu funktionieren. Sie ist nur eine Variation.
<div class="module module-books">
</div>.module {
/* normal styles */
}
.module.module-books {
/* variation styles */
/* you don't HAVE to double up the classes here in the CSS, but it enforces the connection (while increasing specificity) */
}Datenattribut-Variationen
Ich denke nicht, dass das besonders verbreitet ist, aber ich mag es irgendwie.
<div class="module" data-variation="books">
</div>Attribute sind wie Klassen (gleiche Spezifität), können aber Werte haben.
.module {
/* normal styles */
}
.module[data-variation="books"] {
/* variation styles */
}Liest sich gut.
Inline-Styles
Ist diese Variation *selten*? Vielleicht reicht ein Inline-Stil.
<div class="module" style="margin-bottom: 40px;">
</div>Typischerweise verpönt (nicht wiederverwendbar), aber wenn es eine einmalige Sache ist, erfüllt es seinen Zweck.
Shame.css
Man kann es immer später mit shame.css erledigen!
<div class="module chris-did-this">
</div>/* I will totally deal with this later I promise */
.chris-did-this {
/* variation styles */
}Wie machen Sie das?
Datenattribute sind dazu gedacht, Daten zu transportieren, daher fühlt es sich seltsam an, sie zum Stylen zu verwenden.
Ich persönlich bin für die Idee, eine zusätzliche Klasse hinzuzufügen (doppelte Klasse) für verschiedene Variationen. Es fühlt sich einfach "richtig" an und bewahrt den modularen Aspekt.
Ich stimme Ihnen zu, dass Datenattribute für den Transport von Daten gedacht sind, aber sie können auch für Stile verwendet werden, da wir die Anzahl der Klassen, die wir dem DOM hinzufügen, reduzieren wollen, und oft kann ein Datenattribut hilfreich sein, um den Code semantischer zu machen.
Alles, was den Code weniger und sauberer macht, sollte bevorzugt werden.
Ich persönlich verwende die Varianten „zusätzliche Klasse hinzufügen“ oder „Body-Klasse beeinflusst es“. Sie sind einfach und halten Sie davon ab, Ihr Stylesheet zu überladen. Wenn ich dies jedoch mehr als ein paar Mal tun muss, gehe ich zurück und erstelle es neu, um flexibler zu sein.
Das Nützliche an Datenattributen ist, dass Sie das Hinzufügen der Klasse vollständig überspringen und einfach Attribute nutzen können.
Zum Beispiel könnte dies ein Standardmodul sein
Und das könnte ein schickes Modul sein
Der CSS ist ziemlich geradlinig
Sie können auch Ihre eigenen benutzerdefinierten Modul-spezifischen "Klassen" erstellen, indem Sie den
[~=]Selektor verwenden.Es scheint, dass einige meiner Codeblöcke nicht ganz richtig waren.
Das Standardmodul ist
und das schicke Modul ist
Hmm, diese Idee gefällt mir irgendwie..
Die Frage ist, sind diese Datenattribute semantischer als Klassen, oder sind sie weniger? Wann wählen Sie, welche Sie verwenden?
Ich bin persönlich ein Fan der "Ganz neue Klasse"-Methode, da die Logik der OOP-Prinzipien ähnelt, bei der die Formatierung des Klassennamens
.super-klasse--unterklassewäre.Dies ermöglicht es regulären Klassennamen, Bindestriche zu verwenden, während der doppelte Bindestrich anzeigt, dass die Superklasse von einer Unterklasse erweitert wird, wo Regeln hinzugefügt und von der Superklasse geerbte Regeln überschrieben werden können.
Schlechte Idee. Leute werden denken, dass Sie BOM verwenden und verwirrt sein, dass Sie es nicht verwenden.
Prost.
Ich muss zustimmen, dass ich nicht glaube, dass es eine gute Idee ist und keine OOP-Vererbungsprinzipien impliziert. Denken Sie zum Beispiel an eine Java-Klasse. Es ist eine Weile her, aber wenn ich mich richtig erinnere, ist es etwas wie public Mustang extends Car{} (Ich arbeite seit Jahren mit C#, aber viele Sprachen verwenden eine Syntax, die dem nahe kommt). Was Sie andeuten, ist fast umgekehrt, und ohne einen Präprozessor wäre es das vollständige Gegenteil von Vererbung, da Sie zwei CSS-Klassen pflegen müssten, wenn sich die Basisklasse ändert.
Dennoch bin ich ein Fan des menschlich lesbaren doppelten Klassenstils. Bei Programmiersprachen kommt die Basisklasse zuletzt und in Markup steht sie zuerst, aber es ist kein kompliziertes Konzept zu erfassen und entspricht eher dem, was Programmierer gewohnt sind, und schließlich wollen wir uns in eine Welt bewegen, in der wir Aufgaben trennen, sodass die Leute, die an den Stilen arbeiten, nicht auch die Leute sein müssen, die HTML schreiben. Je einfacher wir das Anwenden von Stilen machen (Klasse plus Klasse plus Klasse ergibt Ergebnis), anstatt eine Stilvorlage nach der spezifischen Klasse für einen Button mit rotem Hintergrund zu durchsuchen.
Außerdem würden Sie viele kaum genutzte Klassen erstellen und die Ladezeit für sehr spezifische Instanzen erhöhen, anstatt wiederverwendbare Komponenten zu fördern.
Bearbeiten (fehlt mir etwas oder kann ich meinen ursprünglichen Beitrag nicht von meinem Tablet aus bearbeiten?)
Ich verstehe, dass das, was Sie tun, die Vererbungsregeln nicht wirklich bricht, obwohl es sie verkompliziert, indem es mehrere Varianten erstellt, die Endbenutzer durchsuchen müssen, um das zu bekommen, was sie brauchen, anstatt Klassen zu kombinieren. Es verursacht auch viel Mehraufwand für wenig Ertrag. Ich entschuldige mich für die fälschliche Annahme, dass Sie Basis- und Unterklassen mit Ihrem Modell ändern müssten, stehe aber weiterhin dazu, dass je spezifischer Untermodule werden, desto mehr Wartung erforderlich ist, da für jede Instanz neue Klassen hinzugefügt werden müssen, anstatt eine Entsorgung gemeinsamer Klassen zur Erstellung von Modulen zu haben. Verzeihen Sie mir, ich bin auf einem Tablet und es ist 2 Uhr morgens. Aber ich bleibe bei meiner Haltung ^_^
Danke für das Feedback. Konstruktive Kritik ist immer gut, und ich gebe zu, dass dieses Modell nicht für alle Projekte gut funktioniert und ich oft stattdessen das doppelte Klassenmodell verwenden musste.
@wqeqwewq Ich bin mit dem Begriff BOM nicht vertraut und eine Google-Suche ergab sehr wenig. Wenn Sie etwas wie BEM meinen, dann sehe ich Ihren Punkt und es könnte verwirrend sein, aber es ist nur ein Problem, wenn Sie mit einem Team arbeiten oder etwas für die breite Webentwicklergemeinschaft veröffentlichen.
@Eric Gute Punkte, aber abgesehen von der Philosophie hinter der Benennung und Formatierung dieser beiden Beispiele sehe ich keinen technischen Unterschied:
.baseclass--modifierund.superclass--subclassWas die Reihenfolge von Superklasse und Unterklasse betrifft, haben Sie Recht. PHP, Java und ActionScript (unter anderem) verwenden die SyntaxstrukturSubclass extends Superclass {}. Ich bin mir dessen sehr bewusst und formatiere die CSS-Klassen absichtlich so, weil es für mich zumindest schneller und einfacher ist zu erkennen, was eine Klasse tut, und die Organisation in der CSS-Datei beibehalten wird.Was die Probleme betrifft, die entstehen, wenn Module immer komplexer werden und somit eine völlig neue Unterklasse erforderlich ist, machen Sie einen guten Punkt – mehr Overhead für wenig Ertrag. Eine Möglichkeit, dies zu überwinden, ist die Verwendung einer Mischung aus dem doppelten Klassenmodell (als Utility-Klassen) mit dem Super-/Unterklassenmodell.
Wenn ich mit einem Team arbeite oder etwas für die Öffentlichkeit veröffentliche, halte ich mich sicherlich an den Styleguide und das bereits vorhandene Formatierungsmodell, aber für meine persönlichen Projekte funktioniert dieses Modell gut für mich. Trotzdem schätze ich Ihre Kommentare und muss darüber nachdenken, ob dieses Modell für mich das beste ist.
Entschuldigung, meinte BEM, nicht BOM
http://csswizardry.com/2013/01/mindbemding-getting-your-head-round-bem-syntax/
Meistens "verdopple ich die Klassen", obwohl ich diese Spezifität in meinem CSS selten vermeide, wenn ich kann (Ausnahme sind Zustände einer Klasse, wie
is-active). Wenn ich das Gefühl habe, dass das neue Muster *jetzt* ähnlich ist, aber ein hohes Risiko besteht, dass es sich in dramatischer Weise aufspaltet, werfe ich Vorsicht in den Wind und dupliziere Sachen in einem völlig separaten Muster. Aber das passiert seltener.Und ich habe auch nichts gegen die Anwendung der alten
shame.css-Technik von Zeit zu Zeit, besonders wenn Abgabetermine näher rücken. "Echte Künstler liefern" und so.Leute, genau deshalb haben wir "Utility-Klassen".
Um nur einen Rand hinzuzufügen, ja. Aber Utility-/Helper-Klassen sind nicht dazu da, andere Klassen zu erweitern.
Ja, genau. Ich hätte spezifischer sein sollen, dass ich das für genau dieses Beispiel meinte.
Für ein paar kleinere Korrekturen, die einmalig sein könnten, verwende ich Utility-Klassen. Wenn ich das Gefühl habe, dass ich zu viele hinzufüge und es ein Stil ist, der mehr als einmal verwendet wird, mache ich daraus einen Komponenten-Modifikator oder eine neue Komponente.
Jede Situation erfordert unterschiedliche Lösungen. Das richtige zu wählen, kommt mit Erfahrung und der Pflege großer Projekte über längere Zeiträume.
Nicolas Gallagher hielt einen großartigen Vortrag bei der CSSconf AU darüber und wie man vorsichtig mit seinen Abstraktionen umgeht.
Das war mein erster Gedanke. Haben Sie einige Utility-Klassen, die einen standardisierten "Abstand" für den Rand haben. Machen Sie daraus eine Variable in Sass/Less. Ich verwende sogar eine Halb-Abstands-Variable für den Fall, dass die normale Randabstands-Variable zu groß ist.
Ich habe die doppelte Klasse schon oft benutzt, aber wenn Sie jemals mehr als ein paar Varianten haben, wird es schmerzhaft zu verwalten, besonders wenn Sie jemals die Basis bearbeiten wollen.
Heutzutage wickle ich das Modul vielleicht in ein Div und style dieses Div, aber meine bevorzugte Methode ist es,
(mit less)
.module-styles(){
margin: awesome;
border: snazzy;
…
}
.module-foo{
.module-styles();
margin: ballin’;
}
.module-bar{
.module-styles();
margin: stellar;
}
Ihre gerenderte CSS hat redundante Stile, aber wenn Ihre Anwendung im Jahr 2014 leistungsempfindlich ist, habe ich keine Ahnung, was Sie tun. Indem Sie einen Stil-Override in den "semantischen" Klassendefinitionen durchführen, müssen Sie sich nicht mit der Klassenspezifität auseinandersetzen, nur mit der Stilreihenfolge, was ich viel einfacher finde.
Wenn Sie den BEM-Stil verwenden (den ich GRM nenne – Gruppe, Rolle, Modifikator :))
http://codepen.io/anon/pen/dqGyr
Ich bin dem vor kurzem begegnet, so mache ich das
[class*=module] { padding: 10px; display: inline-block; background-color: #ccc; } .module-pad20 { padding: 0 20px; }Gibt es einen Grund für die doppelte Deklaration?
/*why?*/ .module, [class*=module__] {... /*wouldn’t this be better?*/ [class*=module] {...Vielleicht ein Fallback für ältere Browser?
(habe ich von 24ways, falls jemand interessiert ist, hier ist es: http://24ways.org/2012/a-harder-working-class/)
@Ralfff, der Grund dafür ist, dass wenn in der CSS, die auf der Seite geladen wurde (könnte auch eine Drittanbieter-CSS sein), zufällig etwas wie
.awesome-modulesoder.user-feedback-modulevorhanden ist, Ihre Stile ([class*=module]) angewendet werden und Sie sie neu definieren müssten. Wenn Sie jedoch die Namenskonvention befolgen, die BEM (wieder, ich nenne es GRM :)) verwendet (http://bem.info/method/definitions/, http://csswizardry.com/2013/01/mindbemding-getting-your-head-round-bem-syntax/), bei der Sie die CSS-Klassennamen in 3 Teile unterteilen:.group--role__modifier, zum Beispiel (nur aus dem Gedächtnis :)):.button, .button__primary, .button__primary--alternative, .button--icon, .button--icon__arrowUp, ist es ziemlich unwahrscheinlich, dass Sie in eine solche Situation geraten.Ich kann vermuten, dass Sie verwirrt sein könnten – es ist ziemlich unwahrscheinlich, dass ich in eine solche Situation gerate, und wenn es passiert, kann ich die Stile für diese spezielle Situation anpassen. Das ist sehr wahr, wenn man an einem Projekt mit 1-2 Front-End-Leuten arbeitet. In meinem Fall arbeite ich an einem Projekt mit ca. 30 Entwicklern, und alle könnten zu CSS beitragen, daher ist es für uns sehr wichtig, diese Konventionen zu haben. Aber wenn ich das Projekt verlasse und selbstständig arbeite, werde ich GRM weiterhin verwenden.
@everything, Entschuldigung für die Verwirrung, ich schätze, es ist üblich,
--für Modifikatoren und__für Elementtrenner zu verwenden, und in den Beispielen habe ich sie vertauscht :)Und der Grund für die doppelte Deklaration ist, dass die Stile nur auf Elemente angewendet werden sollen, die
.moduleentsprechen + Elemente, auf die ein Modifikator[class*=module__]angewendet wird, werden auf.module__books, .module__whatever, ...angewendet.Ah, verstehe, ergibt Sinn. Scheint, als ob ich mein Framework neu schreiben muss.
Ich arbeite hauptsächlich an kleinen bis mittelgroßen Projekten (2 Entwickler) und bin mit der BEM-Methode vertraut. Mein CSS basiert lose darauf, aber ich habe es nie geschafft,
__und--zu verwenden. Nur der einzelne Bindestrich funktioniert für mich.Danke, Sergey.
Warum nicht eine ID anstelle einer Klasse für den Body-Stil verwenden?
IDs sind böse. Genug gesagt.
IDs sind zu spezifisch und schwer (zu) überschreiben. Klassen machen genau dasselbe.
Ich habe IDs in meinem CSS komplett fallen gelassen.
Ich benutze sie immer noch als Anker in HTML und für jQuery.
Wenn ich sie für Stile verwenden muss (z. B. zum Stylen von WP-Plugins oder dem Code anderer Leute), ziele ich auf sie mit dem Attributselektor [id=”name”] ab, sodass sie die gleiche Spezifität wie eine Klasse haben.
„Genug gesagt“ ist böse.
@Ralfff Kluge Methode, um eine Spezifitäts-Albtraum mit WP-Plugins zu vermeiden, indem der Attributselektor verwendet wird. Danke fürs Teilen!
Ha, kein Problem. Aber um ehrlich zu sein, bin ich nicht so schlau, Harry Roberts ist
http://csswizardry.com/2014/07/hacks-for-dealing-with-specificity/
Zusätzliche Klasse! Mache ich schon seit einiger Zeit so.
…und lol @ shame.css haha
Ich würde Klassen verdoppeln. In Chris' Beispiel ist das Modul identisch, abgesehen davon, dass es einen zusätzlichen unteren Rand hat. Es ist wirklich eine Erweiterung des Modulobjekts, daher ist dies meiner Meinung nach der richtige Weg.
** … **
Zum dritten Mal Glück... Ich wähle die Klasse Alpha, um den Klassennamen nicht an den Inhalt zu binden. Wir wissen nie, ob er in Zukunft für etwas völlig anderes wiederverwendet werden könnte.
Doppelklasse, mit ein paar Namenskonventionen. Der Artikel von Smashing Mag letztes Jahr über die Neugestaltung der London Times hat mich dazu angeregt, meinen Ansatz und meine Namenskonventionen zu beschreiben.
Meistens mit einer erweiternden Klasse im BEM-Stil
Manchmal über die Body- oder HTML-Element-Klasse, z. B. bei der Verwendung von WordPress, werden die Body-Klassen automatisch für eine bestimmte Seite eingefügt und wenn ich zu faul bin, zusätzliche Parameter zu meinem serverseitigen Code hinzuzufügen.
Beim Hinzufügen zu Body oder HTML-Element erstelle ich einen Mixin, um Änderungen einfacher und weniger fehleranfällig zu machen.
Mixins bringen den Nachteil zusätzlicher Bytes mit sich (was natürlich nicht kritisch sein kann). Was halten Sie von meiner Lösung: https://css-tricks.de/design-pattern-breaks/#comment-1584654?
Das hängt vom Zweck des Moduls ab. Wenn das Modul etwas wirklich in sich geschlossenes ist, das auf vielen Seiten und in vielen Kontexten verwendet werden kann, dann sollte es wahrscheinlich überhaupt keine Layout-Regeln enthalten. Layout-Regeln wären Dinge wie Float, Breite, Rand.
Ich würde diese portablen Module in allgemeinere Layout-Module verschachteln, die für die Positionierung zwischen Modulen verwendet würden. Der HTML sieht hässlicher aus und kann an Div-itis grenzen, aber der CSS ist ziemlich sauber und portabel.
Glückwunsch, dass Sie die erste Person sind, die Sinn ergibt :) Ich füge nur das Beispiel hinzu
Aktuell versuche ich, doppelte Klassen zu verwenden, ohne Teile des Namens zu wiederholen.. So etwas wie
Somit muss ich von vornherein spezifischer sein.
Es ist weit davon entfernt, perfekt zu sein, aber ich mag die Lesbarkeit...
Ich würde die Klassen verdoppeln, aber sicherstellen, dass diese Klassen modular sind. Ich würde dafür OOCSS verwenden und eine Klasse wie .mbm (margin-bottom: $medium) hinzufügen.
Ich denke oft darüber nach. Jetzt verwende ich die BEM-"Methode" mit class=”module–solitary” und dann in der .less-Datei
Vito
Am häufigsten verwende ich
body.contact .aside_module. Aber ich bin wirklich nicht abgeneigt, Inline-Stile oder sogar "Blöcke" zu verwenden, da es normalerweise nicht genug Bytes gibt, um meine Seite zu belasten, und definitiv nicht genug, um eine zusätzliche Anfrage zu rechtfertigen. Ich mag es immer, meine Stylesheets so universell wie möglich zu gestalten, daher ermöglichen Inline-Stile auch, dass meine Stylesheets sauber bleiben.Ich versuche,
[data-*]nur für Javascript zu verwenden.Ich lese jetzt den Shame.css-Artikel. Klingt, als könnte das eine gute Option sein.
Ich entscheide mich für eine zusätzliche Klasse und @extend in Sass. Fühlt sich richtig, einfach und leicht zu aktualisieren/entfernen an.
Ich versuche normalerweise, Klassen zu verdoppeln, es sei denn, es ist eine einmalige Sache, in diesem Fall mache ich entweder einen schnellen Inline-Stil oder etwas etwas Schändlicheres, wie Sie oben gezeigt haben. Ich stoße in meiner Arbeit auf viele Fälle, in denen Ränder angepasst werden müssen, daher habe ich auch einige generische Randstile. Normalerweise habe ich so etwas zur Verfügung
Wobei m für "margin", "p" für "padding", "t" für "top" usw. steht.
.mt10 { margin-top:10px !important; } .m10 { margin:10px !important; }
Das !important ist nur da, weil ich an viel Code von anderen Leuten arbeite, bei dem die Vererbung normalerweise nicht sofort bekannt ist. Daher können diese schnellen Fix-Klassen viel Zeit bei Abstandsproblemen sparen.
Ich neige dazu, Klassen zu verdoppeln
.module.module-books. Aber in letzter Zeit sieht mein Markup etwas unordentlich aus, ich brauche manchmal etwa 7 Klassen, was mir nicht so gefällt. Das ist aber hauptsächlich bei.grid-Elementen der Fall. Ich schätze, das Modul könnte auch ein.gridsein...Meistens benutze ich die "doppelten" Klassen. Wenn nur eine häufig verwendete Eigenschaft benötigt wird (wie ein unterer Rand), erstelle ich normalerweise eine Hilfsklasse
.md(für margin down) dafür und füge sie zum HTML hinzu. Wenn es sich um eine tatsächliche Variation handelt, gehe ich zu.module-variation.Ich benutze manchmal Body-Klassen, aber meistens nur für Javascript..
Ich verwende normalerweise eine Modifikator-Klasse. Habe noch nie Inline-Styles verwendet!
Das hängt davon ab, wenn ich nur einen unteren Rand hinzufügen muss, habe ich normalerweise eine Reihe von Hilfsklassen wie .margin-bottom, .margin-bottom2x, .margin-top usw.
Dann füge ich einfach die Modifikator-Klasse hinzu.
Füge eine zusätzliche Klasse hinzu! Früher hätte ich vielleicht eine Modulerweiterung gemacht, aber in letzter Zeit liebe ich die Inuit-Style-Helfer. Anstatt also
.module-bookshinzuzufügen, habe ich Dinge wie.push--bottomhinzugefügt (ich benutze Inuit 5; https://github.com/csswizardry/inuit.css/blob/master/generic/_helper.scss)Der Schlüssel hier für diese neue Situation™ ist, dass der zusätzliche untere Rand wahrscheinlich ein Designmuster sein wird, das wieder vorkommt. Diese Art von Abstraktion, obwohl fast zu einfach, war für mich sehr hilfreich.
Ich stimme für einen neuen Stil! Und wenn Sie SASS verwenden, importieren Sie die Eigenschaften des Basisstils.
Die Doppelklasse ist schön für die Organisation, aber ich bleibe bei meiner ersten Zeile.
Ich würde so etwas tun. Wenn es nur eine Änderung der Farbe, Polsterung usw. ist.
Ich versuche, die Block-Element-Modifikator-Methodik zu verwenden. In diesem Fall hätte ich wahrscheinlich die Basis
.module-Klasse und dann für den zusätzlichen Rand würde ich etwas wie.module--dbl(oder etwas Ähnliches, je nachdem, wie viel mehr Rand und ob es Rand ringsum oder nur an einer bestimmten Seite (oben, links, unten, rechts) ist) tun.Sie könnten das Modul immer semantisch benennen
„
Dann in scss
.user-biography { @extend %module; padding-bottom: $bigPadding; }Hallo Chris, toller Beitrag!
Was ich normalerweise mache, ist das Verdoppeln von Klassen, ich nenne sie persönlich "Modifikatoren". Ich denke, es bleibt auf diese Weise sehr gut wartbar und es funktioniert gut mit Twitter Bootstrap.
Allerdings mag ich die Datenattribut-Varianten, sie sind ziemlich raffiniert. Es ist so gut wie der AMCSS-Stil von GitHub: http://amcss.github.io/
Hat jemand diesen Stil schon mal ausprobiert?