Vor Kurzem habe ich erklärt, warum ich denke, dass es kein semantisches CSS gibt. Wir dürfen deshalb nicht aufhören, uns Gedanken über die sinnvolle Semantik einer Webseite zu machen. Das kann leider in kleinliche Diskussionen und Gedankengänge führen. Doch es ist sinnvoll und hilfreich, sich über die Basis einer Webseite Gedanken zu machen. Und diese Basis ist und bleibt natürlich das HTML. CSS und JavaScript können ausgeschaltet oder von einer Firewall blockiert werden. Ohne HTML gibt es keine Webseite.
Deshalb sind Artikel, wie “Semantic CSS With Intelligent Selectors” von Heydon Pickering so wichtig. Heydon hinterfragt ganz bewusst den so extrem gehypten objektorientierten Ansatz. Nicht nur der Artikel, auch die teilweise recht langen Kommentare sind absolut lesenswert. An ihrer Profession wirklich interessierte Frontendentwickler sollten sich die notwendige Zeit dafür nehmen.
Ich möchte nicht die diversen objektorientierten Ansätze in Bausch und Bogen verdammen. Sie lenken den Fokus auf wichtige Eigenarten von Frontendcode. Sie gehen in meinen Augen aber einen Schritt zu weit, indem sie helfen, CSS und HTML zu entkoppeln. Ein besonders krasses Beispiel präsentiert hierbei ein passenderweise “Semantic-UI” genannte Projekt. Die diversen Klassen zur Gestaltung von Buttons werden in einem Beispiel auf DIV-Container angewendet.
Mein Eindruck ist, dass solche Beispiele nicht von echten Frontendentwicklern kommen können. Und ebenso ist es für mich sehr wahrscheinlich, dass der Ansatz der Entkoppelung von CSS und HTML für Backendentwickler geschaffen worden ist. Die dafür bekannten Systeme OOCSS, SMACSS und BEM entstammen schliesslich sehr grossen Firmen mit sehr komplexen Projekten. Es ist sehr wahrscheinlich, dass dort selbst die Frontendentwickler eigentlich umgeschulte Backendentwickler sind. Deren Interesse an und Verständnis für Semantik dürfte sich in sehr engen Grenzen halten.
Es ist deshalb viel einfacher, ein paar Klassen an Zielobjekte zu verteilen, als sich Gedanken über die Art dieser Zielobjekte zu machen. Das ist legitim, aber nicht wirklich gut und professionell. Deshalb plädiere ich ja schon immer dafür, dass Backend-Entwickler zwar mit Frontendcode beschäftigen sollten (wie umgekehrt auch), sie ihn aber nicht unbedingt schreiben sollten.
Gegen eine Verlagerung der meisten Gestaltungsregeln auf Klassen ist prinzipiell nichts zu sagen. Es sollte aber nicht dazu führen, dass die Semantik einer Webseite unwichtig wird. Wir würden so alles negieren, was wir seit der Ablösung der Layouttabellen durch semantisches HTML gelernt und praktiziert haben. Wir wären wieder in einer “Malen nach Zahlen”-Phase, diesmal nicht mit WSYSIWYG-Editoren oder aus Phtosohop exportiertem HTML. Aber genauso sinnlos.
23. August 2013 um 13:39 Uhr
In wesentlichen Teilen gehe ich mit deinen Auffassungen d’accord. Aber die Ablehnung der Konzepte von dem, was unglücklicher Weise „objektorientiertes CSS“ genannt wird, rundheraus ist meiner Ansicht nach nicht vorteilhaft. Insbesondere, weil du mit YAML gar nicht so weit von diesen Ansätzen entfernt bist.
SMACSS wurde von Jonathan Snook (ex-Yahoo!) geschrieben, einem durch und durch Frontend-orientierten Entwickler. OOCSS von Nicole Sullivan, die Firmen (z. B. Facebook) zu Frontend-Fragen berät. Populär unterstützt übrigens von Harry Roberts (bekannt als @csswizardry), der mit inuit.css ein fantastisches CSS-Framework vorgelegt hat. BEM stammt direkt von den Frontend-Entwicklern von Yandex, ihre Backend-Leute waren nicht beteiligt.
Wie du richtig siehst, sind das alles große Firmen, die irgendwo hinter den Namen auftauchen. Die, die sich das ausgedacht haben, sind aber alles durch und durch Frontend-Leute. Sie haben die Systematiken entwickelt, damit sie nicht im Chaos tausender, modular aufgebauter Seiten (man denke an Yahoo!) den Überblick verlieren, isb. wenn Widgets des einen Subsystems auf anderen Seiten auftauchen. Die Systeme sind alle auf hoch-skalierenden Webseiten geboren worden. Deshalb hat z. B. BEM auf Ömchens kleiner, statischer HTML-Seite wenig Sinn.
Andererseits wiederum sind sie dort Best Practices, die sich „im Kampf“ bewährt haben. Das trifft z. B. auch auf das Minimieren von CSS und JS vor dem Deployment zu. Auch das wäre auf Ömchens Seite nicht wirklich notwendig.
Ich habe mittlerweile einige Konzepte (z. B. viele Klassen statt IDs und Elementnamen) zunehmend eingesetzt und beste Erfahrungen damit gemacht. Insbesondere was Wiederverwertbarkeit einzelner Elemente betrifft, kann ich nun viel mehr CSS (und auch HTML) zwischen Kundenprojekten wiederverwenden, ohne dass mir andere Stile dazwischenfunken, die ich erst weg-deklarieren muss.
23. August 2013 um 14:54 Uhr
@Manuel: Wenn Du den Eindrcuk hast, dass ich objektorientiertes CSS in Bausch und Bogen verdamme, dann habe ich das falsch kommuniziert. Zumindest in einem der letzten Artikel sollte klar geworden sein, dass ich den grundsätzlichen Ansatz gut finde.
Ich finde, dass alle Ansätze zu weit gehen. Möglich, dass sie von Frontendentwicklern erschaffen wurden. Aber deren Zielgruppe waren sicherlich eher Backendentwickler oder gemischte Teams aus Backend- und Frontendentwicklern. Und da ist es einfacher, Du vergibst nur Klassen.
Wenn man sich aber so stark auf die Zuweisung von Klassen konzentriert, geht der Fokus vom HTML weg. Das ist meine Befürchtung. Und wenn ich Beispiele für Buttons mit DIVs sehe, dann werden meine schlimmsten Befürchtungen wahr.
Mehr wollte ich nicht ausdrücken 🙂
23. August 2013 um 16:08 Uhr
Tatsächlich hab ich mir das Semantic-UI-Projekt angesehen, als du es getwittert hattest, und wollte gleich einen Bug bzgl.
<div>s als Buttons schreiben, als ich so einen bereits dort vorfand 🙂Andererseits ist es mir oft genug passiert, dass ich eine Überschrift
<h2>in einem Widget gestylt habe, nur um dann an einem anderen Ort ein beinahe identisches Widget mit einem<h3>vorzufinden. In den Fällen spielt OOCSS einfach seine Stärke aus. Oder, um bei Buttons zu bleiben, konsistenter Stil für allea.button, button, input[type="submit"], input[type="button"], input[type="reset"]in einem bestimmten Widget ist durch eine Klasse.widget-buttoneinfacher zwischen großen Teams an Backend- und großen Teams an Frontendentwicklern zu pflegen als das obige Selektor-Ungetüm. Dabei kann „groß“ durchaus auch heißen „drei Entwickler und ihre zukünftigen Selbste in einem halben Jahr“.Unsemantisches HTML kann man mit und ohne OOCSS schreiben. Ich denke, in manchen Fällen hilft OOCSS auch, weil die darunterliegenden Elemente wenig Einfluss auf den Stil haben, und dadurch Refactoring von schlechtem HTML in etwas sinnvolles leichter machbar ist. Ich denke an mein h2/h3-Beispiel. Ich kann dort mittlerweile Überschriften so setzen, dass ich eine sinnvolle page outline zusammenbekomme. Wenn das Widget-Element ein div oder ein section sein kann, kann ich die Widget-Überschrift je nachdem z. B. als h3 oder h1 wählen.