Donnerstag,
14. Oktober 2010

In den Abenstunden des gestrigen Tages war es endlich soweit, YAML 3.3 – das lange angekündigte und erwartete Update meines (X)HTML/CSS Frameworks ging endlich online.

Wohin geht die Reise?

Wie sich unter aufmerksamen Lesern und Barcamp-Besuchern bereits herumgesprochen haben sollte, arbeite ich seit längerer Zeit an einem Nachfolger des YAML-Builders. Mit der Veröffentlichung dieses neuen Projektes wird gleichzeitig (bzw. kurz davor) YAML 4.0 das Licht der Welt erblicken. Diese Version 4.0 ist die Basis für die Arbeit an meinem JavaScript-Projekt und daher ebenfalls schon seit längerem in der Entwicklung und reift langsam heran, allergings wird bis zur geplanten öffentlichen Betaphase noch einige Zeit ins Land gehen.

Damit einher gehen aber einige größere Veränderungen des Frameworks, die eine Abwärtskompatibilität zu dem 3er-Releasestrang unmöglich machen. Aus meiner Erfahrung dürfte das den wenigsten Nutzern weh tun, da die Mehrzahl der Entwickler einen Versionswechsel nur in Verbindung mit neuen Projekten vornimmt. Dennoch habe ich mich entschlossen, einige der für YAML 4.0 geplanten Verbesserungen in der Version 3.3 vorzuziehen, um auch den 3er-Strang zukunftsfähig und für die nächsten 2 Jahre praxistauglich zu halten.

CSS3 wird salonfähig

Die Notwendigkeit für die Version 3.3 ergibt sich maßgeblich aus der mittlerweile guten Browserunterstützung für zahlreiche CSS3-Eigenschaften zur grafischen Gestaltung. In Verbindung mit CSS3 wird die bisher von mir bevorzugte Clearing-Lösung overflow:hidden mehr und mehr zum Problem, da sich das Clipping-Verhalten an den Elementrändern bei Child-Elementen störend auf die Darstellung neuer CSS-Eigenschaften wie box-shadow auswirkt. Dies betrifft in erster Linie die Subtemplates sowie allgemeine CSS-Klasse .floatbox zum Einschließen von Floatobjekten.

Alternativen drängen sich nicht wirklich auf – hierzu werde ich wohl auch nochmal einen Blogbeitrag zum Float-Containing in 2010 schreiben müssen. Fakt ist: Als Kandidaten bleiben display:table und display:inline-block. Grundsätzlich funktionieren beide fast gleich, sie führen zum Einschließen von Floats, benötigen aber zusätzlich eine definierte Breite, sonst fallen die Elemente mit diesen Eigenschaften auf die Breite ihrer Childs zusammen. Innerhalb von YAML ist das kein Problem: display:table; width:100% für .subcolums und .floatbox funktionieren perfekt, denn beiden Klassen enthielten auch in den Vorversionen schon die Breitenangabe von 100%. Es sind daher keine Kompatibilitätsprobleme zu erwarten.

Gegen die Clearing-Methode auf Basis von display:inline-block habe ich mich aus zwei Gründen entschieden:

  1. Während display:table von Firefox 1.0 an unterstützt wird, unterstützt der Firefox display:inline-block erst seit der Version 3. Zwar dürfen die älteren Browserversionen als veraltet bezeichnet werden, aufgrund der vielen Forks ist das dennoch eine Situation, die mich stört. Zwar würde ein Hack die Unterstützung älterer Gecko-basierter Browser über display: -moz-inline-stack ermöglichen, das würde jedoch in einem invaliden Framework-Core resultieren, was unabhängig von meiner persönlichen Meinung zu Validität vermutlich zahlreiche Einsteiger und unwissende Kunden verwirren würde und im Gegensatz zu WAI-ARIA keinen echten Vorteil mit sich bringt.
  2. Noch viel mehr stört mich an display:inline-block, dass es die Elemente zu echten Inline-Elementen macht, die damit den Gesetzmäßigkeiten von normalem Fließtext unterworfen sind. Das bedeutet: Schon ein Zeilenumbruch im Quelltext zwischen zwei Containern mit dieser Eigenschaft wird vom Browser als “Leerzeichen” (sichtbarer white space) interpretiert, wodurch ein Spalt zwischen den Elementen entsteht. Für Einsteiger und Gelegenheitsanwender eröffnen sich aber neue, schwer nachvollziehbare Fehlerquellen und nicht zuletzt macht es die Arbeit mit Content Management Systemen u.U. kompliziert, denn bei weitem nicht alle Systeme erlauben hundertprozentige Kontrolle über den generierten HTML-Code.

Die Eigenschaft display:table ist auch nicht ganz frei von Nachteilen. In Verbindung mit ihr ist position:relative im Firefox (auch anderen Browsern) wirkungslos. Hier sehe ich jedoch kein größeres Problem in Bezug auf YAML, denn einerseits kann man innerhalb der Spaltencontainer der Subtemplates weiterhin relativ positionieren (halt nur nicht direkt in .subcolums), andererseits kann man auch einfach einen zusätzlichen Container wrappen, um das Problem zu umgehen. In der Summe ist dieser Nachteil aus meiner Sicht leichter akzeptierbar als die display:inline-block Eigenheiten.

Beim Formularbaukasten schließlich ist es so, das keine der beiden Alternativen akzeptabel war, denn durch die zwingende Vorgabe einer Breite kommt der Anwender stets in Konflikt mit dem CSS-Box-Modell bei der Gestaltung der Container .type-text, .type-select, etc. Bei fixen Layouts ist das alles leicht anzupassen, bei flexiblen Layouts rennt man damit aber gegen die Wand. Hier nun erlebt der Clearfix-Hack eine Renaissance. Dieser ist nun für die Box-Klassen des Formularbaukastens fest verankert, muss also nicht gesondert als Klasse im HTML ergänzt werden. Das Float-Clearing wird in der .columnar Darstellungsvariante benötigt, um Label und Formularelemente sauber einzuschließen. Mit dieser Änderung lassen sich nun CSS3-Box- und Text-Shadows im Layout und in Formularen sehr frei anwenden.

HTML5 auf die Beine helfen

Damit kommen wir zum zweiten größeren Schritt: HTML5. Eigentlich bräuchte YAML dafür keinerlei Anpassungen, wenn die Herren Browsrentwickler/WHATWG/W3C (keine Ahnung, wer sich das ausgedacht hat) nicht Elementen wie header, footer, etc. als Standardeigenschaft display:inline mitgegeben hätten. Also musste der Reset-Baustein um ein display:block für diese (und weitere) Elemente erweitert werden, damit div#header und header grundsätzlich gleich funktionieren. Dazu bedarf es allerdings doch noch einer Änderung bei YAML:

Während div#header innerhalb von YAML aufgrund der ID ein exklusives Element war und ist, kann und soll header entsprechend der HTML5-Spezifikation nicht nur zur Strukturierung des Screenlayouts sondern auch zur Gliederung von Inhaltselementen verwendet werden. Das wiederum bedeutet, dass die bisherige Regelung in der base.css, den IDs #header, #footer, #main und #nav pauschal die Eigenschaft clear:both mitzugeben, in Verbindung mit den HTML5-Elementen header, footer oder nav zu unvorhersehbaren Problemen führen kann (Stichwort: unbeabsichtigtes globales Floatclearing). Ich habe daher die Konsequenz gezogen, und diese Eigenschaften – und zustätzlich die relative/absolute Positionierung von #header und #topnav – aus der base.css entfernt und ins Screenlayout (basemod.css) der mitgelieferten Beispiellayouts verschoben. Nur durch die konsequente Trennung von Layoutlogik (Framework-Core) und Screenlayout (Spielwiese des Webentwicklers) kann ich Konsistenz beim Übergang von HTML 4 /XHTML 1.0 zu HTML5 bewahren.

Damit wünsche ich allen Anwendern viel Spaß mit der neuen Version. Der YAML Builder ist übrigens auch bereits aktualisiert und gibt v3.3 kompatiblen Code aus.


Du kannst die Kommentare zu diesen Eintrag durch den RSS 2.0 Feed verfolgen. Du kannst einen Kommentar schreiben, oder einen Trackback auf deiner Seite einrichten.

Dieser Eintrag kann nicht mehr kommentiert werden.