23. März 2009
CSS-Frameworks sind bei mir immer wieder Thema. Klar, ich entwickle ja auch ein eigenes. Dennoch – vergleichbar mit der Argumentation pro & contra CSS-Layouts, die David Maciejewski, Tomas Caspers und ich in der letzten Technikwürze diskutiert haben – mache ich mir bereits seit längerem Gedanken um eine gehaltvollere Argumentation in der öffentlichen Diskussion. Die Anzahl der Framework-Projekte wuchs im letzten Jahr fast wöchentlich und noch immer kommen regelmäßig neue Projekte hinzu. Gleichzeitig wird die Streubreite der Layoutansätze, Funktionsumfang und Intention der Projekte (Layout, Formulare, Menüs) immer größer, sodass ein Vergleich zwischen einzelnen Frameworks nicht gerade einfach ist, ganz zu schweigen von der nicht weniger weitgefächerten Erwartungshaltung von Webentwicklern an derartige Projekte. Zudem gibt es weder im deutschen noch im englischen Sprachraum nur sehr wenige Beiträge, die sich eingängig mit dem übergeordneten Konzeptes eines Frameworks im Beich HTML & CSS beschäftigen. Einer der wenigen Beiträge in dieser Richtung “Frameworks for Designers” wurde im Juli 2007 von Jeff Croft auf A List Apart veröffentlicht.
Fast in direkter Folge auf diesen Artikel erschien seinerzeit Blueprint CSS auf der Bildfläche und leitete einen weltweiten Hype ein, obgleich Projekte wie YAMLoder YUI Grids zu diesem Zeitpunkt bereits jeweils etwa 2 Jahre Entwicklungszeit hinter sich hatten. Keines der beiden Projekte vermochte aber die Aufwerksamkeit der Gemeinde der Webentwickler derart aufzurütteln.
Mit Blueprint CSS und seinem geradlinigen Grid-Ansatz kamen die Diskussionen um CSS-Frameworks in Schwung, wobei insbesondere im englischen Sprachraum aufgrund des Hypes die beiden Bezeichnungen “CSS-Frameworks” und “Blueprint CSS” sehr eng miteinander verbunden. Positive Stimmen heben den Gridansatz von Blueprint (und damit CSS-Frameworks) in den Himmel, kritische Stimmen bemängeln den tabellenähnlichen Aufbau des Markups, weiten ihre Kritik aber ebenso wie die Beführworter meist pauschal auf alle Framework-Projekte aus. Hinzu kommt die verbreitete Liebe zu Top-Listen-Blogbeiträgen (“Die 10 besten ...”, “Die 100 besten ...”), wobei das Hinterfragen der unterschiedlichen Projektansätze zugunsten der Masse auf der Strecke bleibt.
Bereits auf dem Webkongress 2008 in Erlangen habe ich deshalb in meinem Vortrag versucht, einen etwas differenzierteren Blick auf die Vielzahl der Frameworkprojekte zu werfen und dabei die individuellen Stärken und Grenzen der Projekte, wie auch die allgemeinen Vorteile der Arbeit mit CSS-Frameworks herauszuarbeiten. Der im Verlauf der letzten 3 Wochen in Zusammenarbeit mit Nils Pooker entstandene Essay “Was Sie über CSS-Frameworks wissen sollten!” ist eine Fortführung dieser Betrachtung, der parallel auch in englischer Sprache veröffentlicht wird.
Wir haben dabei bewusst die Länge des Essays in Kauf genommen, denn wir wollten alle in der öffentlichen Diskussion befindlichen Aspekte ansprechen und nicht in einer Serie Einzelartikeln in Details verlieren. Zu schnell ginge in der Hitze der Diskussion der Blick auf das übergeordnete Konzept verloren. Erwartungsgemäß steckt in diesem Essay unsere meine Meinung pro CSS-Frameworks, denn sonst würde ich mich wohl kaum um die Weiterentwicklung von YAML kümmern. Wir hoffen, mit diesem Essay die Diskussion anregen zu können und freuen uns auf hoffentlich zahlreiche Kommentare und Blogbeiträge, gern auch mit gegenteiligen Meinungen. Bei Interesse antworten wir auf interessante Diskussionspunkte auch gern mit einem Folgebeitrag.
In diesem Sinne, viel Spaß beim Lesen ...
Montag, 23.03.09 (22:30 Uhr)
hallo
ich bin gerade dabei selbst so ein sogenanntes framework zusammenzubasteln - allerdings eher für mich persönlich.
bei der recherche fand ich es sehr aufschlussreich zu sehen wie andere web-entwickler/-designer ihre arbeitsordner und css-dateien strukturieren.
in deinem artikel habe ich eine leise kritik an der schwemme an frameworks herausgelesen - ich finde jedes hat seine existenzberechtigung, auch wenn ich kein einziges für den produktiven einsatz benutzen würde. gerade deswegen finde ich die spezialisierten ansätze sehr wertvoll.
yaml verfolgt ja eine ganz andere philosophie und ist für den produktiven einsatz gedacht, und sollte deswegen auch von blueprint, 960.gs & co abgegrenzt werden.
für mich gibts 3 relevante ansätze:
1.
ganzheitliche frameworks die für den produktiven einsatz geeignet sind (yaml/yui css framework)
2.
layout frameworks die sich v.a. für schnelles prototyping eignen (blueprint/960.gs) und die mehr oder weniger nichts weiter tun als raster-klassen definieren.
3.
typography resets (sen css/tripoli/eric meyer reset) die sich hauptsächlich mit bowserkonsistentem font-rendering und baseline-grids beschäftigen
zu jedem ansatz lassen sich viele gute pro und kontra argumente finden, trotzdem haben alle ihre existenzberechtigung.
Ein CSS Framework bedeutet für mich weitaus mehr als grid-klassen bereitzustellen und hübsche typo-samplepages zu generieren, deswegen kann ich deine kritik an dem hype nachvollziehen, aber wie gesagt ich störe mich eher an dem begriff ‘framework’ und freue mich darüber einblick in den arbeitsprozess von anderen zu bekommen.
Korbinian
Montag, 23.03.09 (23:27 Uhr)
Hi Korbinian,
Blueprint oder 960.gs haben im Rahmen ihrer Möglichkeiten in etwa den gleichen Funktionsumfang wie YUI Grids. YUI Grids ist wirklich nicht “ganzheitlicher”, es verwendet lediglich einen etwas anderen Layoutansatz. Ganz im Gegenteil. Blueprint bringt wenigstens noch ein Print-Stylesheet mit. YUI Grids kennt nicht einmal medienspezische Eigenschaften.
Ich habe kein Problem mit anderen Frameworks. Ich habe ein Problem mit der inflationären Verwendung des Begriffes für Dinge, die in Wirklichkeit keine Frameworks sind. Es gibt auch heute noch Unterschiede zwischen simplen Layoutvorlagen oder Filesammlungen und einem Framework. Auch ein Reset-CSS ist kein Framework, es ist maximal ein Baustein innerhalb eines Frameworks. bzw. ein Codeschnipsel.