23. März 2009
Layout-Frameworks werden immer beliebter und sind auf gutem Weg, sich als fester Bestandteil der Webentwicklung zu etablieren. Nun ist jedoch der Begriff des «Frameworks» vorrangig aus dem Bereich der Softwareentwicklung bekannt und weder HTML noch CSS können als Programmiersprache bezeichnet werden, weshalb die Übernahme der Bezeichnung in den Bereich von HTML/CSS nicht unumstritten und oft verwirrend ist. Ähnlich verhält es sich mit dem gedanklichen Ansatz eines CSS-Frameworks an sich, denn eben weil es sich nicht um Programmierung handelt, besteht trotz der Widrigkeiten des Alltags insbesondere unter professionellen Entwicklern die Überzeugung, Markup und CSS-Regeln vollständig von Hand schreiben zu müssen, um sauberen und schlanken Code zu erhalten. Zum Teil rührt dieses Vorurteil aus den Erfahrungen, die wahrscheinlich jeder Entwickler aus seinen Anfangszeiten mit automatischen Codegeneratoren wie Frontpage, GoLive oder Dreamweaver als einprägsame Negativbeispiele für sein Leben mit sich trägt.
Note: This essay is also available in English.
Inhalt
- Die allgemeine Einschätzung der Webentwickler
- "CSS-Frameworks are never the best solution ..."
- Zukunftssicheres und wartbares CSS
- Liefern Frameworks unsemantischen Code?
- Nur für Anfänger oder fehlender Lerneffekt?
- Fazit
Die allgemeine Einschätzung der Webentwickler
HTML und CSS werden clientseitig interpretiert. Ein möglichst schlanker Code für individuelle Projekte sollte daher vorrangiges Ziel jeder Layoutentwicklung sein. CSS-Frameworks sind hingegen projektunabhängige Baukastensysteme, deren Ziel ein möglichst universeller Lösungsansatz für unterschiedlichste Layouts darstellt. Wie passen diese offensichtlich gegensätzlichen Anforderungen also zusammen?
Eine Vielzahl von Projekten (mittlerweile über 20) finden sich im Netz unter der Bezeichnung «CSS-Framework». Dabei streuen Qualität der Umsetzung und Dokumentation ebenso wie der Anspruch an Funktionsumfang und die zugrunde liegenden Layoutkonzepte derartig stark, dass ein objektiver Vergleich untereinander extrem schwierig ist. Hinzu kommt, dass es bisher keine klare und allgemein anerkannte Definition gibt, was ein CSS-Framework wirklich ausmacht. Gleichzeitig besteht jedoch genau in diesem Bereich ein großes Informationsbedürfnis, was leider zu zahlreichen undifferenzierten und oberflächlichen Betrachtungen führt. Die typische Argumentation bei Diskussionen Pro & Contra CSS-Frameworks sieht folgendermaßen aus:
Advantages of CSS Frameworks
- You increase your productivity and avoid common mistakes.
- You normalize your code/class base.
- You have a better workflow within a team.
- You gain an optimal browser-compatibility.
- You have a clean, well-structured and complete code.
Disadvantages of CSS Frameworks
- You need time to fully understand the framework.
- You need a close familiarity with your code’s architecture.
- You might inherit someone’s bugs or mistakes.
- You develop sites upon a framework, not upon the solid knowledge of CSS
- You get a bloated source code.
- CSS can not be framed semantically.
- Ignoring the uniqueness of your project.
CSS Frameworks + CSS Reset: Design From Scratch, Smashing Magazine
Als Entwickler des (X)HTML/CSS-Frameworks YAML muss ich mich permanent diesen Argumenten stellen, um das Projekt bei der Weiterentwicklung auf Kurs zu halten. Daher möchte ich in diesem Essay meinen Standpunkt zu den am häufigsten geäußerten Kritikpunkten an CSS-Frameworks darlegen, wobei ich hierfür meine Definition eines CSS-Frameworks als Maßstab ansetze.
CSS-Frameworks sind leistungsfähige Entwicklungsumgebungen für die Erstellung von Webseiten und richten sich vorrangig an professionelle Webentwickler. Sie stellen universelle Layoutbausteine bereit und definieren ein Regelwerk, im Rahmen dessen der Entwickler sich frei bewegen kann.
Wichtig ist hier die Feststellung, dass CSS-Frameworks Werkzeuge für Profis sind. Ein Projekt wie YAML mag vielleicht auf den ersten Blick wie ein Fertigbaukastensystem mit Layoutvorlagen und fertigen Beispielen erscheinen, aber sämtliche Vorlagen und Beispiele dienen nur der Anschauung, wie flexibel diese Umgebung in der Praxis professioneller Webentwicklung genutzt werden kann.
Ich werde mich in der Diskussion an verschiedenen Stellen auf Fachartikel von Jens Meiert stützen, einem der bekanntesten deutschsprachigen Webentwickler und energischen Vertreter von standardkonformem und schlankem Code. Dabei habe ich nicht die Absicht Jens persönlich anzugreifen. Vielmehr schätze ich seine Beiträge sehr hoch, denn er ist einer der wenigen Kritiker, die ihren Standpunkt nicht nur einfach in den Raum stellen, sondern mit stichhaltigen Argumenten hinterlegen. Seine Artikel sind daher eine gute Grundlage für eine ansprechende Fachdiskussion.
"CSS-Frameworks are never the best solution ..."
Ob die oben zitierten Nachteile tatsächlich zutreffen, soll im Folgenden überprüft werden. Tatsache ist aber, dass CSS-Frameworks aus verschiedensten Gründen nicht jedermanns Sache sind. Jens Meiert versucht dafür auch mehrere Gründe zu benennen:
"Public, or open, HTML/CSS “frameworks” are never the best solution, and oftentimes not even a good solution for any site. [...] So why stating that frameworks aren’t a good solution? Because people outside your company or outside your apartment just cannot know your needs, and this implicit ignorance results in way too much markup in your documents and way too many rules in your style sheets, making any framework-based solution inferior to something tailored."
A few words on HTML/CSS-Frameworks, Jens Meiert
Auf den ersten Blick erscheint das verständlich. Ein Framework kann sich auf Webstandards und Best-Practice-Methoden stützen, unmöglich aber die individuellen Arbeitsweisen eines einzelnen Entwicklers oder einer Agentur zu 100 Prozent abbilden. Deshalb verlangt die Arbeit mit einem CSS-Framework nach einer gewissen Einarbeitungszeit in den Code und seine Funktionsprinzipien. Dazu gehört auch, dass der Entwickler seine individuelle Arbeitsweise entsprechend den konzeptionellen Ansätzen des CSS-Frameworks angleichen muss.
Jens Meiert folgert jedoch allein aus der Tatsache des fremden Codes, dass CSS-Frameworks immer mit einem Overhead an Markup und zu vielen CSS-Regeln einhergehen. Dahinter steht die Annahme, Frameworks würden erstens keine individuelle Arbeitsweise und zweitens keine Möglichkeiten der finalen Code-Optimierung zulassen. Diese Annahme ist der eigentliche Aufhänger seiner Kritik. Der Denkfehler in Meierts Argumentation besteht darin, dass nicht individuelle Arbeitsweisen oder konkrete Projektanforderungen die Basis professioneller Webentwicklung darstellen, sondern die Arbeit nach geltenden Webstandards. Dieses Regelwerk ist nicht nur die Grundlage jeder professionellen Webentwicklung, es ist ebenso die Grundlage unterschiedlicher und individueller Arbeitsweisen. YAML als das aktuell umfangreichste und ausgereifteste CSS-Framework basiert ebenfalls auf diesen Webstandards, es gibt also ein Fundament, das aus Transparenz des Quellcodes, klarer Trennung von Inhalt und Layout und semantisch korrekten Auszeichnungen innerhalb der HTML-Seitenstruktur besteht.
Betrachten wir die Praxis der Webentwicklung: Trotz aller Unterschiedlichkeit der Millionen von Websites ist deren struktureller Aufbau grundsätzlich ähnlich. Meistens gibt es einen ein Header, eine Navigation, einen klar eingegrenzten Inhaltsbereich (content), eventuell eine Sidebar und abschließend ein Footer, wobei sich auch diese Art der Benennung schon fast als Konvention durchgesetzt hat. Vielleicht gibt es mehrere Spalten und vielleicht gibt es auf ausgewählten Seiten einen Teaser oder kleine Variationen des Layouts. Dennoch unterscheiden sich Websites nicht mehr voneinander als ein Haus, das auch bei individueller Ausführung und größter Unterschiedlichkeit zu allen anderen Häusern über ein Fundament, eine Wohnebene und ein Dach verfügt.
Frameworks, Codeschnipsel und Webdesign-Praxis
Zum Thema Gestaltungsfreiheit wird immer wieder der Vorbehalt geäußert, ein CSS-Framework würde durch vorgegebenen Aufbau und festgelegter Benennung von Klassen und IDs die individuelle Umsetzung einer Website unnötig einschränken. Dazu sei nur bemerkt, dass der CSS Zen Garden trotz festgelegter HTML-Struktur der Vorlage die Webdesigner offensichtlich nicht davon abgehalten hat, zahllose individuelle Lösungen zu entwickeln.
Die Praxis der individuellen Handcodierung einer Website bedeutet deshalb nicht, dass der Entwickler aus dem Nichts heraus beginnt, eine Struktur zu erfinden. Der Webentwickler ist eben nicht der Künstler, der von der Muse geküsst wird und dank seiner Kreativität und Schöpferkraft dem Web ein neues Meisterwerk schenkt. Webentwicklung ist ein Handwerk und jeder Entwickler greift auf bewährte Werkzeuge (Codeschnipsel) zurück, auch der per Hand codierende. Und selbst wenn ein Entwickler schwören könnte, keine vorgefertigten Zeilen HTML- oder CSS-Code per copy & paste zu verwenden, ist es eben sein Fachwissen, das bei der Handcodierung den Prinzipien eines bestimmten Systems folgt. Unzählige bewährte Codeschnipsel hat der Webdesign-Profi in seinem Kopf, so wie der Architekt unzählige bewährte Varianten für die Planung eines Hauses kennt. Und CSS-Frameworks sind grundsätzlich nichts anderes als eine Sammlung erprobter, praxisorientierter Codeschnipsel, die reibungslos zusammenarbeiten und sich einem übergeordneten Konzept unterordnen.
Zusammen mit dem Argument von zu viel Markup und zu vielen CSS-Regeln wird oft die angeblich schlechte Qualität des Codes ins Feld der Kritik geführt. Hier ist es jedoch wichtig, auf die grundsätzlich unterschiedlichen Ansätze verschiedener Framework-Konzepte hinzuweisen. In der allgemeinen Wahrnehmung verstehen die meisten Webdesigner unter dem Begriff «CSS-Framework» nicht nur YAML, sondern daneben auch YUI Grids, Blueprint CSS, 960 Grid System und entsprechender Derivate der beiden letztgenannten. Dabei wird schnell übersehen, dass im Vergleich zu YAML dem schlanken YUI Grids beispielsweise die umfangreichen IE-Patches, der Formularbaukasten und eine ausführliche Dokumentation fehlen und dass Blueprint CSS, bzw. 960.gs die Gestaltung in klassischen Spaltenrastern zur konzeptionellen Grundlage des gesamten Frameworks gemacht haben und damit dem rein visuell orientierten Tabellenlayout näher stehen als dem Konzept der Webstandards. Als Framework in der Praxis ist YUI Grids deshalb gelegentlich etwas dünnhäutig bei komplexen Aufgabenstellungen, während die visuell orientierten Frameworks durch das detailliert ausgearbeitete Spaltenkonzept an vielen Stellen die klare Trennung von Inhalt und Design vermissen lassen, was zurecht Anlass zur Kritik gibt.
Über pragmatische Lösungsansätze und Minimierung von Quellcodes
Professionelle CSS-Frameworks können nicht dem Anspruch gerecht werden, immer das absolute Minimum an Code zu liefern. Naturgemäß kann ein solcher Extremwert nur für jeweils genau einen speziellen Anwendungsfall erreicht werden und bedingt zwingend die Einbeziehung der Seiteninhalte. Das Ziel eines guten CSS-Frameworks besteht vielmehr darin, mit einem relativen Minimum an Markup und CSS-Regeln Bausteine mit einem größtmöglichen Potential zur Wiederverwendbarkeit zu entwickeln und darauf aufbauend inhaltsunabhängig ein robustes und effizient einsetzbares Layoutgerüst bereitzustellen.
Die Differenz zwischen dem absoluten Minimum an Code einer perfekten Individuallösung und dem relativen Minimum des Framework-Codes ist naturgemäß keine konstante Größe, sondern abhängig von verschiedenen Einflussfaktoren:
- Je besser die Planung für die Umsetzung eines Layouts die Funktionsprinzipien des verwendeten Frameworks berücksichtigt, desto geringer ist der entstehende Overhead und desto schneller und einfacher ist auch die Realisierung.
- HTML und CSS bieten fast immer mehrere Lösungswege für eine Aufgabe und Handcodierung ist kein Garant dafür, auf Anhieb die Ideallösung zu finden und fehlerfrei zu implementieren, hierfür zählt allein Fachwissen.
- Das absolute Minimum ist ein theoretischer Wert. In der Realität bedingen CSS-Bugs und variierende CSS-Fähigkeiten verschiedener Browsergenerationen immer wieder Kompromisse im Markup und bei der Formulierung von CSS-Regeln.
- CSS-Frameworks sind Werkzeuge zur Layoutentwicklung. Erst in den Händen des Entwicklers entsteht damit das fertige Layout, eben weil erst mit Kenntnis der Randbedingungen des konkreten Projektes eine Optimierung sinnvoll möglich ist. Demzufolge ist ein gewisser Overhead auf der Seite des Frameworks unerlässlich, um diese Vielseitigkeit zu ermöglichen.
CSS-Frameworks liefern daher keine Maßanzüge, sondern Kompromisslösungen – und das aus gutem Grund. YAML hat nicht den Anspruch, out-of-the-box die bestmögliche (im Sinne: Maßanzug = absolutes Minimum an Code) zu liefern. Stattdessen nehme ich für YAML in Anspruch, die bestmögliche Codebasis (im Sinne von Effizienz und Vielseitigkeit) für den Entwickler bereitzustellen. Das Basismarkup von YAML, die flexiblen Gridbausteine (Subtemplates) sowie die drei CSS-Core-Stylesheets (base.css, iehacks.css und print_base.css) sind robuste, wiederverwendbare Bausteine, die ihrerseits ein Optimierungsprozess in der Frameworkentwicklung durchlaufen haben und speziell im Bereich der flexiblen Layouts ist diese Codebasis trotz ihrer Vielseitigkeit extrem schlank.
Das immer wieder vorgebrachte Argument des Übermaßes an Markup und Regeln wird natürlich auch nicht dadurch gelöst, indem man einen leeren Ordner für Inhalte anlegt und lediglich ein Reset-CSS und ein paar Zeilen Basis-CSS als Grundlage zur Codierung anbietet und das dann «Framework» nennt. Das ist zwar schlank, bringt aber außer ein paar Minuten Zeitersparnis keine Entlastung in der Praxis der Webentwicklung.
Frameworks dienen der Webentwicklung, nicht der Philosophie
Noch ein Blick in die Praxis: Das gewünschte Minimum an Code ist auch in der von Hand codierten Form im Projekt-Workflow nur dem äußerst seltenen Idealfall vorbehalten, dass der Auftraggeber dem Entwickler von der Planung bis zum Launch völlig freie Hand gibt und nicht die geringsten Änderungswünsche formuliert. Die Realität der Frontend-Entwicklung sieht jedoch anders aus. Nicht selten werden noch nach Abnahme und Launch der Website von Kunden oder Entscheidern umfassende Änderungen gewünscht, die oft auch zusätzliches Markup bedeuten. Das Minimum kann also frühestens am Ende des Projektablaufs stehen, und auch da nur als best-case-Variante.
Nicht nur Jens Meiert verfehlt daher in seiner Argumentation gänzlich den Sinn und Zweck eines CSS-Frameworks, denn er stellt eine theoretisch hochoptimierte Individuallösung dem out of the box Ergebnis eines CSS-Frameworks gegenüber, um mit dem zwangsläufig vorhandenen Overhead gegen CSS-Frameworks argumentieren zu können. Bei dieser Argumentation wird erstens vergessen, dass gerade Profis mit hinreichendem Fachwissen auch das projektbezogene Grundgerüst eines Frameworks optimieren können und sollten. Zweitens liegen die Vorteile der Arbeit mit einem CSS-Framework nicht im Bereich der finalen Codeoptimierung, sondern in den davor gelagerten Entwicklungsphasen, die nicht nur durch die beschriebene Abstimmung mit dem Auftraggeber zahlreiche Änderungen erfahren können. Die zunehmende Komplexität anspruchsvoller Großprojekte mit der Arbeit in Teams und heterogenen Entscheidergruppen lässt eine auf Anhieb optimierte und finalisierte Codierung überhaupt nicht zu. Hier bietet das Konzept von YAML eine praxisnahe Lösung: für alle gängigen Browser robust, für komplexe Anforderungen in der Webentwicklung umfassend und für die Untiefen in der Kundenabstimmung flexibel. Dass beim eben vergebenen BIENE-Award für besonders zugängliche Webseiten insgesamt sechs Gewinner-Websites mit YAML umgesetzt wurden, zeigt, was dieses Framework in der professionellen Praxis leisten kann.
Zukunftssicheres und wartbares CSS
Auch im Bereich von CSS gibt es viele unterschiedliche Meinungen, was die Aufsplittung von Stylesheets in Module, den Einsatz von Hacks zur Zähmung des Internet Explorers oder auch der Verwendung von Conditional Comments betrifft. YAML macht von all diesen Dingen intensiven Gebrauch und muss sich demnach natürlich auch der Kritik stellen.
Conditional Comments & Hacks
Bezüglich Conditional Comments zitiere ich Jens Meiert einleitend, denn er vertritt in Bezug auf Conditional Comments und Reset-CSS eine sehr kompromisslose Ansicht.
"The core problem with Conditional Comments is its impact on maintainability. By their very definition you have to link at least one additional style sheet from your HTML, unless, even worse, CSS rules are added within the document. And just as we avoid using font elements as they are presentational and usually mean HTML changes once we want to change the layout (which means a maintenance problem), we should avoid Conditional Comments as once we want to change (or even keep) the layout when a new version of Internet Explorer ships or an old version goes, we face a good likelihood to change the HTML, which translates to an unnecessary maintenance issue as well. [...]
There are implications for collaboration as well, and you can observe these problems in practice: Since CC style sheets don’t necessarily use different selectors than the “regular” style sheets, developers either have to look for the same selector in at least two style sheets, which slows them down (even or especially in comparison to “hacks” which are usually close to all other rules), or they overlook them, implement another solution, eventually run into “weird” layout problems (because the CC style sheet overrides something or says something different), and maybe even add code that is unnecessary."
To Be Clear (on Conditional Comments and Resets), Jens Meiert
Conditional Comments fallen zwar in der Tat etwas aus der Rolle, denn es handelt sich um eine proprietäre Erweiterung von Microsoft und sie verhalten demzufolge auch sich nicht ganz so, wie es einfache HTML-Kommentare tun sollten. Doch ein Problem ergibt sich daraus nicht. Gleiches trifft nämlich auch auf das nicht weniger eigentümliche Verständnis des Internet Explorers bezüglich vieler CSS-Eigenschaften zu, die entweder falsch (CSS-Bugs) oder gar nicht interpretiert werden. Zwar sind CSS-Bugs kein Alleinstellungsmerkmal des Internet Explorers, jedoch beansprucht Microsoft seit vielen Jahren die Marktführerschaft. Nun lassen sich aber all diese Darstellungsprobleme des Internet Explorers mehr oder weniger einfach beheben, sei es durch Vermeidung bestimmter Markup/CSS-Konstellationen oder durch CSS-Hacks.
Eine Frage der Praxis: Wohin mit den Hacks?
Für die Hacks gibt es zwei Wege: Entweder –
wie Jens Meiert empfiehlt – verzichtet man auf den Einsatz von CCs und verwaltet sämtliche Bugfixes in den regulären Stylesheets. Für die skizzierte Suche nach bestimmten CSS-Regeln im Wartungsfall mag dieses Vorgehen vorteilhaft sein. Das hat aber leider den Nachteil, dass wir sämtlichen modernen Browsern diesen nutzlosen CSS-Ballast der Bugfixes aufbürden und somit die Ladezeiten in Firefox, Safari & Co. unnötig verlängern. Zudem benötigen viele Bugfixes Parser-Hacks, um einzelne IE-Versionen direkt ansprechen zu können. Doch genau diese meist invaliden und schwer lesbaren Konstrukte werden nicht zwingend von anderen Browsern ignoriert, was diesen Weg nicht weniger problematisch in Bezug auf "weird layout problems" macht.
Oder man trennt Standard-CSS und die IE-Anpassungen sauber voneinander, fasst sämtliche CSS-Hacks in einem gesonderten Stylesheet zusammen und bindet dieses über einen Conditional Comment ins Layout ein. Die Vorteile dieses Weges klingen überzeugend und wiegen den möglichen Nachteil eines leicht erhöhten Pflegeaufwands mehr als auf.
Vorteile Conditional Comments
- Das Standard-CSS bleibt frei von kryptischen Parser-Hacks zur Korrektur von IE-Bugs.
- Die Bugfixes für den Internet Explorer können nicht versehentlich die Darstellung modernen Browsern stören.
- Der Umfang der CSS-Anpassungen für den Internet Explorer hält sich zumeist in übersichtlichen Grenzen. Ein solches Stylesheet bleibt daher meist übersichtlich klein.
- Die Webseite gewinnt an Performance in modernen Browsern, da Bugfixes für den Internet Explorer auch nur diesem zugänglich gemacht werden.
Soweit der allgemeine Teil zum sinnvollen Umgang mit Conditional Comments. Innerhalb von YAML ist es zudem möglich, Bugfixes für den überwiegenden Teil der CSS-Bugs Internet Explorers so universell zu formulieren, dass sie ohne Zutun des Entwicklers greifen und deshalb präventiv eingesetzt werden können, dank der vom CSS-Framework vorgegebenen Struktur des Markups. Dieses Konzept, das bisher ausschließlich in YAML umgesetzt wurde, führt zu einerseits zu geringfügigem CSS-Overhead, bringt aber im Gegenzug nachhaltige Vorteile mit sich.
Conditional Comments in YAML
- Entwickler können sich bei der Layoutentwicklung auf standardkonforme Browser konzentrieren, der überwiegende Teil der Anpassungen für IE 5.x - 7.0 erfolgt automatisch durch YAML. Der Korrekturaufwand für Darstellungsprobleme des Layouts, von Formularen und sonstigen Inhalten sinkt drastisch.
- Auftraggeber müssen keine Einschränkungen in der Browserunterstützung hinnehmen, denn das CSS-Framework liefert die Unterstützung älterer IE-Versionen frei Haus.
- Endanwender werden hinsichtlich des gewählten oder gezwungenermaßen verwendeten Browsers weniger bevormundet aufgrund der weitreichenden Browserunterstützung des CSS-Frameworks.
Und letztlich, sollte der Internet Explorer 8 vollständig standardkonform rendern und die älteren IE-Versionen verdrängen, so beschränkt sich der Wartungsaufwand zur Deaktivierung der Unterstützung dieser veralteten Browser für den Webentwickler auf das einfache Löschen eines Stylesheets auf dem Server, bzw. die Entfernung dieses speziellen HTML-Kommentars aus dem Layout. Wer daher Conditional Comments allein aufgrund ihrer proprietären Herkunft oder einem willkürlich heraufbeschworenen Wartungsproblem ablehnt, muss sich die Frage nach einer vergleichbar effektiven Alternative zu dem in YAML umgesetzten Bugfix-Konzept gefallen lassen, welche die genannten Vorteile für Entwickler, Auftraggeber und Endanwender gleichermaßen abdeckt.
Modulare Stylesheets vs. Performance
CSS-Frameworks sind Entwicklerwerkzeuge mit einem modularen Aufbau. Sie beinhalten eine Vielzahl an wiederverwendbaren Bausteinen (Reset-CSS, Screenlayout, Navigationselemente, Druckausgabe, ect.), die in Abhängigkeit der jeweiligen Anforderungen in das CSS-Layout integriert und ggf. angepasst werden. Die Möglichkeit der Wiederverwendung ist dabei entscheidend für die Beschleunigung des Entwurfsprozesses. Gleichzeitig wird durch die Verwendung erprobter Bausteine der Pflege- und Testaufwand auf ein notwendiges Minimum zu reduziert. Im Gegensatz zur Layoutentwicklung verlangt der Produktivbetrieb der Webseite in erster Linie nach Geschwindigkeit. Jeder CSS-Baustein muss einzeln per HTTP-Request beim Server angefordert werden. Jeder Request bedingt Latenzzeiten und verlangsamt somit die Darstellung der Webseite. Im Produktivbetrieb ist es daher sinnvoll, die Anzahl der einzelnen Stylesheets durch Zusammenfassen so weit wie möglich zu reduzieren. Ähnliche Vorgehensweisen wendet man bei Grafiken an, Stichwort: CSS-Sprites. Dennoch handelt es sich hier um zwei gänzlich von einander unabhängige Phasen der Projektentwicklung, die in der Diskussion nicht willkürlich miteinander vermischt werden sollten.
Das CSS einer Webseite wird erst im User Client interpretiert und muss dazu zunächst vom Server heruntergeladen werden. Performance im Produktivbetrieb verlangt deshalb nach möglichst kleinen Dateigrößen für kurze Ladezeiten. Erreicht wird dieses Ziel durch die Komprimierung von Stylesheets mit Werkzeugen wie dem YUI Compressor oder dem PHP-Tools wie minify. Dabei werden CSS-Kommentare und unnötige White-Spaces (Leerzeichen, Tabulatoren, Zeilenumbrüche) aus den Stylesheets entfernt, um die Dateigröße zu reduzieren. Ebenso ist es jedoch nachvollziehbar, dass sich in einer derart komprimierten Form nicht vernünftig entwickeln lässt. Wer sein Layout von Hand codiert, wird gleichermaßen darauf achten, CSS-Regeln lesbar und übersichtlich zu halten und wird einzelne Passagen kommentieren, um die Wartbarkeit des Codes und das Nachvollziehen von Designentscheidungen für andere Teammitglieder zu dokumentieren. Die Wartbarkeit und Pflege komplexer Projekte lässt eine Unterteilung von Stylesheets in logische Teile ebenfalls sinnvoll erscheinen.
Bei der Entwicklung eines CSS-Frameworks ist es nicht viel anders. Das Framework stellt für den Anwender zunächst eine fremde Codebasis dar, die verstanden sein will, um Vertrauen in den Code zu gewinnen und um effektiv damit arbeiten zu können. Aus diesem Grund sind die CSS-Bausteine bei YAML auf Basis von CSSDOC sehr ausführlich dokumentiert und die modulare Aufteilung der Stylesheets in aufgabenspezifische CSS-Bausteine wird konsequent verfolgt. Das Kommentieren von CSS, die bedeutungsvolle Benennung von Layoutelementen, Dateien und Ordnern ist eine Grundvoraussetzung für professionelle Webentwicklung und kann somit nicht exklusiv für die Handcodierung oder den Einsatz von CSS-Frameworks gelten. In beiden Fällen unterliegt der Entwicklungsprozess anderen Kriterien als der Livebetrieb der fertigen Website. Der modulare Aufbau der Stylesheets während der Layoutentwicklung ist daher kein Argument gegen CSS-Frameworks. Unabhängig von Handcodierung oder Framework-Einsatz ist die Entscheidung hinsichtlich einer Performanceoptimierung der Stylesheets für den Livebetrieb ein Zeichen dafür, ob man sich einer professionellen Arbeitsweise stellt oder nicht.
Liefern Frameworks unsemantischen Code?
Ein ausgesprochen leidiges Diskussionsthema betrifft den immer wieder zu hörenden Vorwurf, CSS-Frameworks würden unsemantischen Code produzieren oder gar unsemantische Klassennamen verwenden.
"A CSS framework passively removes a great majority of semantic value from the markup of a document and, in my opinion, should be avoided."
Please Do Not Use CSS Frameworks, Jonathan Christopher
Diese Aussagen sind ganz und gar Unfug. CSS-Layouts basieren typischerweise auf DIV-Elementen. Und diese Elemente haben in der Tat per Definition keine festgelegte semantische Bedeutung. Es sind strukturgebende Elemente, die uns erlauben, Inhalte sinnvoll innerhalb eines HTML-Dokumentes zu gliedern (Header, Navigation, Content, Footer, ect.) und mit CSS inhaltsunabhängig zu gestalten. Jetzt gibt es natürlich durchaus unterschiedliche Ansichten, wie und in welchem Umfang mit DIV-Elementen umgegangen werden soll. Doch diese Fragestellung hat wiederum nichts mit Semantik zu tun, sondern ist dem persönlichen Geschmack, bzw. dem zuvor diskutierten Thema um möglichst schlanken Code zuzuordnen.
Dann wären da noch bösen unsemantischen IDs und Klassennamen in vielen CSS-Frameworks. Das ist schlicht und ergreifend Unsinn. Klassen- und ID-Bezeichnungen fügen einer Webseite weder irgendeine semantische Information hinzu, noch geht den Seiteninhalten Semantik verloren, wenn der Quelltext mit Klassennamen eines CSS-Frameworks angereichert wird. Klassen- und ID-Bezeichnungen dienen der Zuordnung von CSS-Selektoren zu HTML-Elementen, mehr nicht. Oder als Frage formuliert: Was ändert sich wohl an der Semantik eines deutschsprachigen Fachtextes, wenn das ihn umgebende CSS-Layout englische oder gar spanische Klassennamen verwendet? Natürlich sollten Klassennamen stets sinnvoll gewählt werden, um die Les- und Wartbarkeit des Quellcodes zu erleichtern. Doch man muss den bekannten CSS-Frameworks zweifelsfrei eine durchdachte Systematik bei der Namensvergabe bescheinigen.
Verständnisprobleme bei Entwicklern rühren eher daher, dass die verwendete Systematik der Benennung nicht den Geschmack eines jeden Webdesigners trifft. Reine Gridbasierte Frameworks (Blueprint CSS oder 960 Grid System) sind sehr stark visuell orientiert. Das äußert sich zum einen in einem, dem früheren Tabellenlayout ähnlichen Aufbau des Markups und eben auch in der Bezeichnung der CSS-Klassen, die sich am Gridraster orientiert. Die Kritik von Jens Grochtdreis und Adam Bard ist in der Tat angebracht, denn sie macht deutlich, wie wenig bei diesem Layoutansatz von der Trennung von Inhalt und Layout noch übrig geblieben ist und wie aufwändig Änderungen werden können. Doch dieser berechtigte Kritikpunkt bezieht sich konkret auf den Layoutansatz von Blueprint CSS und dessen zahlreicher Clones und Modifikationen. Bei YAML hingegen ist eine Vielzahl an Gestaltungsmöglichkeiten vollständig per CSS realisierbar, ohne dass das Basismarkup verändert werden muss. Das Layoutkonzept von YAML ist deshalb gerade in Verbindung mit Content-Management-Systemen effektiv, denn die Templateerstellung ist üblicherweise relativ aufwändig. Weitreichende Gestaltungsmöglichkeiten eines solchen Templates per CSS ermöglichen auch hier eine Wiederverwendung.
Nur für Anfänger oder fehlender Lerneffekt?
Zum Abschluss noch zwei weitere typische Argumente aus der Diskussion contra CSS-Frameworks: So seien Frameworks in erster Linie für Einsteiger sinnvoll, während Profis keine derartigen Hilfen bräuchten. Sicherlich ist es für Einsteiger eine geringere Hürde, die Anwendung eines Frameworks zu erlernen, als echtes Fachwissen über CSS aufzubauen.
“A big problem with frameworks is when up and coming developers attach themselves to a framework as opposed to the underlying code itself. The knowledge gained in this case surrounds a specific framework, which severely limits the developer.”
Please Do Not Use CSS Frameworks, Jonathan Christopher
Doch wie weit kommt denn ein Einsteiger ohne Fachwissen wirklich? Kein Framework dieser Welt nimmt seinem Nutzer die Eigenverantwortung ab, individuelle Layoutelemente fehlerfrei zu positionieren und Inhalte semantisch korrekt auszuzeichnen. Wer Qualität will, kommt um Fachwissen nicht umhin. In jedem Fall bleibt der Lerneffekt also erhalten. Erspart bleibt dem Einsteiger lediglich der Frust, den Webentwickler jeder Qualifikation erleben, wenn sie sich der nicht ganz so standardkonformen Browserrealität stellen.
Für professionelle Entwickler dürfte wohl kaum ein nachhaltiger Lerneffekt aus der alltäglichen Anwendung von HTML & CSS zur Layout erwachsen, denn sie sollten dieses Fachwissen bereits besitzen. Wie einleitend erwähnt wurde, verlangt jedoch auch die Nutzung eines CSS-Frameworks eine gewisse Lernbereitschaft, um damit effizient arbeiten zu können. Und speziell im professionellen Bereich wirkt sich das zeitliche Einsparpotential erst richtig aus, denn die Einsparungen multiplizieren sich mit der Anzahl der Projekte. Die eingesparte Zeit lässt sich indes hervorragend zur Weiterbildung in Sachen HTML 5, WCAG 2.0 oder WAI-ARIA nutzen.
Im Gegensatz dazu ist es durchaus nachvollziehbar wenn Hobbybastler vorrangig den Spaß an der Freude schätzen und sich deshalb bewusst für die Handcodierung entscheiden, denn Effizienz ist in diesem Fall wahrscheinlich weder maßgebend noch erwünscht.
Fazit
Auffällig ist die Tatsache, dass massive Kritik an CSS-Frameworks, bzw. an YAML, von Profis kommt, die selbst offensichtlich noch nie mit YAML gearbeitet haben. Man kann darüber spekulieren, ob neben dem grundsätzlich verständlichen Misstrauen vor allem die Furcht vor fehlender Kontrolle über eine Instant-Lösung von dritter Seite eine große Rolle spielt. Man wird das Gefühl nicht los, als ob die Kritiker Angst hätten, dem für sie fremden Konzept ausgeliefert und in ihrer Arbeitsweise eingeschränkt zu sein, was jedoch bei hinreichender Fachkompetenz nicht der Fall ist. Jeff Croft bemerkte das schon vor einer ganzen Weile. Es stimmt, man muss sich auf das Konzept von YAML einlassen, und man muss Zeit investieren, um den Aufbau des Frameworks zu verstehen. Aber das gilt ebenso für jedes CMS, das ebenfalls nach eigenen Regeln funktioniert und erst nach weitaus längerer Einarbeitungszeit beherrscht werden kann als ein CSS-Framework. Die Argumentation "Ich will nicht" wäre deshalb eine ehrliche und völlig legitime Aussage, mit der ich als Entwickler von YAML gut leben kann. Eine solche, zutiefst persönliche Entscheidung für eine individuelle Arbeitsweise, bedeutet im Umkehrschluss jedoch nicht, dass CSS-Frameworks obsolet sind oder mit der eigenen Codequalität nicht konkurrieren könnten.
Es ist unbestritten, dass die aktuelle Vielzahl an Projekten und deren stark variierender Funktionsumfang, sowie die verschiedenen Layoutansätze eine qualitative Einschätzung ohne tiefgründige Recherchen fast unmöglich manchen. Zudem heften sich zahlreiche Projekte das offensichtliche Buzzword «Framework» gern ans Revers auf der Suche nach etwas Ruhm in Netz, scheitern bei genauerer Betrachtung jedoch den Ansprüchen, die an derartige Hilfsmittel für Webentwickler gestellt werden. Und nur aus diesem Grund ist Pauschalkritik momentan noch so einfach, wenn auch nicht gerechtfertigt. Denn einzelne Trittbrettfahrer schmälern langfristig nicht die zahlreichen Vorzüge, die aus der Arbeit mit CSS-Frameworks erwachsen können. YAML und auch YUI Grids lassen heute bereits erahnen, wohin die Reise für Webentwickler in den nächsten Jahren gehen wird.
Informationen
Dieses Essay entstand in enger Zusammenarbeit von Dirk Jesse und Nils Pooker. Die wie immer hervorragende englische Übersetzung lieferte Genevieve Cory.
Montag, 23.03.09 (14:35 Uhr)
Vielen Dank für diesen ausführlichen Artikel. Er ist gut geschrieben und fasst die (von den Kritikern selbst herbeigeführte) Problematik im Umgang mit CSS-Frameworks sehr gut zusammen.
Ich stimme euch zu, dass eine Entscheidung eines Webentwicklers gegen YAML und co. nicht gleichbedeutend mit der Aussage ist (bzw. sein sollten), dass CSS-Frameworks im Allgemeinen nicht einsatzfähig sind. Einigen schmeckt Tee besser als Kaffee. Einige mögen ihren Kaffee gern pur, die anderen mit Zucker, die anderen mit Milch und noch andere lieber mit Milch und Zucker.
Ich fördere gern den Einsatz von CSS-Frameworks u.a. auch in Technikwürze, wenn oben YAML drüber steht und ich weiß, was für ein „Meisterwerk“ dahinter steckt. Für viele professionelle Webentwickler ist YAML auch sicher eine Arbeitserleichterung. Doch ich sehe meinen Job in Bezug auf HTML und CSS eher darin zu entwickeln (im Beispiel der YAML-Entwickler Dirk; der Stippenzieher), statt zuzuarbeiten (der YAML-Endnutzer, der eine Basis erweitert). Wer jetzt schneller am Ziel ankommt ist mir echt Schnurz. Wichtig ist mir nur, dass mir mein Job Spaß macht. Und dazu gehört es eben auch, auf „Datei neu“ zu klicken.
Montag, 23.03.09 (23:45 Uhr)
Hi,
ein sehr schöner Artikel, gut geschrieben!
Ich kann nur sagen, dass ich inzwischen YAML sehr gerne nutze. Obwohl ich mich schon seit fast 10 Jahren mit HTML, CSS & Co. beschäftige und deshalb auch ohne YAML in der Lage war, Browser-Bugs abzufangen und browserübergreifende Layouts zu erstellen, bringt YAML für mich trotzdem eine enorme Arbeitserleichterung. Gleichzeitig bedeutet es aber keine Einschränkung. Bis jetzt konnte ich jedes gewünschte Layout mit YAML umsetzen.
Deshalb: mein Lob und meine Hochachtung vor Dirk Jesses Arbeit! Ich werde die weitere Entwicklung gespannt verfolgen! :)
Dienstag, 24.03.09 (00:26 Uhr)
find ich auch (größtenteils).
man merkt dass du einen hintergund als bauingenieur hast, dementspechend praxisnah ist dein professioneller anspruch. für viele “fertighauslösungen” ist yaml auch genau das richtige - hohe qualität und sehr pragmatisch. die codebasis ist soweit ich das beurteilen kann exzellent, und man kann extrem schnell sehr webstandardkonforme seiten erstellen. eben genau richtig für menschen die webdesign als ihr tagesgeschäft verstehen und mit möglichst geringem aufwand erstklassige arbeit machen wollen. aber das geht oft auch mit vorgefertigten und erprobten templates die man nur geringfügig an etwaige layouts anpasst. das ist auch eher die spielwiese von yaml finde ich.
ich glaube auch, dass viele webdesigner inklusive mir fame-whores sind, die sich niemals auf dem code anderer ausruhen würden, und das web auch als künstlerisch-experimentelles medium sehen, das es zu erforschen gilt - und zwar nicht nur präsentationsseitig. ich nutze jedes projekt um neue dinge für die zukunft dazu zu lernen, yaml hört sich für mich stark deutsch, gegenwarts- und praxisorientiert an. eine frage die ich mir z.b. stelle ist: warum muss jede seite in jedem browser möglichst gleich gerendert werden? - ist das nicht auch eine denkweise die aus analogzeiten kommt?
schwierig.
korbinian
Dienstag, 24.03.09 (00:52 Uhr)
Vielen Dank für diese Zusammenfassung !
Ich habe beim WordCamp Jena schon der Session beigewohnt und da ist dieser Artikel eine gute Erweiterung und Erinnerung. Gerade das Argument der zu großen Dateien kann ich absolut nachvollziehen, da es immer heißt “Wir haben soviel CSS, soviel JS ...” dabei merkt niemand dass man von den größten 100 Portalen noch am wenigsten hat.
Seit ich mich mit YAML beschäftige ist der IE wesentlich erträglicher geworden :-)
Grüße aus der Eifel,
Dominik
Dienstag, 24.03.09 (16:55 Uhr)
Ich habe mit YAML vor einiger experimentiert und finde das Konzept dieses Frameworks äußerst sympathisch. Zumal ich nach einer relativ geringen Zeit der Einarbeitung eine standardkonforme Website erstellen konnte. Und mal ehrlich ob Profi oder Anfänger, wichtig ist was hinten rauskommt. Und wenn man dabei noch Zeit spart um ein gutes Produkt abliefern zu können, ist das für mich Grund genug dieses Konzept zu akzeptieren und in meinen Arbeitsalltag zu integrieren.
Dienstag, 24.03.09 (20:31 Uhr)
Absolut richtig. Ich habe schon Seiten von “Profis” gesehen, da sollte man sich den Code lieber nicht genauer anschauen.
Ebenso gibt es “Amateure”, die absolut professionelle Arbeit abliefern. Es gibt extreme in beide Richtungen.
Mittwoch, 25.03.09 (19:09 Uhr)
Ich möchte zunächst Jens für seinen enormen Engagement bei der Entwicklung von YAML herzlich danken. Für mich wiegen die Vorteile von YAML weit mehr als seine Nachteile.
Ich denke allerdings, dass YAML eine weit grössere Akzeptanz hätte, wäre der Einstieg darin nicht so beschwerlich. Die Popularität mancher anderen Frameworks lässt sich m.E. damit erklären, dass sie eben leicht durchschau- und lernbar sind.
Für mich stellt sich also die Frage, wie YAML als Konzept so erweitert/modifiziert werden könnte, dass er Komplexität versteckt, anstatt Komplexität sichtbar macht. Der YAML-Builder ist möglicherweise ein Schritt in die richtige Richtung, ich bin mir diesbezüglich aber nicht sicher. Denkbar wäre auch eine Art allgemeine Layout-Grammatik (eine Layout Beschreibungssprache, so etwas wie ein eigenständiges YAML Markup), welche wie eine Skriptsprache den entsprechenden HTML/CSS code erzeugt. Ich hatte neulich einen Entwickler entdeckt, der an so was arbeitet, er hat aber erst damit angefangen.
Der zweite Punkt hat mit der Dokumentation bzw. mit dem YAML-Buch zu tun. Ich habe viel Verständnis dafür, wenn Autoren Ihr Können und Wissen demonstrieren wollen. Leider wirkt sich dieses sehr menschliche Streben auf die Qualität und Transparenz des Buchs aus bzw. wirft es ein schiefes Licht auf das Tool selbst. Ich denke hier wäre wirklich sinnvoll und angebracht, ... über die Bücher zu gehen und sich gründlich zu überlegen, wie man YAML einem breiteren Publikum zugänglich machen könnte. Damit meine ich nicht meine Grossmutter, sondern eben die unzähligen Web-Developers, die von diesem Tool wirklich profitieren könnten, würde man Ihnen den Einstieg erleichtern. Persönlich bin ich überzeugt, dass in diesem Bereich einiges getan werden könnte.
Gruss,
FF
Mittwoch, 25.03.09 (20:01 Uhr)
Deine Argumente für ein gesondertes IE-Stylesheet überzeugen mich nicht: Die Performance-Einbußen für andere Browser beschränken sich dank Gzip auf wenige Bytes, die IE-Hacks sind gut dokumentiert und stören andere Browser nicht, wenn man weiß, was man tut.
Die Übersicht geht gerade bei der Aufteilung flöten, nicht bei der Bündelung in einer Datei. Das ist zumindest meine Erfahrung mit beiden Varianten.
Den Vorwurf, auf Blähcode zu basieren, haben sich nahezu alle CSS-Frameworks selbst eingehandelt. Auch in YAML sind die Beispieldokumente klassische DIV-Suppen, die natürlich den ersten Eindruck entscheidend prägen, weil ich als Entwickler erstmal vermute, daß ich das alles selbst wieder herausoperieren muß.
Vielleicht wäre ein Beispiel ohne DIV überzeugender als zwanzig Artikel?
Ich habe bisher noch kein CSS-Framework angefaßt, weil ich dafür einfach keinen Bedarf hatte und weil mir bis heute dunkel bleibt, wie denn eine Aktualisierung vor sich geht. Werden dann meine Anpassungen überschrieben, das Gelöschte wieder eingefügt? Die Dokumentation berührt diesen Punkt nur in einem Absatz, der eigentlich nichts erklärt.
Dennoch: Ein schöner Artikel, der mich zwar (noch) nicht überzeugt aber zum Reflektieren meiner eigenen Arbeitsweise angeregt hat.
Mittwoch, 25.03.09 (21:49 Uhr)
@Franco
vielen Dank für das sehr interessante Feedback . Die Komplexität ist sicherlich eine Hürde, wenn man Blueprint CSS oder YUI Grids als Gegenbeispiel heranzieht. Der Hauptunterschied zwischen YAML und diesen Systemen ist, dass man für deren Anwendung, keine CSS-Kenntnisse benötigt, denn das Layout wird ausschließlich über den Markup und die Klassenzuweisung erstellt. Bei YAML gehts ohne CSS nicht und Effektivität erreicht man erst mit einem gewissen CSS-Grundwissen. Ich zweifle allerdings daran, dass man auf dieses Grundmaß an Verständnis des Systems verzichten kann oder es vor dem Nutzer auf Dauer verstecken kann.
Der YAML Builder ist definitiv nicht nur ein Weg zur einfacheren Anwendung von YAML. Ich bin überzeugt davon, dass derartige Tools in Zukunft stark an Bedeutung gewinnen, denn auf Grundlage von Frameworks wie YAML lassen sich Layoutkonzepte problemlos automatisieren. Die derzeitigen Grenzen des YAML-Builders spiegeln lediglich meine zeitlichen Grenzen für die JS-Programmierung wieder, nicht die des Frameworks. Hier ist in Zukunft viel mehr möglich. Ebenfalls vorstellbar ist eine Metasprache, wie Du sie erwähnst. Die Idee ist alles andere als abwägig und ich denke, dass im Bereich der JS- und PHP-Frameworks dieser Weg zur Erstellung von Benutzeroberflächen bereits gegangen wird (oder man kurz davor ist). Somit ist etwas ähnliches auch für Webseitenlayouts vorstellbar.
In diesem Detail mag ich Dir nicht folgen, denn obgleich natürlich jeder seine eigene Sichtweise bezüglich guter Dokumentationen und Bücher hat, bin ich doch vom Ansatz und der Umsetzung meines Buches aufgrund der allgemeinen öffentlichen Wahrnehmung überzeugt. Ein praxisorientiertes YAML-Kochbuch fehlt in der Tat, jedoch war das nicht die Intention für mein eigenes Buch.
Bei der Online-Dokumentation besteht definitiv Verbesserungsbedarf. Vorschläge sind immer willkommen, Hilfe ebenso. Allerdings bedarf es dafür eines detailreicheren Feedbacks und weniger einer solch pauschalen Kritik, wenn ich diese ernst nehmen soll. Du bist gern eingeladen zu einer gemütlichen Plauderei am Telefon.
Nochmals, vielen Dank für dein Feedback und zum Schluss noch der kleine Hinweis: Nicht “Jens”, sondern “Dirk”. :-)
@Thomas
Die Argumente bezüglich CCs mögen Dich nicht überzeugen, jedoch sind Deine Argumente keine anderen als die von Jens Meiert, nur Du begründest sie schlechter. Performanceverlust groß oder klein - er ist da. Und deine Position wird nicht glaubwürdiger, wenn Du den Performanceverlust auf CSS-Seite einfach hinnimmst, beim HTML jedoch YAML pauschal als überladene DIV-Suppe bezeichnest.
YAML existiert bereits seit 3 1/2 Jahren und ist seit Version 1.0 auf flexible Layouts ausgelegt. Dass YAML bei einem fixen Einspalter etwas unterfordert ist, unterschreibe ich Dir gern. Bis auf ein Einziges, sind jedoch ALLE Layoutbeispiele bei YAML durchweg flexibel angelegt. Wenn Du flexible Layouts deutlich effektiver umsetzen kannst, dann wäre es an Dir, den Beweis dafür anzutreten, dass ich falsch liege. Ich bemühe mich seit YAML 1.0 um schlanken Code und bin von dem gewählten Ansatz überzeugt. Zudem bin ich durchaus in der Lage, die Effektivität von YAML an an zahlreichen Übungs- und Praxisbeispielen zu belegen.
Nunja, ich komme ehrlich gesagt auch nur leidlich mit TYPO3 klar, weil ich mich bisher mit der Dokumentation von TYPO3 nicht weiter befasst habe. Allerdings halte ich mich aufgrund dessen in der Argumentation bei TYPO3-Diskussionen etwas zurück. In der YAML-Doku steht dann doch etwas mehr zu dem Thema (Stichwort: Regel 4 und der Text daneben). Dazu existieren gerade einmal 32 Layoutbeispiele + ein vollständiges Beispielprojekt, welche die Umsetzung der von YAML propagierten Trennung von Framework- und Nutzer-CSS ganz praktisch verdeutlichen.
Freitag, 03.04.09 (10:54 Uhr)
Die Verwendung eines Frameworks ist und bleibt aus meiner Sicht Geschmackssache; das betrifft “echte” Programmier-Frameworks wie Layout-Frameworks gleichermaßen. An der Stelle gebe ich Dir sehr gern Recht - ein einfaches “ich will nicht” wäre ausreichend.
Dass die Diskussionen um Pro und Contra des Öfteren aus der Bahn geraten / entarten, liegt sicher auch an dem Vormachtanspruch der jeweiligen Entwickler. Stets dreht es sich um professionelle Entwicklung für absolute Profis oder gar - ich zitiere aus Deinem Beitrag - wohin die Reise für Webentwickler in den nächsten Jahren gehen wird.
Seltsam, dass es so viele Entwickler / Projektanten / Strategen gibt, die uns das seit Jahrzehnten immer wieder gebetsmühlenartig versprechen…
Aus dieser Perspektive erscheinen die langatmigen Argumentationen in Deinem Artikel genauso pauschal wie die ablehnende Haltung der entsprechenden Gegner.
Apropos Trittbrettfahrer: wieso benutzt Du für Deine Schöpfung dasselbe Akronym wie Yet Another Markup Language?
cx
Freitag, 03.04.09 (12:49 Uhr)
@Cortex
Ein Projekt braucht eine Zielgruppe, für CSS Frameworks im Allgemeinen und YAML im Speziellen sehe ich diese im Bereich der professionellen Webentwickler. Zwar können auch Hobbybastler und Laien von der Verwendung von Frameworks profitieren (weil sie zum Ziel kommen), aber erst mit einem Grundmaß an CSS-Kenntnissen lässt sich YAML richtig effektiv einsetzen. Ein Hobbybastler baut seine eigene Homepage, ein professioneller Entwickler mehrere Layouts pro Woche oder Monat. Es ist zudem nachvollziehbar, dass die positiven Effekte vor allem bei der mehrfachen Anwendung nachhaltig zum Tragen kommen. Ein solche Abgrenzung beschreibt daher keine “Vormachtstellung” sondern lediglich den Focus der Entwicklung. Es gibt genug Frameworkprojekte, die deutlich einfacher zu verstehen sind als YAML und demzufolge einsteigerfreundlicher sein mögen.
Fürs erste wäre es schön, wenn es wahr wäre und wirklich so viele Entwickler regelmäßig über den Tellerrand schauen würden. Zum zweiten schreibe ich lediglich meine Vorstellungen nieder, wo es mit YAML in Zukunft hingeht. Damit musst Du nicht übereinstimmen. Daher frage ich mich, was Du eigentlich sagen willst bzw. was Dich stört?
Für wahr, in Zeiten von Link- und Top-10-Listen Postings mag das Lesen längerer Beiträge ungewohnt anstrengend sein. Aber der Sinn und Zweck eines Essays ist eben, dass man sich darin die notwendige Zeit nehmen kann, Dinge zu diskutieren. Das magst Du persönlich langatmig finden, Pauschalität erwächst daraus jedoch nicht. Hier müsstest Du schon ins Detail gehen.
Darum: Yet Another Multicolumn Layout.
Freitag, 03.04.09 (13:41 Uhr)
Dirk, auf den ersten Teil deiner Antwort möchte ich nicht eingehen; es ist nachvollziehbar, dass Du so argumentierst. Dennoch möchte ich keine Diskussion über die Für und Wider von Frameworks, Einsatzszenarien und Zielgruppen führen; wir würden uns im Kreise drehen.
Meine Lesart des betreffenden Satzes ist anders - Du stellst einen Zusammenhang zwischen Deinem Framework und der prospektiven Entwicklung des “webcodings” her. Eine bescheidenere Interpretation als Vormachtstellung bleibt mir an dieser Stelle verwehrt. Diese Darstellungsweise ist - wie bereits angedeutet - kein Alleinstellungsmerkmal Deines Artikels.
Stosse Dich bitte nicht an möglicherweise “blumigen” oder polarisierenden Formulierungen… Dein Artikel als Diskussionsgrundlage kann dem Ideal einer nüchtern-wissenschaftlichen Darstellung (ebenfalls) nicht entsprechen .-
Diese Kausalität habe ich auch nicht hergestellt; der Bezug findet sich im vorherigen Absatz.
Das ist keine befriedigende Antwort, insofern man meine Anspielung nicht ignoriert.
cx
Freitag, 03.04.09 (15:51 Uhr)
@cortex
Dass flexible und robuste Frameworks einen Weg in die Zukunft der Webentwicklung weisen können, ist eine aus der Praxis begründete Annahme, siehe Essay.
Jene Annahme ist nun aber nicht automatisch mit dem Anspruch einer Vormachtstellung des eigenen Frameworks zu verwechseln, selbst wenn der Verfasser - wie hier - gleichzeitig Entwickler ist. Da muss man schon sorgfältig unterscheiden und aufpassen, was man schreibt.
Und egal, ob Du uns das unterstellst oder nur falsch verstanden hast: eine nüchtern-wissenschaftliche Abhandlung mit der Notwendigkeit größtmöglicher Objektivität war auch nie Anspruch dieses Essays.
Freitag, 03.04.09 (17:03 Uhr)
und
Nils, es sind Äusserungen wie diese, durch die Diskussion aus der Bahn geraten; ich hatte das in meinem ersten Kommentar angedeutet.
1. Ich achte schon darauf, was ich schreibe. Eine Ermahnung ist so unangebracht wie überflüssig.
2. Ich habe aus meiner Perspektive weder etwas unterstellt, noch falsch verstanden. Dass Du mir lediglich diese zwei Möglichkeiten zugestehst, ist imho symptomatisch für die Diskussionskultur in einigen deutschsprachigen Blogs.
Sorry für meine kritischen Äusserungen - Klappe halten oder Bravo rufen kam halt schon immer besser an.
In diesem Sinne,
cx
Freitag, 03.04.09 (17:44 Uhr)
@ cortex
Es ist doch leider so, dass gerade die Diskussionskultur vieler deutschsprachiger Blogs immer nur Mainstream ist, der entweder Bravo- oder Buh-Kommentare generiert. Von Klappe halten ist da eher keine Rede. Der Mainstream zum Thema Frameworks ist eben “Buh”.
Du hast geschrieben “Die Verwendung eines Frameworks ist und bleibt aus meiner Sicht Geschmackssache; das betrifft “echte” Programmier-Frameworks wie Layout-Frameworks gleichermaßen”. OK, das ist doch mal eine Aussage. Aber der anschließende Text mit “blumigen” Thesen erinnert an Adornos undurchdringlich-überkomplizierter Dialektik und kann ebenso wenig zum eigentlichen Thema beitragen wie die Aussage “Ich find’ Frameworks blöd, weil ich außerdem eh nicht damit arbeite”.
Also sei bitte nicht beleidigt, dass ich eben nicht die Klappe zu Deiner Meinung halte.
Freitag, 03.04.09 (17:53 Uhr)
akteptiert .-p
cx
Samstag, 04.04.09 (12:06 Uhr)
Gratulation an Euch beide. Sehr guter Artikel, der mich nun angeregt hat, mein nächstes Projekt nun doch mal mit YAML zu verwirklichen.
Was mir persönlich jedoch überhaupt nicht gefällt ist die durchmischung mit englischen Passagen. Nicht jeder beherrscht englisch fliessend und muss sich daher diese Passagen erst mühsam übersetzen, was den Lesefluss erheblich stört. Zudem mag es durchaus auch Leute geben, die gar kein englisch können, sich aber trotzdem für Webstandardkonformes Webdesign und CSS-Frameworks wie YAML brennend interessieren. Ohne die hervorragenden Artikel von Leuten wie Euch sind diese Menschen aufgeschmissen und werden aus dieser schönen Welt ausgeschlossen, was sehr schade ist und nicht gerade der Nachwuchsförderung dient… Somit ist ein solcher Artikel also nicht “Barrierefrei” ;-)
Ich bitte daher mal freundlich darum: macht Euch bitte die Mühe und übersetzt oder schreibt solche Artikel komplett auf deutsch, dann hat jedermann die Chance, von Eurem Wissen zu profitieren.
Samstag, 04.04.09 (12:32 Uhr)
Hallo,
danke erst einmal für diese überaus informative Essay. Für jemanden der bis jetzt noch nicht mit css frameworks gearbeitet hat, aber immer mal wieder Kommentare zu YAML oder auch YUI Grids gelesen hat, schließt das hier, meiner Meinung nach, essentielle Verständnislücken. Speziell auch die Kritik von Jonathan Christopher oder Jens Meiert wird sachlich zerlegt und es wird aufgezeigt aus welchem Hintergrund heraus die Kritik der beiden entstanden ist.
Zum Thema Performance. Verständlicherweise ist diese während der Entwicklungsphase des Projektes noch nicht optimal und eventuell auch hinterher nicht. Was dann aber nicht am Framework liegt, sondern an der nicht konsequenten Performance Optimierung der Dateien.
Jedenfalls, auch wenn nicht beabsichtigt, macht diese Essay Lust auf YAML, beziehungsweise endlich den Knick zu kriegen sich einzuarbeiten, wovor ich bis jetzt immer etwas Abstand gehalten habe. Was aber auch an der vielen Negativ Kritik gelegen hat.
Oliver
Donnerstag, 16.04.09 (20:41 Uhr)
Ich bin kein professioneller Webentwickler und habe auch nicht vor, einer zu werden. So kann ich mich auch nicht direkt an der Diskussion zu Pro und Kontra von CSS-Frameworks beteiligen. Gleichwohl fand ich den Beitrag und die bisherige Diskussion dazu sehr aufschlußreich. Wenn ich mich hier melde, dann weil ich soeben einen kleinen und bescheidenen Internetauftritt mit YAML erstellt habe. Das folgende ist zunächst als großer Dank an Dirk für seine Arbeit und dann als lediglich kurzer Erfahrungsbericht eines Einsteigers in die Webseitengestaltung zu verstehen. Ich hatte mich bis vor kurzem noch nicht richtig mit HTML und CSS beschäftigt, kam aber mit Erfahrungen von LaTeX her und einer gehörigen Portion Skepsis gegenüber automatisch erzeugtem Code. Ich
hatte mir zugetraut, mich soweit in HTML/CSS einzuarbeiten, um mir ein Layout zusammenzubasteln, das auf meinem Bildschirm so einigermaßen passabel aussieht. Eine Beschäftigung mit den Untiefen der Browservielfalt wäre für
mich aber aus Zeitgründen definitiv nicht infragegekommen. Allein darin, daß einem YAML diese Arbeit abnimmt, lag für mich von Anfang an ein Reiz an diesem Framework. Eingearbeitet habe ich mich durch die Lektüre der Dokumentation, durch Herumprobieren mit den vielen mitgelieferten Layout-Beispielen und mit SELFHTML. Ich habe YAML dabei durchaus nicht als einsteigerunfreundlich erlebt. Ohne weitere Vergleiche mit den alternativen CSS-Frameworks angestellt zu haben, möchte ich sagen, daß es sicher viel Komplexität in YAML gibt, daß diese aber nichts Einschüchterndes hat. Sie hat für mich eher dazu eingeladen, mir weitere Kenntnisse zu CSS anzueignen. So habe ich für meinen Teil durch YAML einiges über CSS gelernt und kann ich die Alternative “Framework vs. echtes Fachwissen über CSS” zumindest in einer strikten Formulierung nicht nachvollziehen. Der grundlegende Aufbau von YAML war für mich durchaus recht schnell zu verstehen, auch wenn es im einzelnen manche Zeile gibt, die mir bis jetzt noch nicht ganz transparent ist. Wenn es aber Profis, die wohl oft genug im Team arbeiten und mit fremdem Code arbeiten, als Argument gegen solche Frameworks bringen, daß man sich dort in fremden Code einarbeiten muß, dann finde ich das etwas befremdlich. Inwieweit die Kreativität durch so etwas wie YAML für einen Profi tatsächlich eingeschränkt wird, kann ich nicht beurteilen. Ich kann von meinen (sehr begrenzten) Erfahrungen her nur bestätigen, daß man auch als Anfänger schnell zu ahnen beginnt, daß mit YAML eine sehr hohe Flexibilität in der Layoutgestaltung möglich ist, auch wenn man selbst nur einen Bruchteil der Möglichkeiten ausreizt.
Wenn von Seiten der Profis so massive Kritik an CSS-Frameworks geübt wird, wie es im Fazit heißt, vermute ich darin weniger eine Angst vor der Fremdheit des Konzepts als vielmehr eine Angst davor, daß es nun auch Nicht-Profis möglich wird, Webseiten in einer Qualität zu erstellen, die bisher nur sie garantieren konnten. Das wäre eine vermutlich über weite Strecken unbegründete Angst vor einer Entwertung des eigenen und gut gehüteten Wissens. Wenn man es an der Kompetenz mißt, sind nun aber die Grenzen zwischen Laien und Profis im Bereich der Web-Gestaltung wie in vielen anderen
Bereichen fließend. Liegt nicht wenigstens ein Teil des Erfolgs von YAML gerade darin begründet, daß es eben beide Gruppen anzusprechen vermag? Mich wundert es ein bißchen, daß YAML in dem Beitrag dann doch recht entschieden als vorrangig für Profis bestimmt präsentiert wird. Ich verstehe schon, daß Dirk bei den Profis eine Lanze für YAML brechen möchte, aber sowohl die Dokumentation als auch das YAML-Buch lassen erkennen, daß es ihm sehr wohl auch um eine Popularisierung geht, die ihm übrigens auf sympathische Weise gelingt. Ich möchte damit ansprechen, daß es nicht nur professionelle Entwickler auf der einen Seite und Hobbybastler auf der anderen gibt, wie es im Artikel z.T. anklingt. Es gibt auch Leute dazwischen, die sich für die Codierung mit YAML nicht primär aus Spaß an der Freude entscheiden, sondern weil sie eine ordentliche Webseite brauchen und selbst erstellen möchten, also wohlüberlegt und mit Blick auf einen akzeptablen Einarbeitungs- und Zeitaufwand, auf Flexibilität, Standardgerechtheit und umfassende Browserunterstützung.
Ich wollte diese sehr subjektive Perspektive hier kurz einbringen, wie gesagt, um Dirk zu danken und ihn zu ermutigen, den breiten Ansatz von YAML weiter zu pflegen.
Falk
Sonntag, 25.10.09 (02:43 Uhr)
@ Falk Seiler:
Ich entschuldige mich im Voraus für etwaige Schreib- und Grammatikfehler, jedoch bin ich Niederländer und somit werde ich nie das Thema “der, die, dem den oder des” en perfection beherrschen :-)
Ich finde es schon ein wenig impertinent dass Jemand der gerade anfängt behauptet dass Profis Angst hätten für Hobbybastler.
Es ist ja doch wohl so dass eine Webseite nicht nur auf validen Code, Browserkompatibilität und Barrierefreiheit mittels CSS und (X)HTML beruht.
Da kämen dann doch auch noch die Facetten des Designs dazu, oder?
Schliesslich hat der durchschnitts User keine Ahnung was sich “hinter” der Seite, die er gerade besucht, abspielt.
Primär hängt der Erfolg eines Internetauftritts von dem Design ab, weil das der erste Eindruck bildet (innerhalb vonb 10 Sekunden) und anhand dessen der Besucher entscheidet ob er ein gutes “Bauchgefühl” hat und bleibt oder die Seite wegklickt.
Photoshop, In-Design, Freehand, Illustrator sind richtige professionelle Tools, die man wirklich studieren muss damit man mit diese Software arbeiten kann. Und danach muss man sich ständig auf dem laufenden halten.
Ich bin mir sicher dass irgendwelche Nicht-Profis dies absolut nicht beherrschen.
Ebenso sollte man, um eine gut funtionierende Webseite zu erstellen doch auch basierte Kenntnisse in PhP und JavaScript besitzen.
Was das Design angeht, gibt es dort richtiggehende Studienrichtungen. Die goldene Mitte zum Beispiel wie ein Layout eingeteilt wird und wie ein Betrachter eines Magazins, einer Zeitung oder eben eine Webseite anschaut (von Oben Links angefangen (Eintrittsbereich) bis unten rechts (Austrittsbereich). Alles über die Psychologie eines Betrachters wurde in Studien festgelegt.
Um dann nicht die andere Themen wie Farblehre etc. zu nennen. Da Farben Emotionen auslösen ist diese sehr wichtig. Um nicht zu vergessen unsere Sehbehinderte Mitmenschen. Es gibt z.B. verschiedene Arten von Farbblindheit (Rot-, Grün- und Blaublindheit) um nicht zu vergessen das es bei diese Sehstörung totale Farbenblinheit (nur shcwarz/weiß und bunte Farben grau) und Zweifarbensehen gibt. Also sollte man testen (dazu gint es Seiten im Web wo man das mit seinem Design machen kann) ob es auch für diese Zielgruppe (Besucher sind nun mal potenzielle Kunden) ein comfortables Surferlebnis ist, wenn sie die Seite besuchen.
Also sehr wichtig für barrierefreie Webseiten.
Ungeachtet ob ich CSS-Frameworks all dann nicht gut finde (ich arbeite mit Joomla! ein CMS. Auch so etwas aber um komplette Webseiten mit Funktionen zu erstellen damit der Kunde selbst seine Inhalte bearbeiten und/oder austauschen/aktualisieren kann und in der ein Framework für JavaScript “mitgeliefert wird. ) aber es gehört doch eine Menge mehr dazu eine Internetpräsenz zu erstellen.
UND… man kann so ein Framework nur DANN benutzen, wenn man über fundierte Kenntnisse über CSS, (X)HTML, PhP und JavaScript verfügt!
Ist das gleiche wie bei WYSIWYG Editoren die dann, indem Du ein Bildchen ins Fester knallst oder einen Text eingibst, automatisch den Code generiert.
Wenn man keinen Schimmer der Sprache hast, wie kannst man denn in den Quellcode gehen und die Anpassungen, die man gerne hätte, vornehmen?
Ich habe in meiner Ausbildung gelernt, dass man ERST die ganze Materie aus dem FF beherrschen sollte und erst DANN mit solche “Spielzeuge” wie Dreamweaver & Co. rangehen soll.
Aber ehrlich gesagt habe ich Dreamweaver einmal benutzt und dann habe ich auf meine eigene Bibliotheken zurückgegriffen. Aber das erfordert Kenntnisse.
Es ist natürlich deine Wahl wie Du Seiten generierst, aber vielleicht solltest Du erstmal lernen welche Gebiete man beherrschen sollte, bevor man behauptt das Leute wie Du uns Angst machen.
Alles Gute,
Rob