NoFollow Free!
SHIFT Weblog

Dieses Blog ist ein Online-Magazin für erfahrene Website-Entwickler und Webdesigner, die PHP und Webdesign lieben.

Allgemein, CSS

Über den (Un)Sinn von CSS Frameworks

Es gibt viele gute Gründe, beim Erstellen einer Softwareapplikation ein Framework zu benutzen. Dieser Gedanke hat natürlich selbst bei den Webdesignern nicht Halt gemacht – und so gibt es beispielsweise für die serverseitige Sprachen  ASP.net und PHP (wie Zend, CodeIgniter und CakePHP) diverse Frameworks, die den Programmier-Alltag erleichtern sollen. Auch für das clientseite JavaScript existieren Frameworks wie jQuery oder MooTools.

Das es demzufolge auch irgendwann ein Framework für CSS geben muss, war fast sicher und nur eine Frage der Zeit – auch wenn bei dem Wort “Framework” die Grenzen gerne verschwimmen. Sogenannte CSS-Frameworks versprechen ein komfortableres, schnelleres Erstellen von Stylesheets oder sollen sogar dem Ersteller verhelfen, die CSS-Datei DRY zu kreiren.

Diese “CSS-Frameworks” lassen sich meines Erachtens in zwei Hauptgruppen aufteilen: Projekte wie YAML, 960gs oder blueprint gehören zu der ersten Gruppe und stellen dem Entwickler eine Sammlung von Klassenselektoren zur Verfügung, um die Typografie zu vereinheitlichen, das “floaten” zu vereinfachen und um Elemente der Webseite an gedachten Linien und Spalten auszurichten – ein sogenanntes “Grid-System”. Auch soll viel Zeit bei der Erarbeitung eines Print-Stylesheets eingespart werden.

Zur zweiten Gruppe gehören Meta-Sprachen für CSS – sogenannte CSS “Pre-Processors” – das bedeutet, dass der Entwickler eine andere, vereinfachte Syntax zur Verfügung gestellt bekommt – auf geschweifte Klammern wird hier beispielsweise verzichtet und im Gegenzug viel Wert auf die Einrückung der Elemente gelegt. Zusätzlich bietet es die Nutzung von Variablen (die eigentlich Konstanten heissen müssen) und funktionsähnlichen “Sammeldeklarationen”, sogenannten “mixins” an.

Schön, dass es solche Projekte gibt, möchte man jetzt vielleicht denken. Aber lohnt sich der Einsatz eines “CSS-Frameworks” überhaupt?

Zunächst ist der Begriff “Framework” nicht gerechtfertigt – denn eine Sammlung von Klassen(deklarationen) ist für mich kein Framework – genauso wenig ist eine Metasprache kein Framework. Naja, es hört sich ja aber auch total schick an, wenn man sagt “Ich benutze ein CSS-Framework! Du nicht?”.

Klassenbibliotheken

Der Hauptnutzen dieser Art von CSS-Frameworks ist sicher das Grid-System, das mit Hilfe von Floats realisiert wird. Eine Box kann also offenbar sehr einfach horizontal positioniert werden, ohne auf die anderen Elemente achten zu müssen.

Auch in Sachen Typografie und Formularelemente wollen diese CSS-”Frameworks” punkten. Für immer wiederkehrende Definitionen, wie z.B. der Abstand zwischen zwei Input-Textfeldern, bringt das blueprint-Framework beispielsweise eine forms.css mit, die solche Deklarationen schon vorher erledigt hat. Labels werden automatisch fett “gedruckt” und werden über den Formularelementen platziert. Für blockquote-Elemente wird der Text automatisch gräulich und kursiv dargestellt. Wie praktisch, dann muss ich das ja nicht mehr machen!

Schon klar – ich möchte auch mein eigenes Design mit einbringen. Dafür überschreibe ich also einige Definitionen einfach, so dass es mit meinem Design harmoniert. Viele voreingestellte Werte sind sicherlich korrekt, aber Farbwahl & Co. möchte ich bitte selbst verwalten. Kein Problem mit CSS Frameworks!

Doch Moment, war da nicht mal was..? Etwas, was noch tief in unserer Erinnerung sitzt? Ich hatte damit  zu tun, bevor ich das erste mal mit CSS-Resets in Berührung kam. Achja! Die voreingestellten Elementeinstellungen für Headings, Text und Formularelemente! Die werden ja zum Glück durch ein mitgeliefertes CSS Reset bereinigt!

Merkt ihr, was hier passiert?

  1. Browser haben  bereits vordefinierte Werte, zum Beispiel margin’s und padding’s für Headings.
  2. Mit einem mitgeliefertem CSS-Reset des Frameworks werden alle browserspezifischen Einstellungen wie margins entfernt.
  3. Das Framework bietet dem Benutzer dafür eigene, voreingestellte Definitionen in mehreren CSS-Dateien für das Aussehen und die Positionierung verschiedener Elemente, die ähnlich den browserspezifischen Definitionen sind.
  4. Der Benutzer überschreibt viele dieser voreingestellten Definitionen, damit es in sein Design passt.

Lasst mal den zweiten und dritten Listenpunkt beim Lesen aus – dann merkt ihr schnell, dass der Einsatz von blueprint & Co. eigentlich überflüssig ist - zumindest wenn sich selbst um grundlegende Styledefinitionen kümmern möchte: Wer auf das kleine bisschen Zusatzarbeit verzichten möchte, sollte sich der browsereigenen Definitionen bedienen. Diese verlangen auch kein extra Stylesheet.

Ich persönlich möchte weder vom Browser gesagt bekommen, wieviel margin mein Heading haben soll, noch von einem CSS-Framework.

“Ich persönlich nutze CSS Frameworks sowieso nur für Grid-Systeme” habe ich in Diskussionen oft gelesen. Ich frage mich dann immer, warum man sich ein Stylesheet mit seltsamen Klassendefinitionen einbaut, um sich die Mühe zu ersparen drei, vier Div-Boxen korrekt per Hand zu positionieren? Alles was man dafür braucht ist width, float und ein clearfix. Ich kann mir einfach nicht vorstellen, wie man sich die Sache mit Klassenzuweisungen wie div class=”span-6 prepend-3 last” einfacher machen möchte. Ganz zu schweigen vom überflüssigem Markup.

Wir haben gelernt, dass CSS-Frameworks, die einige vordefinierte Klassendeklarationen mit sich bringen, keine Frameworks sind. Der Sinn eines Grid-Systems bleibt mir schleierhaft, kann ich doch mit einigen CSS-Zuweisungen das gleiche herbeiführen – und das ohne überflüssige Klassenzuweisungen.

CSS Präprozessoren

Was für ein blödes deutsches Wort – da gefällt mir “Preprocessor” einfach besser. Ich werde es daher weiterführend vermehrt nutzen. Bekannte Projekte von CSS-Preprocessors sinds SASS und LESS. SASS verspricht auf seiner Webseite, dass mit dessen Einsatz “CSS wieder Spaß macht”. Macht CSS denn sonst keinen Spaß? Ich freue mich, eine so geradlinige und überschaubare Sprache nutzen zu können. Na gut, vielleicht geht das anderen ja nicht so. Was können also Preprocessors wie SASS und LESS?

Nehmen wir mal dieses Beispiel:

table.hl {
  margin: 2em 0;
}
table.hl td.ln {
  text-align: right;
}

li {
  font-family: serif;
  font-weight: bold;
  font-size: 1.2em;
}

Nutzt man die Metasprache SASS, so kann man sich offensichtlich eine wenig Tipparbeit ersparen und schreibt stattdessen.

table.hl
  margin: 2em 0
  td.ln
    text-align: right

li
  font:
    family: serif
    weight: bold
    size: 1.2em

Klingt interessant? Es geht noch weiter: Es gibt die Möglichkeit, Variablen Konstanten zu nutzen – damit lassen sich sogar Berechnungen durchführen:

$blue: #3bbfce
$margin: 16px

.content-navigation
  border-color: $blue
  color: darken($blue, 9%)

.border
  padding: $margin / 2
  margin: $margin / 2
  border-color: $blue

Hier mal ein Beispiel von sogenannten “Mixins”:

@mixin left($dist)
  float: left
  margin-right: $dist

#data
  @include left(10px)

#img
  border: 1px solid red
  @include left(2px)

Ein Mixin ist kann als eine Funktion oder ein CSS-Snippet verstanden werden, das von anderen Deklarationen eingebunden werden kann.

Vorteile von CSS-Preprocessors

Auf den ersten Blick scheint diese Technik eine neue Dimension in der CSS-Entwicklung darzustellen. Der “Boah-Effekt” ist bei erster Betrachtung sicherlich groß. Wir können

  • Variablen für zu definierende Werte vergeben, etwa für wiederkehrende Farben,
  • uns mit der geänderten Syntax offenbar Tipparbeit ersparen,
  • können wiederkehrende Deklarationen (etwa drei bis vier Zeilen für eine CSS3-border-radius-Deklaration) in sogenannte mixins verpacken
  • mit einem guten Preprocessor auch relative Farbwerte vergeben, etwa rgba(-10%, -11%, -8%, 50%)
  • können Größenangaben wie width anhand einer Variable berechnen lassen
  • Da wiederkehrende Werte dank Konstanten nicht immer wieder neu eingetippt werden müssen, rückt man DRY ein bisschen näher.

Schöne neue Welt? Nicht ganz – denn nur auf den ersten Blick liegen die Vorteile auf der Hand.

Nachteile

Präprozessor

Die Tatsache, dass die per Metasprache erstellte CSS-Datei erst einmal kompiliert werden muss, um als “normale” CSS Datei interpretiert zu werden sorgt bei mir für ein ungutes Magengefühl. Oder wie ich es der Leser “June”  eines englischen Blogbeitrages schrieb:

Man schreibt CSS-Code, um CSS zu generieren. Klingt nicht sehr innovativ. Es ist so, als würde man sein gesamtes Markup mit einem MVC-Helper schreiben. Präprozessoren wie LESS und SASS werden nativ nur von Ruby unterstützt. PHP-User bleiben erst einmal aussen vor – es sei denn, sie greifen auf eine weitere Bibliothek zurück, um die Metasprache zu interpretieren.

Debugging wird unnötig erschwert

Wie schön ist es doch, mit Hilfe von CSS-Browsertools wie Firebug den CSS-Definitionen auf die Schliche zu kommen. Uns wird die exakte Zeilenangabe neben dem betroffenem Selektor angezeigt – doch bei der Nutzung von CSS-Preprocessors wie LESS oder SASS ist das nicht mehr möglich: Bei der Umwandlung in “normales” CSS sind die betroffenen Zeilennummern nicht mehr identisch.

Wir kapseln uns also von wirklich nützlichen Features ab und sind gezwungen, wieder unsere Div-Boxen mit einer background-color zu versehen oder verschiedene Selektoren testweise zu löschen – so, wie es vor der Firebug-Ära gemacht werden musste.

Der Nutzen in der Praxis ist fraglich

CSS-Preprocessors sehen “auf dem Papier” sicherlich sehr gut aus. In der Praxis könnte ein solcher Einsatz aber den normalen Entwicklungsweg durcheinanderbringen. Zumindest meinen Entwicklungsweg:

Wenn ich ein Design im Kopf habe oder es vorher mit Photopshop realisiert habe, code ich erst einmal statisches HTML mit normalen Stylesheets. Wenn das Design steht, portiere ich die Dateien in meine Entwicklungsumgebung – etwa einem PHP-Framework. Möchte man aus den CSS-Preprocessors aber Nutzen ziehen, darf man erst in der Entwicklungsumgebung mit CSS anfangen – denn LESS und SASS erfordern eine Entwicklungsumgebung – und das ist  Ruby.

Ich müsste also, wenn ich meinen Entwicklungsweg beibehalten möchte, erst mein statisches CSS (das in der Regel dann aus mehreren hundert Zeilen besteht) in “LESS-CSS” oder “SASS-CSS” umwandeln, nur damit der Präprozessor diesen Haufen dann später in “normales” CSS umwandeln kann. Verwirrt? Ich auch.

Der ursprüngliche Kaskadierungsgedanke bleibt auf der Strecke

Die oben vorgestellten “mixins” sind einfach nur ein anderer Weg für das, was wir seit Jahren mit CSS anstellen können: Wir weisen einem HTML-Element eine bestimmte Klasse zu. Diese Klasse kann auch von anderen Elementen benutzt werden. Wer seine Klassendefinitionen also vernünftig umsetzt, wird mixings nicht brauchen:

<div class="highlight rounded left">...</div>

Mit dieser Methode können wir direkt im Markup die zu verwendenen Klassen benutzen. Denn wir dürfen nicht vergessen: Das Zuweisen von Klassen sollte im (X)HTML-Markup geschehen – nicht in der (Meta-)CSS-Datei selbst!

Mit Preprocessor-CSS wird euer Stylesheet nicht besser!

Wenn man sieht, was mit SASS, LESS & Co. machbar ist, fällt einem sicher ein: Die CSS-Entwicklung geht ja viel schneller! Doch das ist meiner Meinung nach eine Milchmädchenrechnung. Bevor man mit Preprocessor-CSS anfangen kann, muss man es in die Entwicklungsumgebung implementieren und eventuell bereits vorher erstellten “normalen” CSS-Code in die neue Syntax wandeln. Einige Operationen muss man sicherlich auch manchmal auf der Entwicklerseite nachschlagen – alle diese vermeintlich kleinen Dinge kostet Zeit. Wie schön war es doch, als man mit einem Texteditor eine style.css erstellen konnte und direkt drauflos tippen konnte! Copy & Paste kann benutzt werden, ohne auf die Einrückung zu achten (obwohl dies zum guten Stil gehören würde).

Mit der neuen Syntax spart man sich offensichtlich etwas Zeit – schließlich muss man diese lästigen, geschweiften Klammern nicht mehr Benutzen. Oder ein Semikolon ans Ende der Zeile führen. Das war ja auch so umständlich! Für diejenigen, die die Ironie nicht erkannt haben: Jede brauchbare IDE wie NetBeans bietet Codevervollständigung an, die dem Entwickler mindestens die gleiche Arbeit abnimmt.

Und wenn wir schonmal von Geschwindigkeit reden: Wie kann man da von einem Vorteil bei der Entwicklungszeit sprechen, wenn der kleinsten CSS-Änderung die Datei neu kompliliert werden muss?

Die Sprachen sind teilweise noch unausgereift

Die neue Syntax muss man nicht nur verstehen und erlernen, sondern auch mit ihren Nachteilen zurechtkommen. Hier mal ein Beispiel anhand eines Schnipsels aus einer LESS-CSS-Datei:

.aleft {
   float: left
   padding: 4px
}

Hier ist nicht zu erkennen, ob es sich um eine “herkömmliche” CSS-Definition handelt (Klassendefinition mit dem Namen “aleft”) oder um ein sogenanntes mixin namens “aleft”. Die einzige Möglichkeit, dies herauszufinden, ist weiter im Code nach einem eventuellen Aufruf dieses vermeintlichen mixins zu suchen.

Eine weitere Fehlerquelle im Gepäck

Wenn eine Webseite nicht richtig angezeigt wird oder nicht so angezeigt wird, wie man es sich vorgestellt hat, so muss der Entwickler im HTML-Markup, in der CSS-Datei und eventuell im JavaScript nach eventuellen Fehlern suchen. Mit dem Einsatz eines CSS-Präprozessors kommt eine weitere Fehlerquelle hinzu. Denkt dran: Firebug hilft hier nicht mehr weiter (siehe oben)!

CSS ist keine Programmiersprache!

CSS ist einfach. Auch unerfahrende Entwickler können nach nur weniger Zeit große Fortschritte machen. Es ist “straightforward” – also einfach und unkompliziert. Warum sollen wir eine einfache Sache nur unnötig kompliziert machen? Mit Kaskadierung hat man ein so mächtiges Werkzeug in der Hand, dass man aus CSS keine Programmiersprache machen muss. Hierzu auch ein Quicktip von csswizardry.com:

There are several tools and frameworks out there at the moment which extend CSS to adopt a more programmatic syntax and function. It is in my opinion that these are only really of benefit to people who haven’t yet mastered writing CSS properly from the outset…

If you learn how to write your CSS sensibly, write more shared styling and utilise the cascade fully, you will see little if any need for things like SASS et all.

Fazit

CSS-Frameworks scheinen auf den ersten Blick unheimlich tolle Dinge zu bescheren – doch in der Praxis ist es gar nicht notwendig. Der Sinn hinter dem Einsatz von Klassenbibliotheken wie blueprint oder YAML sind mir weiterhin schleierhaft.

Ich muss aber zugeben, dass Elemente wie Variablen und Funktionen innerhalb einer CSS-Datei interessant klingen. Aber wir dürfen nicht vergessen, was CSS ist und wofür es geschaffen wurde. SASS wegen der anderen Syntax nutzen? Nö. CSS hat sicherlich seine Probleme – aber nicht die Syntax.

 

Kommentare

Auf dieses Thema gibt es 32 Reaktionen

  1. MoonSign

    danke für den text. ich dachte schon ich waere der einzige, der den sinn hinter diesen css frameworks nicht versteht. sass kannte ich bisher noch nicht – ich muss mich wohl mal wieder in ruby on rails einarbeiten :]

  2. Samuel Herzog

    Wunderschöner Beitrag, Danke :)

    Was mich allerdings regelmäßig dazu treibt, über CSS Frameworks nachzudenken, ist dass ich wirklich wirklich gerne ECHTE Variablen im CSS hätte – die ich dann per JS anpassen können würde – nur das kann freilich weder SASS noch LESS bieten ;)

  3. nikosch

    „Alles was man dafür braucht ist width, float und ein clearfix. Ich kann mir einfach nicht vorstellen, wie man sich die Sache mit Klassenzuweisungen wie div class=”span-6 prepend-3 last” einfacher machen möchte.“

    Ganz einfach – komplexe Seiten, Webmagazine o.ä. mit wechselnden Columnlayouts aber konsistenter Gesamtoptik. Noch wichtiger wird das in backendbasierten Systemen, die dann eine AUswahl des Columnlayouts erlauben.

    • @nikosch
      Du kannst wechselne Columnlayours doch auch mit einfachen Klassenzuweisungen realisieren. Die Klassen müssen eben einfach nur ein bisschen durchdacht sein – ein Framework nimmt dir das auch nicht ab.

      • nikosch

        Je nach angestrebter Komplexität sind die Grenzen zum Framework aber sehr fließend. Wer mal ein echtes Gridsystem angestrebt hat (was bspw. auch mit IEs Boxmodel-Eigenheiten klarkommt), findet schnell ein kaum weniger großes System wieder.

  4. beeblebrox

    Ich gehe mit dem Artikel konform. IMHO versuchen die PPFWs aus CSS eine Programmiersprache zu machen – das geht mir gegen den Strich.

    DRY mag ein tolles Konzept sein, aber bei so simpel strukturierten Sprachen wie CSS empfinde ich das gute alte KISS-Prinzip als deutlich praktikabler.

    Nikosch sagte hier, daß eigene CSS-Konstrukte mit zunehmender Komplexität der Site (oder des Projekts, der Umgebung, whatever …) auf ein Maß anschwellen können, das den Frameworks in nichts nachsteht. Damit hat er (?) völlig Recht. Was er (?) allerdings dabei vernachlässigt, ist die Tatsache, daß es für nahezu jeden Webdev einfacher ist, dieses eigene Konstrukt zusammenzubauen, als sich bis in die letzten Winkel eines fertigen Frameworks einzuarbeiten. Oder bin ich es, der hier etwas vergißt?

    • Nein, ich denke nicht dass du was vergessen hast. Allerdings ist es natürlich richtig, dass mit zunehmender Größe der Seite auch die CSS-Datei / die CSS-Dateien wachsen und so schnell unübersichtlich werden. Ohne Firebug ist man hier dann schnell verloren.

      Aber seitdem ich meine CSS-Dateien meistens sehr genau dokumentiere und kommentiere, finde ich die nötigen Selektoren ganz schnell wieder. Dafür ein extra Framework? Nö. Das bringt auch nicht mehr Ordnung rein. Man spart sich nur einige Zeilen Code. Was für ein Gewinn.

  5. tschundeee

    Also ich gehe weitestgehend mit dem Artikel konform.
    Ich habe neulich aus einem älteren Rails-Projekt compass (SASS & HAML) zugunsten von einfachem CSS-Code rausgeworfen…
    Fairer weise muss man aber sagen, dass die YAML-ähnliche Einrückungssyntax bei compass in .sass-Dateien zugunsten von .scss ersetzt wurde.
    Ich nutze .scss nur als css mit Variablen. So kann man leichter Farben im Nachhinein ändern.
    CSS-Grids sind meiner Meinung nach völlig überflüssig.

  6. Alex

    ist getweetet von “atrioom”!
    ich war schon ein paar mal in versuchung sowas auszuprobieren, jetzt definitiv nicht mehr. danke ;)

  7. hans

    Hi,
    man sollte vielleicht nicht vergessen das es auch webdevs gibt die in Gruppen arbeiten und nicht nur in Einzelarbeit Websites entwickeln. Sicherlich hat ein Framework einen gewissen overhead. Das ist einfach so und kann immer als Totschlagargument genutzt werden. Wenn man ein gut dokumentiertes Framework vernünftig einsetzt hat es den Vorteil das ich einem Entwickler nicht das gesamte CSS erklären muss, wenn er dem Team beitritt.
    Ehrlicher Weise funktioniert das nur wenn alle Teamnitgleider den gleichen Wissensstand zum Framework haben und nicht für jeden Mist nen neue Klasse erfinden ohne die Framework eigenen zu nutzen.

    Ein Reset macht im professionellen Umfeld aus meiner Sicht auch Sinn, denn dem Designer und Artdirektoren ist es nicht egal welcher Abstand zwischen Elementen exisitieren. Das ist zwar im Entwicklungsprozess nervig aber sie haben leider Recht. In einem solchen Zusammenhang zu argumentieren der Browser weiß schon was er macht, ist leider nicht realistisch.

    Die Verwendung von Variablen in CSS macht gerade bei riesen CMS System die über Jahre bestehen auf jeden Fall Sinn.

    • Danke für dein Kommentar,

      ich habe nie etwas gegen CSS Resets gesagt, im Gegenteil, ohne diese wäre das Leben eines Designes stark erschwert.

      Und ich glaube, dass man einem erfahrenen Coder nicht erst CSS-Deklarationen erklären muss. Wenn Unklarheit über eine bestimmte Zuweisung erfolgt, kann man immer noch via Firebug etwas inspizieren.

  8. So richtig übereinstimmen würde ich hier nicht.

    Ich war von LessCSS am Anfang begeistert – dann kamen die von dir erwähnten Nachteile (extra “Kompilierung”, Tools unterstützen die Syntax nicht, Zeilennummern etc.) und ich fand LessCSS wieder blöd..

    Allerdings hat sich in der Zwischenzeit einiges getan: Less kann “nativ” in eine Seite eingebaut werden (mit einem einzigen JS als preprocessor) oder via PHP – sowie viele Editoren unterstützen Less inzwischen von Hause aus.

    Der initiale Aufwand ist zum einen nicht groß, zum anderen ist er beim nächsten Projekt genau gleich 0. Ich muß keine serverside Lösung verwenden und das JS mitzukopieren ist nun keine Arbeit.

    Und natürlich gibt es einen Performance-Nachteil. Aber auch das relativiert sich, denn genau wie man evtl. JS/CSS-Minify verwendet, würde ich am Ende natürlich eine reine CSS-Datei verwenden.

    Von daher ist es für mich eher die Frage, ob die verwendeten Tools es unterstützen und ob es dem persönlichen Workflow hilft.

  9. Ich bin zwar kein Professioneller Coder oder sonst was, doch muss ich sagen das es in dem Sinne wie ich CSS gerne mal zum realisieren einen kleiner Seite immer wieder gerne auf ein Grid System zurückgreife, es geht fix ich kann mir zu 90% sicher sein, dass ich keine nervigen Bugs im IE oder sonst wo habe und ausserdem noch recht valide und Crossplattform coden kann. Klaro, es gibt immer die die sagen Handgemacht ist besser, doch warum nicht auf solche Resourcen zurückgreifen oder direkt als vorlage für eine customized version nehmen.

  10. Gernot Kogler

    Ich sehe die Situtation 100% gegenteilig, aber der Reihe nach:

    1. SASS und Konsorten
    ———————
    Ich schreibe ungern Sachen, die den Code unnötig aufblähen, aber keinen wirklichen Mehrwert liefern. Daher verwenden wir u. a. SASS, HAML, Coffeescript. Wenn ich Code der besseren Lesbarkeit zuliebe sowieso einrücke, warum muss ich dann noch die geschweiften Klammern schreiben? Und wozu Strichpunkte? Das ist unnötiger “Lärm” im Code, der überhaupt nichts bringt.

    Dass IDEs diese Dinge automatisch vervollständigen können, zeigt nur, wie überflüssig sie eigentlich sind.

    Zum Thema Variablen und Mixins: Ist es nicht wesentlich eleganter, eine Farb-Variable zu definieren und diese in ein paar CSS-Klassen zu verwenden, anstatt eine “Farb-Klasse” hunderten von HTML-Elementen zuzuweisen? Mixins erlauben einen sauberen Aufbau der Strukturen, ohne sich endlos wiederholen zu müssen. Was ist eleganter:

    .simple { @include border-radius(4px, 4px); }

    oder

    .simple {
    -webkit-border-radius: 4px 4px;
    -moz-border-radius: 4px / 4px;
    -o-border-radius: 4px / 4px;
    -ms-border-radius: 4px / 4px;
    -khtml-border-radius: 4px / 4px;
    border-radius: 4px / 4px;
    }

    (was SASS aus dem ersten Beispiel generiert) ?

    2. CSS-Frameworks
    —————–
    Ich würde kein Projekt mehr starten, ohne ein gridbasiertes CSS zu verwenden. Grids helfen ungemein bei der Zusammenarbeit mit Grafikern (die oft sowieso einen Grid verwenden, wenn sie ein Layout designen). Und es genügt nicht, einfach ein bisschen float und clearfix zu streuen, zumindest nicht, wenn das Layout komplex ist (verschachtelte Grids) und alle Browser unterstützt werden sollen.

    Warum also soll ich das Basis-CSS mühsam selber basteln, wenn mir ein CSS-Framework diese Arbeit abnehmen kann? Gute CSS-Frameworks generieren sauberes CSS, das ich nicht besser schreiben könnte.

    3. Toolset
    ———-
    Ich kann mir ehrlich gesagt nicht vorstellen, dass der Author immer noch diese Meinungen vertreten würde, wenn er einmal mit einem kompletten, modernen Toolset gearbeitet hat (ich unterstelle aufgrund des Blogposts jetzt mal frech, dass er das noch nicht gemacht hat). Unseres sieht z.B. so aus (nebst diversen weiteren Komponenten):

    - Ruby on Rails 3.1
    - HAML
    - SASS
    - Compass
    - Susy (Grid-System für Compass)
    - Coffeescript

    Wenn dies alles richtig konfiguriert ist (was sehr einfach ist), dann resultiert daraus sauberstes CSS, HTML und Javascript, wie man es besser nicht selber schreiben könnte. Und das vollautomatisch: Im Entwickler-Modus bei jedem page load, beim Deployment auf ein Staging- oder Produktionssystem innerhalb des Deployment-Prozesses (natürlich werden nur die finalen CSS- und Javascript-Dateien deployed).

    • Hallo,

      vielen Dank für das ausführliche Kommentar.

      >> Dass IDEs diese Dinge automatisch vervollständigen können, zeigt nur, wie überflüssig sie eigentlich sind.

      Trotz meiner Ablehnung gegen CSS-FW’s – Da gebe ich dir Recht!

      >> Warum also soll ich das Basis-CSS mühsam selber basteln, wenn mir ein CSS-Framework diese Arbeit abnehmen kann?

      Das Erstellen von Basis-CSS ist nicht mühsam. Auch bei verschachtelten Contentboxen.

      >> Gute CSS-Frameworks generieren sauberes CSS, das ich nicht besser schreiben könnte.

      Was verstehst du unter “sauberem CSS”? Und selbst wenn es so wäre – das Markup wird durch die vielen nichtssagenden Klassen total vermüllt.

      Zu deinem dritten Punkt:
      Ich habe mit all den o.g. Tools schon gearbeitet, jedoch nicht in der Konfiguration wie du sie vorgestellt hast. Da du mit RoR arbeitest, musst du dich um einen Großteil der Implementierungen nicht kümmern. Ich als PHP-Entwickler muss es aber, es gibt kein sauber verknüpftes Netzwerk zwischen diesen Komponenten.

      Was machst du denn, wenn ein Entwicklerteam zu deinem Projekt hinzustößt, das nicht mit SASS & Co. arbeitet?

  11. Hallo zusammen,
    gerade vor einiger Zeit bin ich über LESS gestolpert. Gerade die Möglichkeit, sich nicht ständig wiederholen zu müssen (z.B. durch zentrale Definition von Farben) ist sehr reizvoll. Allerdings lassen sich LESS und SASS recht schlecht in einen “Online-Workflow” integrieren. Wenn man also versucht, ein kompiliertes CSS-File zu verwenden, um die Integration von LESS-Funktionen per JavaScript zu vermeiden, gibt es keine vernünfitge Alternative dazu. Jedoch ständig zu komplieren und hochzuladen, ist auch nicht wirklich praktikabel.

    Je mehr ich mich damit beschäftige, desto weniger Interesse habe ich an einer Verwendung. Zugleich aber steigt der Drang, eine Alternative zu entwickeln, die zumindest einen Teil lästiger Arbeit bei der Erstellung von Styles per Hand erleichtern kann.

    Hat jemand eine Idee?

  12. Mario

    Also bei den Preprocessors bin ich noch unschlüssig und „teste“ noch. Das muss in der Praxis bei mir funktionieren.

    Und bei den Frameworks kann ich nur von YAML sprechen. Aber da muss ich sagen, dass ich das nicht mehr missen möchte. Klar kann man das auch von Hand, aber leider gibt es nicht nur aktuelle Versionen vom Chrome, Safari und Firefox da draußen. Ich habe keine Lust, stundenlang auf (IE)-Fehlersuche zu gehen. Und das bezahlt mir auch kein Kunde. Das abfangen von Browserbugs und die Möglichkeit, das Layout blitzschnell zu ändern sind die Dinge die für mich zählen. Zumal YAML flexible Layouts ausgibt und nicht starre 960 px Einteilungen (wie bei anderen) vorgibt.

    Das mit dem überflüssigen Markup (falls überhaupt existent) sehe ich ganz locker. Wenn man konsequent ist, kann sollte man sich auch die meisten CMS sparen. Was da oft am Ende rauskommt ist viel schlimmer. Soll man auf die auch verzichten, weil da ein div zuviel ist oder einen sperrigen Klassennamen hat?

  13. Wenn man sich einen geeigneten Workflow aufbaut – das einfachste für LESS ist diese kleine Software für OSx (http://incident57.com/less/) – sehe ich keinen Grund, warum man kein LESS verwenden sollte.

    Vorteile:

    Sauberere Stylesheets durch Mixins (zum Beispiel mit parametrischen Mixins und Vendor-Prefixes)

    übersichtliche Stylesheets durch Imports – wenn man eben nicht eine riesen CSS Datei schreiben muss sondern alles in Partials zerlegt findet man Codestellen wesentlich schneller, außerdem kann man dadurch sehr einfach im Team am CSS arbeiten

    Funktionen zum Manipulieren von Werten (Farbe abdunkeln, aufhellen, Breiten ausrechnen)

    Verwenden von Variablen (einmal eine Grundfarbe definieren, komplettes Design wird eingefärbt)

    Beim Parsen kann man die resultierende CSS Datei auch gleich noch komprimieren

    Als Nachteil aufzuführen, dass es nicht in Deinen Workflow passt, ist einfach kein Argument. Wie kommst Du denn auf die Idee, zunächst normales CSS zu schreiben und das dann in LESS umzuschreiben? Das ist natürlich Quark, da macht LESS keinen Sinn für Dich wenn Du so rum arbeitest : )

  14. Würde mich interessieren, ob du heute auch noch so denkst und das CSS weiterhin “per Hand” erstellst.

    • Hallo,
      entschuldige die späte Antwort. Auch heute noch schreibe ich mein CSS “per Hand”. CSS-Grid-Layouts habe ich mir immer mal wieder angeguckt und überlege, mal wieder an eine schlanke Umsetzung auszuprobieren. Eine Notwendigkeit dafür sehe ich jedoch definitiv nicht.

  15. Ich teile Deine Meinung zum Teil und bin selbst übersatt von den ganzen Frameworks, die alles noch besser resetten und gridden, bis der Arzt kommt. Vor allem das total überladene und inflationär eingesetzte Bootstrap macht mich langsam fertig (auch wenn ich das selbst auf meiner Seite eingesetzt habe, was ich mittlerweile bereue).

    Allerdings mache ich, was LESS bzw. SASS angeht, gerade die Erfahrung, dass es richtig eingesetzt die Zusammenarbeit mit mehreren Entwicklern erheblich erleichtern kann. Bei einem aktuellen Projekt gibt es z.B. ein globales Mixin, worauf alle Entwickler zugreifen können, um ihre Apps bzw. Pagelets auf dieser Basis zu entwickeln. Da tauchen nicht zig mal die selben Funktionen und Klassen auf, die aber jeder so schreibt, wie er grad lustig ist. Von Vendor-Prefixes mal abgesehen. Man kann also eine Syntax besser einhalten.

    Auch das mit den Variablen sollte man nicht gleich als Humbug abstempeln, weil man es ja auch alles per Hand schreiben kann. Klar kann man das. Aber bastel mal 40 statische Templates, wenn der Kunde dann sagt, er hätte gerne irgendwelche Farben oder Schriftgrößen anders. Wenn die Variablen sinnvoll verkettet sind, ist das nämlich schnell ein Zeitersparnis von einer Stunde und mehr. Wenn man Dinge wie Farben, Schriftgrößen, Widths und Image-Pfade in Variablen packt, ist es nicht nur für einen selbst besser zu pflegen.

    Wie schon erwähnt teile ich gewisse Ansichten, aber wenn man das Beste aus den jeweiligen Frameworks für sich rausholt und den ganzen überflüssigen Kram liegen lässt, dann kann man schon gerne die Entwicklung der CSS-Entwicklung feiern. Ich frage mich nur, warum man sich ein Framework zulegt, welches Buttons und die ganze GUI schon definiert hat, was man am Ende dann eh überschreiben muss, um es an sein Design anzupassen. Diese Logik habe ich noch nie verstanden. Aber Grids und ein schmales Reset dürfen schon sein.

    Dennoch sollte man erst mal überlegen, was und ob man es braucht, bevor man es benutzt. Aber so ist es ja mit allen Dingen auf dieser Welt.

  16. derSteffen

    Hallo,

    dass ist wirklichalles sehr interessant und ich bin ebenfalls stark am Überlegen SASS einzusetzen, allerdings habe ich ein Problem, was hier auch schon erwähnt worden ist. Wenn mein CSS-Style schon online ist und ich diese weiter anpassse, weil z.B. in einem CMS neue Module hinzu kamen. Nutzt mir SASS doch nichts, oder? Okay, die Arbeit am Anfang wird eventuell abgenommen, aber z.B. eine Suchen & Ersetzen-Funktion im Editor (vorausgesetzt einer guten Doku des CSS-Styles) erfüllt im großen und ganzen die Variablen-Option von SASS.
    Oder hat jemand von euch einen Tipp, wie ich SASS auch online nutzen kann? gibt es da Tools oder Tricks?! Vielleicht WebOrdner und Freigaben unter Windows einrichten und das dann irgendwie “watchen”.

    VIelen Dank

    MfG Steffen

  17. Ich sehe den Einsatz von CSS Frameworks nicht kritisch. Wenn sich damit Redundanz vermeiden lässt, ist das Endergebnis von höherer Qualität. Weniger Code, weniger Tippfehler, mehr Übersicht.

  18. datenkind

    Falls den Artikel im Jahre 2013/2014 liest: Vergesst es. Alles ist anders und besser. Schade, dass der hier noch bei Wikipedia verlinkt ist.

  19. datenkind

    Achso. Ich frag mich ja grad noch ernsthaft, warum man Frameworks und Stylesheet-Meta-Sprachen wie SASS/SCSS mit zusammwnwürfelt. Das hat miteinander überhaupt nichts zu tun.

  20. Hallo,
    sollte das Ziel eines Developers nicht auch an der Übertragungsrate der verwendeten Dateien gemessen werden?

    Was nutzt mir die einfache Erstellung eines Webauftritts durch die Nutzung eines Frameworks, wenn dadurch eine Unmenge an Daten über das Netz fließen müssen?

    No, sorry. Aus meiner Sicht der falsche Ansatz.
    Ich halte es immer noch für den besseren Ansatz, für jeden Auftritt eine angepasste Lösung zu bieten.

    Aber …thinsp;, vielleicht sollte man es sich so einfach wie möglich machen!

    Daher empfehle ich Robert Palmer, Best Of Both Worlds .

    MfG uSeIT

    P.S. Eine Überarbeitung des Eingabefeldes wäre schön.

  21. Danke für diesen mutigen Beitrag! In allen Fachzeitschriften werden diese CSS-Metasprachen hochgejazzt, ohne auf die Nachteile zu verweisen. Hier endlich mal jemand, der sagt: “Der Kaiser hat ja gar nichts an!”

    Ich habe SASS und LESS ausprobiert und bin schnell wieder zu handgeschriebenen CSS zurückgekehrt. Wenn man sich einmal im Lauf der Zeit ein paar immer gültige Routinen zusammengeschrieben hat, dann kann man Standards, die immer gebraucht werden, schnell zusammenpasten, und die so gewonnenne Zeit für wirklich saubere CSS-Entwicklung verwenden. CSS3 ist spannend genug.

  22. 74

    Sehr rückwärtsgewandter, einseitiger Artikel. Lesen, ignorieren und Spass haben.

  23. Malheur

    Der Artikel ist ja nun nicht mehr ganz taufrisch, und vieles ist tatsächlich obsolet. Grids selbst zu basteln ist z.B. kaum mehr zeitgemäß!

    Was bleibst ist allerdings ein mehrfach wiederholtes, zentrales Argument: Der Debuggig-Prozess!

    Die Verwendung eines Preprozessors spart einerseits Ressourcen, andererseits ist die Fehlersuche aufwändiger. Für mich gilt: Präprozessoren in grossen Teams und vor allem in der Produktion von Frameworks selbst. Keine Präprozessoren in kleinen Teams und schon gar nicht, wenn “Pixelschieberei” notwendig wird!

  24. begs

    Leider ein typischer Fall von “Noch nie wirklich mit SASS gearbeitet”.
    Am besten sollte sich der Autor mal richtig mit SASS und dessen Möglichkeiten beschäftigen und erst danach dieses geniale System, durch wirkliche Argumente, schlecht machen.

Hinterlasse eine Antwort

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *

*

Du kannst folgende HTML-Tags benutzen: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre lang="" line="" escaped="" highlight="">

 

Weitere Artikel der Kategorie CSS

CSS, JavaScript & jQuery, Quickies

CSS-Schnittstelle für deaktiviertes JavaScript

Moderne Webseiten sind oft vollgestopft mit JavaScripts, um die Benutzerfreundlichkeit zu verbessern. Natürlich sollte eine Seite dann aber so gestaltet sein, dass sie auch ohne JavaScript funktioniert. Dabei müssen aber oft Anpassungen im Stylesheet vorgenommen werden. Das wiederum bedeutet, dass CSS-Anpassungen gemacht werden müssen, je nachdem, ob JavaScript beim Client aktiviert ist oder nicht. Das

Weiterlesen ›

CSS

Neue Informationen rund um CSS3

Wer glaubt, dass CSS3 keine Neuerungen mehr erfährt, täuscht sich. Sogar das “gute alte” CSS 2.1 ist immer noch in einem Stadium, das als nicht abgeschlossen gilt. Demzufolge ist es sehr wahrscheinlich, dass wir in Sachen CSS3 noch einige Überraschungen erleben dürfen. Aus gleich zwei Quellen habe ich auch gleich etwas parat – für meinen

Weiterlesen ›

CSS, Links am Rande

Links am Rande (4) – CSS only

Die Links, die ich heute vorstelle stehen ganz unter der Flagge von CSS. Vorgebackene CSS3 Media-Queries für Handys und Handhelds gibt es bei stuffandnonsense.co.uk. Lange war ich auf der Suche nach einer CSS-Selektorsuche, die auch seitenübergreifend funktioniert. Mit dem Firefox-Plugin CSS-Usage bin ich fündig geworden. Es ist eine Erweiterung für das nicht mehr wegzudenkende Firebug.

Weiterlesen ›