CSS-Frameworks: Fluch oder Segen?

CSS

Heute möchte ich mal ein paar Worte über CSS-Frameworks und ihre Vor- und Nachteile loswerden. Da es inzwischen eine Fülle von diesen gibt möchte ich mich hier auf drei Beispiele beschränken. Es handelt sich um 960.gs, das 1140px CSS Grid und das YAML-Framework. Vom YAML-Framework sollten viele schon mal gehört haben und auch das 960 Grid System ist einigen mit Sicherheit ein Begriff. Wer das 1140px CSS Grid bereits kennt kann ich nicht einschätzen aber dazu später mehr.

Was ist ein CSS-Framework/Grid?

CSS Frameworks bestehen in der Regel aus fertigen CSS-Klassen um Elemente schnell in einem vorgegebenen Raster zu positionieren. Somit sind Designs, die sich an das vom Framework vorgebene Raster halten, schnell und Cross-Browser kompatibel umgesetzt.

Das 960 Grid System

Das 960 Grid System ist mit seinen ~4,6kB bei 12 Spalten ein recht schlankes Framework. Über die Webseite lassen sich verschiedene Spalten und Abstände und weitere Einstellungen vornehmen. Somit kann sich jeder ganz einfach sein für ihn passendes Framework erstellen und runterladen.

Das YAML-Framework

Das Yet Another Multicolumn Layout ist denke ich eines der bekanntesten CSS-Frameworks und wohl auch eines der umfangreichsten. Bei diesem Layout sind viele Elemente bereits fertig formatiert. Neben formatierten Formularen, Überschriften, Listen und ähnlichen HTML-Elementen sind auch bereits Vorlagen für Navigationen vorhanden. Somit hat man mit diesem Framework eine mehr oder weniger bereits fertige Umsetzung die man dann an seine Bedürfnisse anpassen kann. Allerdings ist dieses Framework mit ~230kB Gesamtgröße auch nicht grade schlank ist.

Das 1140px CSS Grid

Das 1140px CSS Grid ist ein CSS-Framework mit 12 Spalten und auf eine Auflösung mit 1280px Breite ausgelegt. Der große Vorteil ist, dass es sich der Auslösung anpasst. Somit sind Webseiten von 1140px bis hin zu einer Breite für mobile Endgeräte skalierbar. Meiner Meinung nach eine gute Möglichkeit, um sich ein getrenntes Layout für Smartphones und Co. zu ersparen. Außerdem ist das Framework mit ~4kB schön schlank.

Vorteile eines CSS-Frameworks

Egal für welches Framework man sich entscheidet, ein Vorteil ist in jedem Fall die Möglichkeit Layouts schneller umsetzen zu können. Außerdem sind die meisten Frameworks in allen gängigen Browsern lauffähig. Damit spart man sich auch in Sachen Browseranpassungen einiges an Zeit.

Nachteile eines CSS-Frameworks

Im Gegenzug muss man sich aber auch die Nachteile bewusst machen. So benötigen CSS-Frameworks häufig weitere HTML-Elemente die bei einem Verzicht auf so ein Framework nicht unbedingt nötig wären. So wird das zu erstellende Markup schnell unnötig aufgebläht.

Ein für mich aber viel größerer Nachteil ist die Einschränkung bei späteren Anpassungen oder einem Redesign. Bei Anpassungen ist man immer häufiger gezwungen auch in das erstellte Markup einzugreifen und ein Redesign alleine durch Änderungen an den CSS-Dateien durchzuführen wird so ziemlich unmöglich.

Mein Fazit

Fluch oder Segen? Meine Meinung ist da inzwischen recht eindeutig. So viele Vorteile eine schnelle Umsetzung auch haben mag, im Endeffekt bringt sie umso mehr Nachteile. Der sinnvolle Einsatz eines Frameworks ist desweiteren nur dann möglich wenn auch das Layout für das vorgegebene Raster ausgelegt ist. Die Grundidee des 1140px CSS Grids ist allerdings ein Ansatz den man durchaus weiter verfolgen sollte. Eine Umsetzung die in allen Auflösungen ein ansehnliches Ergebnis liefert ist ein guter Weg in Richtung Usabilty.

Wie sieht es bei euch aus? Nutzt ihr CSS-Frameworks? Was haltet ihr von dem Einsatz solcher Frameworks?

FacebookRSS Feeds

8 Kommentare zu “CSS-Frameworks: Fluch oder Segen?”

  1. Wolfgang Wagner

    17. Februar 2011 um 23:01

    Ich nutze inzwischen seit langem YAML für jedes meiner Projekte. Und es ist unglaublich, wie schnell damit Layouts umgesetzt werden. Wenn die grafische Vorlage steht, habe ich eigentlich innerhalb 30 Minuten eine funktionierende HTML-Seite, die dann natürlich noch angepasst werden muss.

    Du erwähnst als Nachteil spätere Anpassungen und Redesigns. Ich sehe das eigentlich nicht unbedingt als Nachteil. Durch die strikte Trennung von Inhalt und Gestaltung kann ich bei gleichbleibender HTML-Struktur völlig unterschiedliche Layouts erstellen. Sieh dir mal ein paar mit YAML erstellte Seiten an, da gibt es teilweise recht krasse Unterschiede, bei trotzdem sehr ähnlicher oder gleicher HTML-Struktur.

    Zum Punkt Aufgeblähtheit und überflüssiger Code: das ist richtig, aber nur, wenn man Frameworks falsch einsetzt. Wieder am Beispiel YAML.
    YAML liefert viel Code und viele Klassen. Aber das ganze ist als Ausgangsbasis gedacht und soll und muss angepasst werden. Das heißt, ich kann Elemente, die ich nicht benötige, einfach weglassen. Ich kann Sie aber auch jederzeit wieder hinzufügen, falls ich sie doch irgendwann brauche.

    Ein wichtiger Punkt ist aber, dass man sich in Frameworks erst einarbeiten muss. Ich habe damals, bei meinem ersten Kontakt mit YAML, die Dokumentation mehrmals gelesen, habe mir auch das Buch von Dirk Jesse (dem Entwickler von YAML) gekauft, und es hat einige Zeit gedauert, bis ich im Umgang damit wirklich sicher wahr. Man muss sich halt in fremden Code einarbeiten, der nicht immer so ist, wie man es selber gemacht hätte. Aber diese Arbeit hat sich für mich mehr als gelohnt.

    Ich denke, für den Hobby-Webdesigner, der ab und zu mal eine Seite baut, lohnt sich vielleicht ein Framework nicht unbedingt. Aber für professionelle Webdesigner oder Agenturen, an denen mehrere Personen an einer Website arbeiten, ist ein Framework fast ein Muss. Dabei muss es aber nicht unbedingt YAML oder das 960gs sein. Viele Webworker entwickeln im Laufe der Zeit ihre eigenen Frameworks mit Codes, die halt einfach funktionieren und wieder verwendet werden können.

    Mein Fazit: die Verwendung von YAML hat mir schon einen Haufen Zeit und Ärger (Browser-Bugs) gespart und meinen Kunden dadurch einen Haufen Geld ;)

    Grüße vom Bodensee
    Wolfgang Wagner

  2. Thomas Weise

    18. Februar 2011 um 00:01

    Ich nutze ebenfalls YAML.
    “Früher” nutzte ich YAML, weil damit die verschiedensten Browsermacken abgefangen wurden. Jetzt beachte ich den IE6 zwar nicht mehr, bleibe jedoch trotzdem bei diesem Framework, weil es für meine Projekte einfach eine solide Grundlage bildet.
    Bleibt abzuwarten, ob sich dann YAML auch CSS3/HTML5 annimmt, beziehungsweise ob man in Folge der Bemühungen der Browserhersteller, diese Standards einzuhalten, überhaupt noch darauf angewiesen ist, CSS-Frameworks zu verwenden.

  3. Marcel

    18. Februar 2011 um 08:41

    Hallo Wolfgang,

    danke erstmal für deinen ausführlichen Kommentar. Hier mal ein Versuch meine Bedenken etwas konkreter auszudrücken. :)

    Evtl. hab ich mir YAML bis jetzt nicht intensiv genug angeschaut, aber ein Problem ist mir bei allen mir bekannten Frameworks aufgefallen. Der grundsätzliche Nachteil ist nämlich, dass Klassen und IDs im Markup angeben wie ein Element aussehen soll und nicht was drin steckt. So könnten einzelne Spalten eines dreispaltigen Layouts z.B. die Klasse “col-1-3″ enthalten. Dieses hilft mir bei einem reinen CSS Redesign aber nicht weiter. Entweder ich muss ins Markup eingreifen oder ich kann die Spalten nur einheitlich bearbeiten und selbst wenn mehrere Klassen gesetzt sind ist das Chaos nach einem kompletten CSS Redesign meiner Meinung nach vorprogrammiert. Wenn ich drei Spalten mit den Klassen “sidebarLeft”, “content” und “sidebarRight” habe besteht dieses Problem nicht.

    Ich hoffe das war verständlich genug erklärt.

    Gruß Marcel

  4. Marcel

    18. Februar 2011 um 08:47

    Hallo Thomas,

    auch dir danke für deinen Kommentar. Auf das langsam Schwung in diesen Blog kommt. :)

    Ich habe mich wie bereits erwähnt von den CSS-Frameworks losgesagt und bin inzwischen ganz glücklich mit dieser Entscheidung. Allerdings sehe ich das im Moment auch eher es privater Sicht und denke dabei an meine privaten Projekte die ständig erweitert und verändert werden.

    Bei Kundenprojekten ist dies durchaus etwas anderes wobei es hier eher darauf hinaus läuft das ich kein wirkliches Framework nutze sondern einfach immer wieder auftauchende Dinge wie Standardformatierung für TYPO3 und WordPress, Formulare, Menüs usw. in einem Pool liegen habe und mich aus diesem bei Bedarf bediene.

    Gruß Marcel

  5. Wolfgang Wagner

    18. Februar 2011 um 08:55

    @Marcel:
    Hm, irgendwie kapier ich jetzt das Problem mit den Benennungen der Container nicht. Wie die heissen ist doch eigentlich egal, solange ich weiss, für was ich sie verwende.

  6. Marcel

    18. Februar 2011 um 09:39

    @Wolfgang:
    Das funktioniert erstens nur dann, wenn du an einem Projekt mehr oder weniger alleine arbeitest und zweitens liegt das Problem nicht direkt in dem Namen selbst sondern darin welche Elemente im Markup die gleichen Klassen zugewiesen bekommen.

    Habe ich z.B. den Klassennamen “col-1-3″ für eine 33% Spalte eines dreispaltigen Blocks, so gilt dies für alle anderen 33% Spalten in solchen Blocks auch. Bearbeite ich diese Klasse so werden alle Spalten dieses Typs verändert. Habe ich die Klassennamen “sidebarLeft” und “sidebarRight” kann ich die beiden Spalten komplett getrennt bearbeiten und kann sie im Frontend auch ohne weiteres in einer anderen Reihenfolge darstellen etc. und das alles ohne in das Markup eingreifen zu müssen.

    Da freuen sich in gewisser Weise evtl. die Suchmaschine und es erspart auch einiges an Arbeit. Grade bei komplexeren WordPress Themes oder bei TYPO3 und dem Einsatz von TemplaVoilà etc.

  7. Wolfgang Wagner

    18. Februar 2011 um 22:06

    Ah, jetzt kapier ich, was du meinst.

    Aber das sehe ich eigentlich auch kein Problem.

    Wieder am Beispiel von YAML:

    Wenn du ein 3-spaltiges Layout mit YAML habe willst,werden die Klasse col1,col2 und col3 verwendet. Ausserdem enthält jede der Spalten noch ein Div namens col1_content,col2_content,col3_content, die sind nötig um das Padding der Spalten unter umgehung dex Box Model-Bugs der älteren IEs zu regeln. Wo jetzt allerdingds die Spalten liegen, kann ich per CSS entscheiden, ohne den HTML-Code anrühren zu müssen, siehe http://www.yaml.de/de/dokumentation/anwendung/freie-spaltenanordnung.html

    Ich gehe aber meistens anders vor. Ich verzichte komplett auf col1-col3 und regel meine Layouts über die sogenannten Subtemplates von YAML.

    So kann ich zum Beispiel auf der einen Seite ein 1-spaltiges Layout verwenden, auf einer anderen ein zweispaltiges mit dem Verhältnis 33%/66%, auf der nächsten dann einen 3-Spalter.
    Dafür bietet YAML eine ganze Latte verschiedener Klassen an, siehe http://www.yaml.de/de/dokumentation/anwendung/subtemplates.html
    Diesen Weg finde ich einserseits flexibler, andererseits sind bei Layoutänderungen tatsächlich eingriffe im Markup nötig, allerdings nur, in dem ich die Klassennamen ändere, also aus c33l und c66r z.B. c25l und c75r mache.

  8. Marcel

    18. Februar 2011 um 22:41

    Ich denke jeder hat seinen Weg eine Umsetzung anzugegehen. Ich habe mich einige Zeit mit dem 960.gs beschäftigt und kurz mit der YAML-Erweiterung für TYPO3. Ich werde weiterhin den Weg bevorzugen meine Klassen und IDs nach dem Inhalt zu benennen und somit meine Flexibilität für CSS Änderungen nicht zu verlieren. Natürlich hat auch der Einsatz eines Frameworks seine Vorteile (siehe Artikel) nur überwiegen in meinem Fall bzw. meiner Arbeitsweise einfach die Nachteile.

    Trotzdem werde ich mir das YAML-Framework bestimmt nochmal genauer anschauen. Grade für Projekte in der Firma könnte dies doch durchaus eine gute Lösung sein. Mal sehen wann ich Zeit dazu finde. :)