Sinn eines CSS-Frameworks

Ich habe vor Kurzem meinen aktuellen Arbeitsworkflow beschrieben. Dabei habe ich auch erwähnt, daß ich mich in der Frontendentwicklung auf zwei Frameworks verlasse: YAML für HTML und CSS sowie jQuery für Javascript. Da meine Arbeit sich auf die Erstellung von Frontendcode konzentriert und ich weder ein CMS direkt befeuere noch die Templates erstelle, muss ich mir keine Gedanken über ein CMS oder ein PHP-Framework machen.

Seit Jahren werbe ich immer wieder für die Nutzung von YAML. Nicht, weil ich dafür Geld bekäm, sondern weil ich die Nutzung eines Frameworks für sinnvoll erachte und YAML für das Beste der derzeit existierenden halte. YAML wird dabei immer wieder vorgeworfen, es sei so „schwer“ und habe einen zu komplexen Code. Abwechselnd wird von DIVitis oder DIV-Wahnsinn gesprochen. Ihre dauernde Wiederholung macht allerdings diese Behauptungen nicht wahrer. Die Kritiken zeugen in meinen Augen davon, daß das Konzept von YAML nicht verstanden wurde.

YAML bietet von Anfang an erst einmal alles. Der Trick besteht darin, das Unnötige wegzunehmen. So gehe ich auch in meinem Entwicklungsframework vor. Ich kann gut verstehen, daß das gewöhnungsbedürftig ist. Die Alternative wäre, eine ganz grobe Vorlage zu haben, in die man dann die benötigten Einzelteile einfügt. Das liefert mir prinzipiell jeder gute Editor, dafür brauche ich kein Framework. Zudem benötige ich einen Ort und eine Ordnungsmethode, um meine hinzuzufügednen Einzelteile zu finden und dann in meine neu entstehende Webseite einzufügen. Auch in diesem Falle benötige ich eine Art Framework-Grundlage. Ich bevorzuge, alle wichtigen Dateien und Skripte an einem Platz zu haben, so daß ich sie jederzeit anwenden kann, und die unnötigen am Ende schnell zu löschen.

Dirk Jesse schachelt bei YAML alle Layoutcontainer doppelt. Ich denke, es ist dieser Umstand, den viele kritisieren. Doch hinter der Verschachtelung steckt Sinn. Dirk entwickelt YAML immer mit dem Gedanken an flexible Layouts im Hinterkopf. Wenn man dementsprechend einem Container eine Breite in Prozent gibt, kann man ihm schwerlich ein Padding in Pixeln oder em geben. Schachtelt man nun einen Container in den Äußeren, dann gibt der Äußere die Breite vor und der Innere erzeugt über Padding oder Margin Abstände für die dann folgenden Inhalte. Natürlich kann ich auch den inneren Inhalten diese Abstände zuweisen. Doch das bedeutet mehr Schreibarbeit, schlechtere Wartbarkeit und weniger Flexibilität. Über die Verschachtelung ist sichergestellt, daß die Inhalte auf alle Fälle die korrekten Abstände bekommen. Zudem ist es egal, welche Inhalte in den inneren Container geschachtelt werden, sie bekommen immer den richtigen Abstand.

Die meisten Entwickler werden hingegen fixe Layouts mit Pixelbreiten erschaffen. Bei einem fixen Layout wird der innere Container nicht mehr zwangsweise für die Abstände benötigt. In diesem Falle kann man die inneren Container löschen. Das gilt für die Spaltencontainer #col1, #col2 und #col3 genauso wie für die diversen Subcolumns, also die Gridbausteine. Ohne die inneren Container kann man nicht mehr ernsthaft von DIVitits sprechen. Eine Lösung hingegen, in der ich Einheiten für Breiten und Abstände mische, kann ich schwerlich ohne zusätzliche Container lösen. Ich beglückwünsche jeden, der es dennoch geschafft hat. Ich wüßte dann aber auch gerne, ob die Lösung allgemein funktioniert, komplexe Layouts zuläßt und wie lange es gedauert hat, bis man auf sie kam.

Man kann also unter bestimmten Umständen die Struktur straffen. Andere Umstände erfordern hingegen diese verschachtelte Struktur. Denn abseits des Falles eines flexiblen Layouts gibt es genügend Gestaltungsideen, die einen zusätzlichen Container erfordern. Es dürfte schwerlich möglich sein, den Kunden zu erklären, man könne jetzt bedauerlicherweise sein Wunschlayout nicht erstellen, weil man dafür einen semantisch unnötigen Container einfügen müsse.

Ich denke, die Struktur können wir als nicht zu sehr aufgeblasen abhaken. Wie steht es nun mit dem CSS? YAML benötigt zwei Dateien, um zu funktionieren. Jede weitere Datei gehört zum individuellen Layout. Die slim_base.css hat 2,34 KB und hält damit für ziemlich viele Problemfälle Lösungen parat. Wer will, kann sich die Datei noch um die wenigen Einträge kürzen, die er definitv nicht benötigt wird. Man sollte dabei aber wissen was man tut. Angesichts der geringen Dateigröße halte ich eine solche händische Straffung allerdings für albern. Alle IE bis einschließlich Version 7 müssen 5 KB CSS-Dateien laden, da für sie ein separates Patchfile hinzukommt. (Siehe Dirks Artikel über YAML 3.2.)

Ich kann beim besten Willen an diesen Werten nichts Schlimmes entdecken. Die genannten Dateien sind eine Sammlung von Best Practices, an denen man schwerlich vorbeikommen wird. Es ist natürlich etwas Anderes, wenn man solche CSS-Dateien selber zusammensucht. Doch wird dies kaum über einen kurzen Zeitraum geschehen. Man wird seine selbst zusammengestellten Best Practices also nicht zwangsweise besser kennen, als man die YAML-Dateien kennen kann, wenn man sich einmal mit ihnen beschäftigt hat. In meinen Augen unterscheidet sich YAML von den anderen Frameworks dadurch, daß es auf Anwender setzt, die sich mit dem Code auseinandersetzen wollen und können. Es ist nicht einfach nur zum Anwenden da, wie die diversen Grid-Frameworks. YAML will erkundet, erforscht, erobert werden.

Wer sich also mit dem System beschäftigt, wird schnell die Vorteile erkennen. Ich habe mein gesamtes bisheriges Berufsleben meinen eigenen Code geschrieben. Bei meinem letzten Großprojekt für SinnerSchrader habe ich sogar ein eigenes kleines CSS-Framework geschrieben, das uns die Arbeit sehr erleichterte. Dieses war allerdings auf den Nutzungskontext zugeschnitten. Ich genieße es derzeit, daß mir YAML alle Gedanken um das Grundlayout abnimmt und ich mich um die eigentlichen Problemfälle der Entwürfe kümmern kann, von denen es noch genügend gibt.

Die Nutzung eines Frameworks hat für mich im wesentlichen folgende Vorteile:

  • Ich kann mich auf Designdetails konzentrieren, weil die groben Probleme browserübergreifend schon gelöst sind.
  • Für alle grundlegenden Seitenelemente gibt es eine festgelegte Notation, sodaß ich mir persönlich weder eine eigene ausdenken muss, noch die Gefahr habe, in ein paar Jahren meinen Code nicht mehr spontan zu verstehen.
  • Durch die einheitliche Notation können Fremde meinen Code leichter verstehen und meine Arbeit übernehmen.
  • Dadurch wird auch die Arbeit im Team stark erleichtert.
  • YAML kommt mit einer ausführlichen Dokumentation. Jedes meiner Projekte hat nun also eine Basis-Dokumentation.
  • Über allem steht in meinen Augen die Effizienz. Mit einem Framework erstellter Code ist effizient, denn viele Gedanken und Fehlersuchen erübrigen sich. Die Ersparnis ist nicht nur Zeit, sondern bares Geld.

Die Sorge um unnötige DIV-Container finde ich zudem übertrieben. Ich habe eher den Eindruck, es ist ein vorgeschobenes Argument. Und es wird schwer, solche unnötigen Container immer und überall zu identifizieren. Semantisch sind sicherlich sehr viele DIV-Container sinnlos. Sie machen semantisch da Sinn, wo sie eine Webseite in Bereiche unterteilen. Doch leider ist die Frontendentwicklung kein idealer Ort und wir können Layouts nicht der reinen Lehre nach nur mit CSS-Mitteln bewerkstelligen. Wir benötigen immer wieder zusätzliche DIV-Container, um Layouts zu erreichen. Das kann man kritisieren, outet sich dann aber in meinen Augen als Förderer schlichter Textwüsten.

Viele Seiten sind zudem keine simplen Bloglayouts oder einfache Seiten, die von einer Person für eine andere erstellt werden. Große Seiten werden von einem Redaktionsteam betreut, bekommen Daten von aussen angeliefert, bekommen oft Werbung von aussen eingebunden und sollen vielleicht sogar ein flexibel anpassbares Design haben. Wer all dies bewerkstelligen muss, der ist über das eine oder andere zusätzliche DIV sehr froh, das ihm die Arbeit sehr erleichtert. Die zusätzlichen 11 Byte tun weder dem Entwickler, noch dem Nutzer weh.

In Deutschland haben immer mehr Auftraggeber den zeit- und geldsparenden Effekt von Frameworks begriffen und fragen konkret nach einer Umsetzung mit YAML nach. Das hat für sie den großen Vorteil, daß sie den Frontendcode von anderen Entwicklern einfacher warten lassen können, wenn sie es aus welchen Gründen auch immer wollen. Ich sehe derzeit keine Veranlassung, wieder zu meinen alten Methoden zurückzukehren und meinen Code komplett selber zu schreiben.

17 Responses to “Sinn eines CSS-Frameworks”

  1. Micha sagt:

    Wo muß ich unterschreiben?

  2. +1, wie man so schön sagt.

  3. Wenn sich dieser Artikel auf PHP-Frameworks beziehen würde, würde ich hier mein Siegel mit Stempel draufdrücken. Denn wozu sollte man das Rad immer wieder und wieder neu erfinden, wenn es doch draußen Frameworks gibt, die einem die Arbeit abnehmen und ihrerseits schon so viele Features nutzen, die dazu auch noch abgesichert sind. Auch wenn ich bei manch kleinem Projekt kein ganzes PHP-Framework einsetze, so nutze ich zumindest immer Bestandteile dieses Frameworks (Handling von Mails, Templatesystem, Rechte usw.).
    Deshalb nutzt ich symfony, ZendFramework, jQuery, Twitter- und Facebook-API und noch vieles mehr.

    Doch bei HTML und CSS schreibe ich weiterhin alles selbst, denn das ist mein Job und ich mache das echt gern und verdammt schnell.
    Zweischneidiges Schwert, ich weiß. Aber mein Workflow passt einfach.

    • Jens Grochtdreis sagt:

      HI David. Ich sehe keinen gravierenden Unterschied zwischen diesen Framework-Arten. Alle Frameworks erledigen für mich Aufgaben, lösen Probleme. Für mich bleiben trotz YAML noch genügend zu lösende Probleme übrig. Das ist der Unterschied zu PHP- oder Javascript-Frameworks, bei denen viele Sachen schon vorgelöst sind. Aber wenn Du lieber ein bischen mehr Zeit beim CSS-Tätscheln verbringen möchtest, gönne ich Dir das von Herzen 🙂

  4. Es gibt absolut keinen Unterschied beim Einsatz eines Frameworks. Sei es im Frontend (HTML, CSS) oder eben serverseitig (PHP, Datenbankabstraktion usw). Von daher wird dein Tipp für die meisten einfach richtig sein und perfekt funktionieren.

    Im Frontend setze ich aber anderen Prioritäten. Entweder unterstütze ich andere Browser nicht oder ich lege keinen Wert darauf, dass eine Webseite überall pixelgenau funktioniert. Der Aspekt, dass mir eine CSS-Framework erheblich Arbeit abnehmen würde, stellt sich bei mir (und vielleicht nur bei mir) nicht. Denn die drei Zeilen hier oder dort, um ein floating zu erzeugen, schreibe ich in meiner Zehn-Finger-Methode schnell runter.

    Wie gesagt, das sehe ich bei PHP-Frameworks ganz anders.

  5. Chris sagt:

    Hey Jens.

    Danke für den ausführlichen und anschaulichen Artikel. In vielen aufgelisteten Argumenten gebe ich dir sogar vollkommen recht.

    Allerdings muss ich auch ein paar Passagen im Artikel nochmal aufwirbeln..wenn ich mir deine Seite hier anschaue, dann ist die basemod.css ganze 28KB (nicht komprimiert) groß..Das ist ein bisschen mehr wie du im Artikel erwähnst. 🙂

    Desweiteren mag ein CSS-Framework sehr hilfreich sein und für große Projekte sogar sehr gut zum Einsatz kommen, da es viele Bedürfnisse abdeckt. Aber für kleinere Seiten mit meist gleichbleibenden Aussehen..also ich müsste da soviel ausmissten, dass ich mir schon überlegen würde ob ich nicht von 0 anfange und es selbst schreibe.

    Desweiteren bist du dennoch an etwas gebunden und an Klassen, ID’s und vllt sogar Selektoren muss man sich erst gewöhnen. Oder sie umschreiben..das kostet auch viel Zeit meiner Meinung nach und nicht jeder findet colxyz und header -> header_inner -> header_inner_inner -> colxy gerade übersichtlich.

    Auch einen Punkt den ich noch gerne anführen würde ist, dass du folgendes erwähnst:

    Wenn man dementsprechend einem Container eine Breite in Prozent gibt, kann man ihm schwerlich ein Padding in Pixeln oder em geben.

    Allerdings…je nach Gebrauch ist es möglich Containern mit %tualen Breitenwerten ein padding und / oder margin zu geben.

    Jetzt hab ich irgendwie den Faden verloren..doofes telefon.. *grmml*

    Grüßli
    Chris

    • Jens Grochtdreis sagt:

      @Chris: Lies den Artikel bitte nochmal. Du wirst feststellen, daß ich von der base.css sprach, die schmal ist. Die basemod.css ist mein eigenes Layout. Die wird groß, egal ob mit oder ohne Framework. Ich habe sie bewußt nicht komprimiert, weil ich sie auch als Anschauungsobjekt hernehme.

      Egal ob Dein Projekt groß oder klein ist, es hat entweder ein Spalten- oder ein Grid-Layout. Was willst Du da also ausmisten? Klar, Du mußt die zusätzlichen Klassen für Formulare nicht nutzen. Aber der Kern ist sinnvoll für kleine und große Projekte.

      Wenn Du es nicht schafftst, Dich an #col1 oder andere Notationen zu gewöhnen, wie hast Du dann irgendeine Programmiersprache gelernt? Man kann sich die Argumente auch künstlich konstruieren. Und wenn Du es allzu schlimm findest, dann kauf Dir eine Lizenz, nimm „Suchen & Ersetzen“ und mach aus #col1 #spalte1 oder #schnuffelchen. Natürlich muss man sich an die Notation von YAML gewöhnen,. Wir sprechen hier aber nicht davon, einen chinesischen Dialekt zu lernen, sondern von vielleicht ein bis zwei Dutzend Klassen und IDs. Diese sind zudem logisch benannt. Wenn Du das Subcolumns-Konzept begriffen hast weisst Du sofort, was .c33l ist und kannst Dir Dein eigenes .c20r bauen.

      Und abschließend: wenn ich ein Layout mit einem 75% und einem 25% breiten Container aufbaue, dann zeige mir mal bitte, wie ich diesen beiden Containern jeweils noch ein Padding zuweisen kann, ohne daß ich das Layout zerstöre. Um diesen Punkt geht es. Und so sind die YAML-Layouts gedacht.

  6. Ingo Chao sagt:

    Sein vermeintliches Zuviel an Semantik schert mich nicht beim Div; beklagenswert ist dagegen oft das semantische Zuwenig seines Inhalts.

    • Jens Grochtdreis sagt:

      Hallo Ingo. Da hast Du sowas von Recht. Darum sollte ich mich in einem meiner nächsten Artikel kümmern.

  7. Chris sagt:

    Hallöchen Jens.

    In der Tat, du hast recht, da hab ich das wohl überlesen. 😉 Dennoch Frage ich mich, wie du auf so eine große CSS-Datei kommst 🙂 (nicht ernst nehmen)

    Ich verstehe deine Argumentation voll. Aber ich denke meist immer etwas in „Zukunft“. Im Laufe der Zeit habe ich meine Klassen und ID’s immer anders benannt und „optimiert“. Allerdings bin ich momentan an diesem Standpunkt angekommen, an dem ich meine Klassen/IDs irgendwie schon nach „HTML5-Standard“ benenne (article, aside, section, ..) da ich mir anscheinend erhoffe, dass wenn mal wirklich ein HTML-Grundgerüst so lange lebt bis HTML5 wirklich Standard ist..ich nicht viel zu ändern habe…

    Mit „ausmissten“ Meinte ich, den überflüssigen xHTML-Code und das CSS wieder rauszulöschen. Kommt eben drauf an, wieviel man benötigt von dem Ganzen und ob es i.O. ist, wenn man überflüssiges CSS mit einbindet.

    Sicherlich ist das nicht möglich wenn man 75% und 25%-Spalten hat, dass man denen noch etwas zuordnet.

    75% + x + 25% + x > 100%. Das ist logisch. Dann müsste man statt 75% eben 70% + 1em padding nehmen.

    Wie gesagt, ich spricht einiges dafür, ein CSS-Framework zu verwenden.

    Grüßli
    Chris

  8. Nils Pooker sagt:

    Zu den Grundsatzdiskussionen über den Sinn und Zweck von CSS-Frameworks: Von Dirk Jesse und mir gibt es auch einen ausführlichen Beitrag: Was Sie über CSS-Frameworks wissen sollten!

  9. Bert Kößler sagt:

    Ich halte es da wie David. Ein neues Layout zu durchdenken und mir zu überlegen, wie ich das am besten umsetze – mit der kleinsten Menge überflüssiger divs natürlich – ist für mich immer der Schokoladenmoment bei jedem Projekt. Zudem schafft man das Minimum an Code wirklich nur auf dem manuellen Weg.

    Trotzdem finde ich es großartig, dass es YAML gibt (und wenn ich je ein CSS-Framework nutzen müsste, würde ich dieses nehmen). Letztlich nimmt es doch auch den letzten Verfechtern der Tabellenlayouts den Wind aus den Segeln. Wer mit CSS und vor allem mit Floats so ein wenig auf Kriegsfuß steht, für den ist YAML sicher die richtige Wahl.

    Die div-Diskussion halte ich für ziemlichen Quatsch. Was man braucht, braucht man eben. Dass man mit möglichst wenig auskommen sollte, versteht sich von selbst. Ich persönlich fahre aber sehr auf semantische ID- und Klassenbezeichnungen ab, und da gehört col_1 eher nicht dazu. Aber manchmal geht es auch nicht anders und im Falle von YAML macht es durchaus Sinn.

    Dennoch ein schöner Artikel, der indirekt für das richtige Framework wirbt.

    P.S.: Übrigens, Jens, du hast entweder Post oder einen paranoiden Spamfilter. 😉

  10. Markus Wolf sagt:

    YAML ist erst der Anfang, denn der Bedarf an vereinheitlichter und standardisierter Frontendentwicklung ist groß, was nicht zuletzt der Erfolg von YAML zeigt. Ob nur aber dieses CSS Framework auch in Zukunft die beste Lösung ist, da bin ich eher skeptisch – für den Moment, aber noch das Beste… Muss aber jeder für sich entscheiden 😉

  11. Markus sagt:

    Ich denke der Streit um YAML entfacht sich immer wieder an der Vollständigkeit des Frameworks. YAML hat den Anspruch ein Framework für eine möglichst große Klasse von Layouts zu sein. Dazu zählen Frameworks mit beliebige Layouts mit diversen Spalten, Headern und Boxen, flexible größen, Screen/Print-Sheets und vieles mehr. Aus diesem Anspruch ergibt sich dann auch eine gewisse Komplexität.

    „YAML Gegner“ verstehen diesen Anspruch oft nicht und fragen sich (aus ihrer Sicht zurecht): Wozu braucht man denn so ein komplexes Framework, wenn man doch nur ein fixes Layout mit drei Spalten und einem Header will.

    Ich persönliche zähle mich zu diesen „YAML Gegnern“ und greife lieber zu 960.gs. Die Möglichkeiten sind begrenzt. Aber ich sehe dies eher als Vorteil. Viele Design-Entscheidungen sind mir quasi abgenommen und ich kann mich auf den Inhalt konzentrieren. Dennoch habe ich genug Flexibilität, um eigenständige Designs zu gestalten.

    • Jens Grochtdreis sagt:

      @Markus: Ich tendiere zu YAML, Du zu 960.gs. Beides ist vollkommen okay, denn beide Wege erleichtern uns die Arbeit und halten immer wiederkehrende Probleme von uns fern. Wenn Du mit 960.gs besser zurecht kommst, ist das klasse. Der Code ist aufgeblähter (http://www.highresolution.info/weblog/entry/yaml_3.2_schaerfung_des_profils/), weniger flexibel, aber für bestimmte Einsatzbereiche einfach besser geeignet, als YAML, weil 960.gs genau für eine bestimmte Art Grid-Layouts erschaffen wurde. Mein Punkt ist weniger „nehmt alle YAML“ sondern „erleichtert Euch die Arbeit und nutzt ein Framework“.

  12. nikosch sagt:

    Um den Ansatz „Frontend code ich selbst“ zu fahren, muss der Entwickler sehr viel Erfahrung und Selbstvertrauen besitzen, und, vor allem seine Kunden einschätzen können! Sonst heißt es schnell: „Für diese Kampagne wollen wir die Seite vorübergehend in Spaltensatz ändern, hier und dort Werbung schalten“ etc. Wenn es dann zeitlich vielleicht auch wiedermal höchste Eisenbahn ist, kommt man hier schnell ins Rudern.
    Somit würde ich schon fast dazu tendieren, Yaml nicht vollständig auszumisten, um einen Teil der gegebenen Fexibilität zu erhalten. Es kann manchmal ein Bild sein, das nicht im Absatzmargin, sondern bis an den Rand gesetzt sein soll und schon steht Entwickler für IE und Konsorten schon vor fast unmöglichen oder deutlich häßlichen Lösungen.

  13. Wolfgang Schulz sagt:

    Frameworks nutzen ist wie mit Convenience Produkten kochen,
    sie erleichtern das kochen, aber es kommt nur Fastfood raus.