Frameworks
Freitag17. Juli 2009

Einen etwas ausführlicheren Beitrag zu effizientem Code (HTML & CSS) habe ich mir schon lange vorgenommen – dieser hier ist es noch nicht. Dennoch hat mich diese kürzlich erschienene Evaluation der vier bekanntesten CSS-Frameworks zu diesem Beitrag bewogen. YAML ist wohl mit Abstand das komplexeste Framework unter den genannten und bedingt aufgrund seiner Ausrichtung (flexible Layouts) sowie der Vielzahl an Möglichkeiten, Dateien und Beispiele auch eine steilere Lernkurve. Schnell kann dabei der Eindruck entstehen, dass die Komplexität (und die umfangreiche Browserunterstützung) zu einem überbordenden Umfang des Frameworks führen. Also gehe ich dieser These hier mit einem kleinen Vergleich mal auf den Grund und verleiche das CSS-Volumen der Framework-Cores.

Der Framework-Core

Beinahe jedes CSS-Frameworks definiert sich durch so genannte Kernbausteine. Diese stellen die grundlegende Funktionalität bereit und sorgen für deren browserübergreifende Kompatibilität. Neben diesen Kernbausteinen bieten die einzelnen Projekte mal mehr, mal weniger optionale Bausteine an (Navigationsbausteine, Textformatierung, Formulare ect.), um den Entwicklungsprozess über die grobe Layouterstellung hinaus zu erleichtern. Genau in diesem Punkt klafft die Schere zwischen den einzelnen Projekten sehr weit auseinander. Diese optionalen Bausteine erhöhen zwangsläufig für den Einsteiger beim Erstkontakt die Komplexität, berühren aber eigentlich die Kernaufgabe der CSS-Frameworks (die Layouterstellung) nicht wirklich und erschweren die Vergleichbarkeit. Ich konzentriere mich deshalb beim folgenden Vergleich jeweils auf diese Kernbausteine, den so genannten Framework-Core folgender Projekte:

Den gesamten Beitrag lesen


Mittwoch08. Juli 2009

Note: This experiment began with a big portion of irony in mind, regarding CSS frameworks. But then it developed into an interesting exercise on how to code with minimal markup.

Have you ever wanted to work with a streamlined CSS framework? Here it is ...

The source code

revision 1: 109 Bytes

<!DOCTYPE html><head><title></title><style type="text/css">*{color:#000;background:#fff}</style></head><body>

No need for a download link. It even fits in a tweet on Twitter.

Revision 2: 74 Bytes

<!DOCTYPE html><title></title><style>*{color:#000;background:#fff}</style>

This is still a valid HTML 5, crossbrowser compatible document and the framework is still ready to start adding content. With revision 2 we achieve amazing 32 percent saving of markup. The source code fits on a single typewriter line.

10 exciting killer-features

  1. It’s standard compliant and only uses valid code (valid HTML 5)
  2. Completely made without any CSS hacks
  3. It’s prepared for the future by using the latest web technologies (HTML 5)
  4. It has a streamlined source code, no DIV soups or bloated CSS, no optional end-tags.
  5. It has accessibility features (maximum contrast for all elements)
  6. Premium class browser compatibility (IE 3+)
  7. Performance optimized code - only a single HTTP request
  8. No limits for webpage design (allows fixed, elastic or fluid designs and even grids)
  9. Prepared for web 2.0: Just add rounded corners, drop shadows and reflections
  10. It’s free: licensed under Gnu Public License

Many thanks to co-author Tomas Caspers for his help, hard work and contribution to make this web developers dream come true.

UPDATE:  Revision 2 is out with huge markup savings. Thanks to all commenters who helped to fall below the 100 Byte limit.


Montag23. 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 ...


Montag02. März 2009

Seit heute ist die 15. Ausgabe des T3N Magazins verfügbar und dieses Mal habe ich mal wieder einen Artikel beigesteuert. Auf dem Berliner Barcamp im Oktober letzten Jahres war ich mit den yeebase-Jungs ins Gespräch gekommen und habe Anfang Januar habe ich dann in die Tasten gehauen. Wenig verwunderlich dreht es sich um Layout-Frameworks.

  Seit langem schon ärgert es mich, dass in Berichten über CSS-Frameworks immer wieder die z.T. grundverschiedenen Ansätze der verschiedenen Projekte undifferenziert in einen Topf geworfen und miteinander verglichen werden. Deshalb fasse ich alle aktuell existierenden Projekte zunächst unter dem übergeordneten Begriff Layout-Frameworks zusammen. Ausgehend vom gewählten Layoutansatz es Frameworks folgt dann eine Unterscheidung in Grid- und CSS-Frameworks (eine Einstufung, die ich auch schon beim in Webkongress in Erlangen vorgestellt habe).

Grid-Frameworks
Sinn und Zweck eines Grid-Frameworks sind schnelle Ergebnisse in der Anwendung in den Grenzen des vorgegebenen Rasters.
CSS-Frameworks
Sinn und Zweck eines CSS-Frameworks ist die Bereitstellung einer möglichst leistungsfähigen Entwicklungsumgebung

Den roten Faden durch den Beitrag bildet die Betrachtung der Entwicklungszeit eines Layouts, wobei sich Layout-Frameworks in Abhänhigkeit des Layoutansatzes und der gewährten Freiheiten recht gut zwischen den beiden Extremen, dem Einsatz von Fertigtemplates (minimaler Aufwand, kein Einfluss auf Codequalität) oder der vollständigen Handkodierung des Layouts (volle Codekontrolle, maximaler zeitlicher Aufwand zur Layouterstellung) einordnen lassen. Unabhängig von persönlichen Vorlieben für den einen oder anderen technischen Weg lässt sich über die Zeitschiene sehr deutlich zeigen, wo die maßgeblichen Vorteile von Layout-Frameworks liegen - in der geringeren Entwicklungszeit.

Die gewonnene Zeit kann für Verbesserungen von Usability und Accessibility und/oder Performanceoptimierungen genutzt werden, denn diese Eigenschaften professioneller Webseiten sind in erster Linie contentabgängig. Das umschließende Layoutgerüst von Layout-Frameworks bietet zwar ebenfalls Potential, jedoch weit weniger als oft vermutet. Bei typischen Größen von 200 ... 300 kB komplexer Webseiten hat das Seitenlayout (HTML und CSS) im Durchschnitt einen Anteil von 5-10 Prozent (unabhängig von der Entstehung).

Im zweiten Teil des Artikel dreht sich dann auch alles um Performance. Frameworks bieten hier aufgrund ihres modularen Aufbaus des CSS naturgemäß Angriffsfläche für Kritik. Kommentare im CSS bedeuten verlängerte Ladezeiten, jeder einzelne CSS-Baustein muss vom Server angefordert werden (HTTP-Requests), was zwangsläufig mit Wartezeiten verbunden ist. Vergessen wird bei dieser Diskussion zumeist, dass auch bei der Handkodierung von Webseiten kaum ein Entwickler auf Zeilenumbrüche, Einrückungen und den einen oder anderen erläuternden Kommentar verzichten kann. Worauf ich hinaus will: Ob Framework-Einsatz oder Handkodierung - die Komprimierung von CSS-Dateien und die Reduzierung von HTTP-Requests sind generelle Optimierungszenarien, um die Performance einer Webseite zu steigern. Wer Performance-Optimierung ernsthaft betreibt, der kommt um eine komprimierte Live-Version des Entwickler-CSS nicht herum.

 


Seite 2 von 2 Seiten

 <  1 2