CSS & XHTML
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.

 


Freitag16. Januar 2009

Das Jahr ist zwar schon über 2 Wochen alt und ich bin für einen Gute-Vorsätze-Artikel verdammt spät dran, aber solch ein Artikel soll es ja auch nicht sein. Vielmehr brennen mir so einige Dinge unter den Nägeln, die ich gern Ende des Jahres als erledigt, bzw. verfügbar abhaken würde.

PNG Performance

Die Browserhersteller haben sich in 2008 fast überschlagen mit der Jagd nach der 100%-Plakette für den Acid3-Test und dem Kampf um die schnellste JavaScript-Engine. Niemand wird behaupten wollen, dass deswegen bereits alles perfekt ist aber die Fortschritte waren doch gewaltig.

Für dieses Jahr wünsche ich mir eine ähnliches Engagement in Sachen PNG-Performance. Die Verwendung von von PNG-Grafiken ist nämlich momentan die einzige Möglichkeit, alphatransparente Hintergründe zu erzeugen. Nutzt man Alphatransparenzen aber für mehr als nur für ein attraktiv über dem Layout schwebendes Logo, geht die Performance aller modernen Browser selbst auf aktuellen CPU’s extrem in den Keller. Wer es nicht glaubt, braucht nur mal 24ways.org aufzurufen und die Seite etwas scrollen und/oder zoomen. Zwar wird dort RGBa (CSS3) verwendet, um die Transparenzeffekte zu erzeugen, der Performanceeinbruch im Firefox steht dem der PNG-Nutzung aber in nichts nach.

Gerade im Bereich von Webapplikationen (ich konnte bei der Arbeit am YAML-Builder reichlich Erfahrung sammeln) ist das nur allzu oft spürbar und es schmerzt, weil sich mit Hilfe von Alphatransparenzen viele nützliche Dinge anstellen ließen. Die CSS-Eigenschaft opacity ist in vielen Fällen unbrauchbar, denn sie ist nicht auf nur auf den Hintergrund beschränkt, sondern wirkt auch auf den Content und sogar auf Childelemente.

Also, liebe Browserhersteller, wer fängt an? Wenn es zu CPU-lastig wird, dürft ihr auch gern optional auf Grafikkartenunterstützung zurückgreifen. Hauptsache es tut sich was.

Programmierer mit einem Herz für Webentwickler

Auch wenn ich persönlich noch immer auf der Suche nach einem Content-Management-System bin, welches einerseits ein anständiges Templating, Mehrsprachigkeit, Workspaces mitbringt und gleichzeitig ein logisch strukturiertes Backend und eine erträglich flache Lernkurve verspricht, hat sich doch in den letzten Jahren auf diesem Sektor viel getan. Über das Seitenlayout hat man als Entwickler fast überall die Kontrolle.

Anders sieht es bei jeglichen Erweiterungen (Plugins, Extensions ... nennt die Dinge, wie Ihr wollt) aus. In den seltensten Fällen erlebe ich es, dass hier mit Templates gearbeitet wird. Stattdessen rendern die meisten Erweiterungen Code, der alles andere als Best Practice oder gar Webstandards entspricht heraus und man muss entweder mühsam patchen oder steht am Ende des Tages doch wieder alleine da. Wie wäre es doch schön, wenn sich in Content-Management-Systemen Template-Schnittstellen durchsetzen würden, die auch für Plugins eine einfache Anpassung des Markups ermöglichen würden. Wer gern in die Tiefen von PHP abtaucht, darf dies tun, ich bevorzuge eine strikte Trennung von Programmcode und Frontentausgabe.

Daher die allgemein formulierte Bitte an Programmierer von Erweiterungen. Macht es den Anwendern Eurer Software ein kleines bisschen leichter und erlaubt das Templating der Ausgaben.


Mittwoch14. Januar 2009

Gestern wurde ich kurzfristig gebeten, ein Shoptemplate zu begutachten. Folgender semantischer Schrecken offenbarte sich unter der Haube eines zunächst einmal optisch durchaus ansprechenden Layouts.

Call me Überschrift

Es ist nicht so, dass es keine Überschriften gab in diesem Template. Das H1-Element war durchaus vorhanden ...

<h1>
  <strong>Willkommen</strong>
  <strong>im <span style="color: #ff3301;">e</span>Shop</strong>
</h1>

Zunächst stellt sich natürlich die grundsätzliche Frage nach der Notwendigkeit der STRONG-Elemente, aber auch das SPAN-Element zur Hervorhebung des Buchstaben “e” glänzt aufgrund der Inline-Styles auch nicht gerade vor Eleganz. Dabei wäre es so einfach ...

<h1>Willkommen im <span>e</span>Shop</h1>

Und damit wird den ersten Buchstaben auch erwischen, gönnen wir uns eine Zeile CSS ...

h1 span { color: #ff3301; }

Den gesamten Beitrag lesen


Freitag05. Dezember 2008

Heute morgen um 8:00 Uhr ging mein erster Beitrag zum diesjährigen Adventskalender der Webkrauts online. Wie der Titel “Grundregeln für zugängliches JavaScript” bereits verrät, geht es um einige wichtige grundlegende Verhaltensregeln bei der Anreicherung von Webseiten mit JavaScript.

Der Artikel ist nicht gerade kurz geraten, hat aber gerade deswegen nach all den CSS- und Framework-Diskussionen der letzten Zeit besonders viel Spaß gemacht.


Seite 4 von 9 Seiten

« Erste  <  2 3 4 5 6 >  Letzte »