Worum geht es? Vor langer Zeit als die Welt noch schwarz-weiß ... als das Web noch jung und HTML4 Quellcode noch fürchterlich chaotisch und gefühlt frei jeglicher Stilregeln geschrieben werden konnte, da kamen einige schlaue Webschaffende auf die Idee, dass es doch ein wirklicher Fortschritt wäre, wenn sich die Entwicklergemeinde an Standards halten würde. Webstandards kamen in Mode und der Ruf nach sauberem, validem Code drang selbst in die hintersten Gassen. XHTML 1.0 war damals der große argumentative Renner, denn XHTML zwang Webentwickler zu Ordnung und Sauberkeit im Code. Tags mussten geschlossen, Attributwerte zwingend in Anführungszeichen gesetzt werden. Die jahrelange Arbeit mit XHTML hat mir zwar XML an sich kein noch so kleines Stückchen sympathischer gemacht (aufgrund seiner Fehlerintoleranz) aber es hat mich gelehrt sauberen Code zu schreiben.

Und da auch ich zu denen gehöre die Bücher veröffentlichen, um mein Wissen um HTML & CSS weiterzugeben, bin ich auch nicht ganz unschuldig an der Situation, die sich uns Entwicklern heute bietet. Seit vielen Jahren predigen wir: Validiert Euren Code! Wenn irgendetwas nicht funktioniert und Ihr jemanden nach Hilfe fragen wollt: Erst validieren – dann jemanden fragen! So oder so ähnlich liest man es in jedem CSS-Buch (und davon gibt es mittlerweile reichlich). Leider haben offensichtlich die wenigstens Autoren es bisher geschafft, den ahnungslosen Neulingen in einfachen Worten zu vermitteln, was Validität eigentlich bedeutet und was die Ausgaben der Validierungsdienste des W3C (HTML | CSS) wirklich bedeuten.

Dieser Umstand ist mir so richtig klar geworden, als ich vorhin über folgendes Foreneintrag gestolpert bin:

Hallo Zusammen!

Ich habe per CSS folgende Codes eingefügt um einen Text vertikal darzustellen. Soweit funktioniert das auch. Jedoch bei der W3C Validierung werden diese CSS Anweisungen als Fehler deklariert. Gibt es hierzu auch eine valide Möglichkeit?

Dazu wurde folgender Codeschnipsel mitgeliefert:

-webkit-transform: rotate(-90deg); 
-moz-transform: rotate(-90deg);    
-o-transform: rotate(270deg);

Ein Einsteiger präsentiert sauberes CSS3, denkt bei den Vendor-Präfixes an alle wichtigen Browser, freut sich zurecht über den Erfolg (”...Soweit funktioniert das auch…”) und wendet sich anschließend trotzdem verzweifelt an ein Forum weil der W3C-Validator ihm ein schlechtes Gewissen eingeredet hat. Das muss definitiv aufhören, denn spätestens wird das ehemalige Mantra der Pflicht-Valität zum Boomerang für uns erfahrenere Entwickler, denn hier werden die Aussagen des Validators fehlinterpretiert.

Wie funktioniert ein Validator?

Der Validator prüft also die Gramatik des Codes, also die richtige Verwendung von Klammern, Anführungszeichen, Elementverschachtelungen etc. Für die Rechtschreibprüfung verwendet der Validator ein Wörterbuch. Bei HTML werden also Tags und Attribute, bei CSS Eigenschaften und Werte anhand einer Wortliste überprüft. Werden sie gefunden, ist alles in Ordnung. Hat sich jedoch ein Tippfehler eingeschlichen, dann wird das entsprechende Schlüsselwort in der Liste nicht gefunden und der Validator gibt einen Fehler aus. Unbekannte Elemente werden somit ebenfalls als Fehler behandelt. Bei der Validierung von HTML war dieses Vorgehen des Validators in der Vergangenheit auch in Ordnung, denn das jeweils verwendete HTML-Wörterbuch wählt der Validator anhand des in der Webseite vorgegebenen DOCTYPES aus. Elemente, die in der jeweiligen Spezifikation nicht enthalten sind, erzeugen somit Fehlermeldungen.

Das Problem

Ganz so einfach ist es halt doch nicht, denn neben HTML existieren mittlerweile zahlreiche Standards, die den HTML-Standard erweitern. Als Beispiel sei hierfür WAI-ARIA genannt, womit HTML durch zusätzlich Attribute mit semantischen Informationen angereichert wird. ARIA wird von allen relevanten Browsern (einschließlich IE6) und den aktuellen Screenreadern unterstützt. Screenreadernutzer profitieren daher schon länger von diesen Zusatzinformationen. Der W3C Validator kennt diesen Standard hingegen noch nicht – vermutlich weil er noch immer nicht aus dem Draft-Status heraus gekommen ist. Die Konsequenz daraus für den unwissenden User: Die durchaus sinnvollen ergänzenden ARIA-Attribute werden dem User als Fehler ausgewiesen.

Folgenden Satz bekam ich bei der Einführung von WAI-ARIA in den YAML-Beispielen vor knapp einem Jahr regelmäßig in e-Mails zu lesen:

Wir bekommen auf jeder Seite folgenden Fehler:
——————————————————————————————
Line 35, Column 31: there is no attribute “role”
      <div id=“header” role=“banner”>

Gut gemeint und doch spukt der Validator eine Fehlermeldung aus, ohne jede zuätzliche Erklärung. Leider hat der W3C-Validator hier noch eine schwache Ausrede, denn formal gehört sich in diesem Fall auch ein passender DOCTYPE, der XHTML + WAI-ARIA ankündigt. Leider gibt’s den aber meines Wissens auch noch nicht wirklich. Der Akzeptanz von WAI-ARIA ist damit nicht gerade ein roter Teppich ausgerollt, obgleich ich jedem ernsthaften Entwickler nur ans Herz legen kann, sich damit zu beschäftigen.

Noch nerviger ist die Situation bei Cascading Stylesheets. Auch hier hat sich die Entwicklergemeinde in den letzten Jahren aus der IE6-Lethargie gelöst und propagiert aus guten Gründen Progessive Enhancement Strategien. Dank der rapide wachsenden CSS3-Unterstützung durch Firefox, Chrome und Opera trifft dieser Ruf auch auf immer mehr willige Entwickler – wie den vornweg zitierten Kollegen. Nur leider steht das erste “C” für “Cascading” also ein aufeinander aufbauendes System. Jeder neue CSS-Standard erweitert den bestehenden Sprachschatz. Zu dumm, dass das W3C den CSS3-Standard zwar kennt, jedoch in den Standardeinstellungen Stylesheets hart nach CSS 2.1 validiert und der Validator die “unbekannten” CSS3-Eigenschaften ebenso als Fehler behandelt, wie jeden wirklichen Tippfehler.

Und um Neueinsteiger restlos zu verwirren, erkennt der W3C Validator die überwiegende Zahl der heute bereits verwendeten CSS3-Regeln noch nicht einmal dann als korrekt, wenn man seine Stylesheets gegen CSS3 validiert. Denn beim W3C kennt man offensichtlich keine Vendor-Präfixes, die das W3C den Browserherstellern selbst vorschreibt, solange neue CSS-Eigenschaften lediglich experimentell implementiert sind. Und damit fliegen uns die meisten runden Ecken, Box- und Text-Schatten oder Gradienten reihenweise um die Ohren.

Als Beispiel hier ein Test, mit der CSS3-Eigenschaft -moz-border-radius (Das Vendor-Präfix “-moz” steht für Mozilla) den folgenden fehlerfreien Code gegen CSS3 validieren zu lassen:

body { -moz-border-radius: 5px; }

Dazu meint der freundliche CSS-Validierungsdienst des W3C ...

Mir ist klar, dass eine solche Meldung für Einsteiger nicht nur respekteinflößend ist, sondern gelegentlich (bei aktuell noch weniger bekannten CSS3-Eigenschaften) regelrecht verschreckt. Nicht umsonst fragte oben zitierter Neuling, ob es denn auch eine valide Lösung für sein real nicht vorhandenes Problem gäbe.

Aufklärung dringend notwenig

Was die Webstandards-Gemeinde angefangen hat, muss sie jetzt auch weiter durchziehen. Einsteiger und unwissende Entscheider müssen darüber aufgeklärt werden, dass Fehlermeldungen des W3C-Validators kein hinreichendes Kriterium zur Qualitätsbewertung der umsetzenden Agentur oder gar ein Anwendungsverbot für neue Standards bedeuten. Es muss klar werden, das – wie bei jeder automatischen Rechtschreibprüfung – aktuell kein Validator in der Bewertung einen Unterschied zwischen einem echten Rechtschreibfehler und einen ihm unbekannten Schlüsselwort macht. Vergleichbares kennt man von Rechtschreibprüfungen in Textverarbeitungen. Kaum ein Programm ist in der Lage, Substantive und Verben auch in all Ihren Beugungsformen und Fällen zu erkennen. Gleiches gilt für die Erkennung von Namen.

Ich weiß, dass viele gestandene Entwickler hier kommentieren werden, dass sie sich um die Ergebnisse des W3C-Validators nicht (mehr) scheren. Doch das allein hilft weder Einsteigern noch Entscheidern, sich zurechtzufinden. Beide Zielgruppen nehmen den W3C Validator (oder auch Hilfsmittel wie das HTML Validator-Plugin für den Firefox) offensichtlich als stichhaltiges Werkzeug zur Qualitätsbeurteilung war. Für Webentwickler und aus der Sicht eines Buchautors halte ich diese Entwicklung für falsch. Deshalb hilft nur eines: Weiter und besser darüber aufzuklären, was Validität bedeutet.

Meine Definition

Validität ist kein Qualitätsmerkmal! Eine Validitätsprüfung ist eine automatische Gramatik- und Rechtschreibprüfung für HTML- und CSS-Code auf Basis eines definierten Wortschatzes.

Eine Validitätsprüfung sagt daher genauso wenig über die Codequalität wie die automatische Rechtschreibprüfung von Microsoft Word oder Open Office mit dem vorinstallierten Standardwörterbuch über meine Fähigkeiten, gute und fehlerfreie Fachtexte zu schreiben. Die Prüfung ist wichtig zur Selbstkontrolle, zur Vermeidung und dem Auffinden von Flüchtigkeitsfehlern und somit ein Entwicklerwerkzeug.

Ich hoffe, diese Analogie hilft etwas, das Verständis der Materie zu verbessern. Vermutlich habe ich mal wieder viel zu viel geschrieben, dennoch: es musste mal gesagt werden.Den unsicheren User im Forum werde ich jetzt etwas aufmuntern ...

Nach nunmehr 6 Jahren als wissenschaftlicher Mitarbeiter zieht es mich ein wenig weg vom universitären Umfeld. Es geht zurück in die freie Wirtschaft. Seit Juli pendle ich bereits regelmäßig zwischen Dresden und Berlin, ab August übernehme ich die Chefredaktion der BAUTECHNIK, einer renomierten wissenschaftlichen Fachzeitschrift für Bauingenieure beim Ernst & Sohn Verlag. Für mich ist es eine große Herausforderung in dem mir nicht fremden aber doch neuen und ungewohntem Terrain des Verlagswesens. Aber es sind schließlich die Herausforderungen, welche die tägliche Arbeit spannend und auf Dauer erfüllend machen und ich freue mich riesig auf die neue Aufgabe. Damit war allerdings bereits Anfang des Jahres (als diese Entscheidung fiel) auch klar, dass meine Dissertation unter Hochdruck bis zum Sommer fertig werden musste. Damit wäre dann auch der eigentliche Grund genannt, warum hier in den letzen Monaten keine neuen Beiträge mehr erschienen. Es blieb schlicht weg keine Zeit. Auch jetzt geht noch das eine oder andere Wochenende dafür drauf, dennoch sind die größten Hürden genommen. Das Licht ist also schon sehr nahe.

Was bedeutet das alles nun für dieses Blog und YAML? Dies ist mein privates Weblog und das werde ich auch weiterhin mit meinen Gedanken zu HTML, CSS und JavaScript füllen sowie vermutlich auch den einen oder anderen Kommentar hinsichtlich des HTML5 & CSS3 Hypes hinterlassen – kurz: hier geht es weiter wie gewohnt. YAML entwickelt sich seit nunmehr fast 5 Jahren kontinuierlich weiter – ein Ende ist auch hier nicht in Sicht. Die Reife des Frameworks macht die Entwicklungsarbeit für mich allerdings etwas angenehmer denn die Releasezyklen werden naturgemäß etwas länger. Der Browsermarkt ist aktuell so richtig in Bewegung und das bedeutet, dass bei YAML diesen Fortschritten Rechnung trägt. Für die effektive Arbeit mit den grafischen Gestaltungsmöglichkeiten von CSS3 gilt es, bestmögliche Voraussetzungen zu schaffen. Dass bedeutet in erster Linie, dass Alternativen zum Clearing mit der Eigenschaft overflow benötigt werden, um die Arbeit mit CSS3-Eigenschaften wie text-shadow und box-shadow weiter zu erleichtern. Daneben haben es Browserhersteller offenbar noch nicht geschafft, den neuen HTML5-Elementen einheitliche und vor allem sinnvolle Standardstyles mitzugeben. Hier wird es eine geringfügige Anpassung des Reset-Bausteins geben, der die aktuell noch vorhandenen Inkonsistenzen beseitigt. Die dritte Baustelle betrifft den Formularbaukasten. Dieser vergleichsweise noch junge Teil des YAML-Framework wird aktuell überarbeitet und soll einfacher individuell gestaltbar werden. Diese und vermutlich einige weitere Änderungen liegen aktuell in einer Version 3.3 alpha, laufen bisher prima und gehen demnächst an die ersten Tester raus. Nein – es gibt noch kein Releasedatum.

Auch in Bezug auf den YAML Builder ist Großartiges in Vorbereitung. Der eine oder andere konnte sich auf dem Barcamp Mainz im letzten November oder auf dem diesjährigen MobileCamp in Dresden bereits einen ersten Eindruck von dem verschaffen, was bereits seit längerem in der heimischen Entwicklerküche auf heisser Flamme köchelt. Natürlich musste ich auch hier eine Pause einlegen, dennoch reift das Projekt Schritt für Schritt und ich freue mich bereits darauf, hier im Blog die ersten Details verlauten lassen zu können. Lange wird es nicht mehr dauern, versprochen.

Anforderungen

Zunächst wären noch einmal die Anforderungen an Skiplinks zu definieren. Die WCAG 2.0 gibt unter G1 Testkriterien vor:

1. Stelle sicher, dass Skiplinks die ersten focussierbaren Elemente der Webseite darstellen.
2. Stelle sicher, dass die Linkbeschreibung eine verständliche Beschreibung des Sprungzieles enthält.
3. Stelle sicher, dass der Skiplink entweder immer oder zumindest dann sichtbar ist, wenn der Tastaturfocus auf ihm liegt.
4. Stelle sicher, dass beim Aktivieren eines Skiplinks der visuelle Focus im Viewport des Browsers auf das Ziel gesetzt wird.
5. Stelle sicher, dass nach dem Aktivieren des Skiplinks der Tastaturfocus auf das Zielelement gesetzt wurde.

Die WCAG ist unnachgiebig, was diese Kritierien betrifft: Alle 5 Testkriterien müssen erfüllt werden.

Die Grundlagen: Markup und Styling

Skiplinks sollten grundsätzlich vor dem eigentlichen Inhalt der Webseite eingebaut werden, um dem Testkriterium 1 (erstes focussierbares Element) gerecht zu werden. Eine einfache Kontrollmöglichkeit für diese Regel besteht darin, sich die Webseite mit deaktivierten Stylesheets anzuschauen. Die Skiplinks sollten dabei an erster Stelle stehen.

Die technische Umsetzung per HTML & CSS ist nicht weiter kompliziert. Das HTML-Grundgerüst bildet ein einfacher Hyperlink, als Ziel kann jedes beliebige HTML-Element der Webseite dienen, soweit es über eine ID eindeutig identifizierbar ist. In der Regel wird man hier auf z. B. den DIV-Container verweisen, welcher die Hauptnavigation oder die Hauptinhaltsbereich der Webseite beinhaltet.

Skiplinks sind nichts Neues mehr, deshalb will ich den technischen Teil an dieser Stelle kurz halten. Tomas Caspers hat vor einiger Zeit auf Einfach für Alle ein sehr eingängiges Tutorial verfasst, welches ich jedem Einsteiger in die Materie ans Herz legen möchte. Auch die Diskussion in den Kommentaren ist bei diesem Beitrag lesenswert. Der wichtigste Punkt, Thomas spricht es an, betrifft die gewählte Technik für das zwischenzeitliche Ausblenden der Skiplinks. Hier darf keinesfalls die CSS-Eigenschaft display:none verwendet werden, denn hierdurch ist der Link für Screenreader nicht mehr erreichbar – und somit nutzlos. Das Aus- und Einblenden von Skiplinks geschieht daher in der Regel durch eine absolute Positionierung, womit die auszublendenden Elemente einfach seitlich aus dem Viewport verschoben (versteckt) werden und bei Focussierung per Tastatur wieder in den sichtbaren Teil zurückgeholt werden.

Mehr Gestaltungsfreiheit

Wie anfangs beschrieben, sollten Skiplinks generell vor den eigentlichen Seiteninhalten im Quelltext stehen. Das Verstecken der Skiplinks ist nie ein Problem – wohl aber die Eingliederung ins Layout, sobald die Skiplinks sichtbar werden. Einerseits muss im Layout Platz (Leerraum) für die Skiplinks eingeplant werden, zum anderen müssen Sie für den Nutzer bei Aktivierung auch gut erkennbar (Kontrast, Schriftgröße) sein. In grafiklastigen Layouts kann dies recht aufwändig werden.

Aus diesem Grund liefere ich seit einiger Zeit (v3.2) bei meinem CSS-Framework YAML eine etwas aufwändigere Darstellungsvariante mit, die in allen Layout-Beispielen implementiert ist. Hierbei werden die Skiplinks nicht in das Layout integriert, sondern bei Focussierung in Form eines farbigen Balkens über dem Layout eingeblendet. Auf diese Weise eröffnen sich viel größere Freiheiten bei der Darstellung – ohne dass das eigentlich Layout in irgendeiner Form beeinflusst wird.

Soweit, so gut. Im Prinzip wäre ich hiermit am Ende des Beitrags, wenn es da nicht neuerdings ein ausgesprochen hässliches Problem mit einigen modernen Webbrowsern gäbe.

Folge dem weißen Kaninchen Tastaturfocus

In den aktuellen Versionen der Webkit-basierten Browser (Google Chrome, Apple Safari) sowie im aktuellen Internet Explorer 8 unter Windows 7 (unter Vista tritt das Problem im IE8 offenbar nicht auf) wird bei Aktivierung eines Skiplinks zwar der visuelle Focus auf das Zielelement ausgerichtet (WCAG 2.0, Testkriterium 4 erfüllt), der Tastaturfocus verbleibt jedoch auch nach Aktivierung auf dem Skiplink, er wird nicht verschoben. Damit ist das Testkriterium 5 nicht erfüllt, denn beim nächsten Druck auf die Tabulatortaste springt der Focus (viuseller Focus und Tastaturfocus) auf das focussierbare Element, welches dem zuvor aktivierten Skiplink im Quelltext folgt. Damit wird der Sinn der Skiplinks vollständig ausgehebelt, denn man befindet sich praktisch wieder bei (oder direkt hinter) den Skiplinks.

Wen trifft das Problem eigentlich?

Ich habe gestern Marco Zehe um Hilfe gebeten, einige Browser/Screenreader-Kombinationen durchzutesten. Marco arbeitet in der Regel mit NVDA und hat im Internet Explorer 8 unter Windows 7 keinerlei Probleme, NVDA greift hier offenbar korrigierend ein. Auch im Safari/Mac trat das Problem in Verbindung mit VoiceOver nicht auf – Google Chrome und Safari/Win sind hingegen nach Marcos Meinung "gar nicht accessible!". Eine Nutzung scheidet für Ihn daher generell aus – das Focusproblem ist damit nicht seines.

Anders sieht die Situation bei JAWS aus: Hier konnte Marco das Problem in Verbindung mit dem Internet Explorer 8 verifizieren. Freundlicherweise ist JAWS der mit Abstand am meisten genutzte Screenreader und auch der IE hat eine gewisse Verbreitung – das Focusproblem ist also überaus real und bedarf einer Lösung.

Workaround – Runde 1

Ich wurde seinerzeit durch einen Blogbeitrag von Paul Redcliffe auf einen cleveren JavaScript-Workaround aufmerksam (Demo). Der Workaround besteht darin, dass er den Skiplinks dynamisch einen Click-Event zuweist, um bei Aktivierung den Tastaturfocus per JavaScript zu setzen. Hier der zugehörige JavaScript-Code ...

var is_webkit = navigator.userAgent.toLowerCase().indexOf('webkit') > -1;
var is_opera = navigator.userAgent.toLowerCase().indexOf('opera') > -1;
if(is_webkit || is_opera) {
  var target = document.getElementById('skiptarget');
  target.href="#skiptarget";
  target.innerText="Start of main content";
  target.setAttribute("tabindex" , "0");
  document.getElementById('skiplink').setAttribute("onclick" , "document.getElementById('skiptarget').focus();");
}

Grundsätzlich funktioniert der Workaround, allerdings gefallen mir einige Details nicht, weshalb ich für YAML einen eigenen Fix geschrieben habe.

• Die Variablen werden im globalen Scope definiert und kein Namespacing verwendet. Das mag im konkreten Fall nicht weiter stören, dennoch empfinde ich es als unsauber.
• Das Script ist monoton auf einen einzigen Skiplink mit der ID skiplink ausgelegt (getElementById) und nicht flexibel erweiterbar. Das ist unzureichend, da zwei oder drei Skiplinks (z.B.: Navigation, Inhalt, Kontaktformular ...) keine Seltenheit sind.
• Den Zielelementen wird innerhalb des Skripts das Attribut tabindex="0" zugewiesen. Das ist aus meiner Sicht keine gute Lösung, denn so wird das Zielelement permanent in die normale Tabreihenfolge aufgenommen, obwohl es bei Focussierung per Tastatur keinerlei Funktion bietet – im Gegensatz zu focussierbaren Links, dessen URL der Nutzer bei Aktivierung folgt.
• Eine weiter Unschönheit ergibt sich durch tabindex="0" in Verbindung mit Apples Safari, denn dieser hebt das focussierte Element generell durch eine leuchtend blaue Umrandung per outline hervor. So angenehm diese Darstellung bei focussierten Links oder Formularelementen ist, so störend oder verwirrend kann die plötzliche Hervorhebung eines einfachen DIV-Containers im Layout sein.

Workaround – Runde 2

Letztlich konnte ich das Phänomen im aktuellen Opera nicht nachvollziehen und konzentriere mich daher nur auf Webkit-Browser und den Internet Explorer. Der nachfolgende Code ist (bis auf minimale Abweichungen) Bestandteil der aktuellen Version 3.2.1 von YAML und ist unter yaml/core/js/yaml-focusfix.js zu finden.

/**
 * "Yet Another Multicolumn Layout" - (X)HTML/CSS Framework
 *
 * (en) Workaround for Webkit browsers to fix focus problems when using skiplinks
 * (de) Workaround für Webkit browsers, um den Focus zu korrigieren, bei Verwendung von Skiplinks
 *
 * @copyright       Copyright 2005-2010, Dirk Jesse
 * @package         yaml
 */

var YAML_focusFix = {
  init: function() {
    var skipClass = 'skip';
 
    var userAgent = navigator.userAgent.toLowerCase();
    var is_webkit = userAgent.indexOf('webkit') > -1;
    var is_ie = userAgent.indexOf('msie') > -1;
    var i = 0;
    var links, skiplinks = [];
   
    if (is_webkit || is_ie) {
      // find skiplinks in modern browsers ...
      if ( document.getElementsByClassName !== undefined) {
        skiplinks = document.getElementsByClassName(skipClass);
   
        for (i=0; i<skiplinks.length; i++) {
          this.setTabIndex(skiplinks[ i ]);
        }
      } else {
        // find skiplinks in older browsers ...
        links = document.getElementsByTagName('a');
        for (i=0; i<links.length; i++) {
          var s = links[ i ].getAttribute('href');
          var c = links[ i ].getAttribute('class');
          if (s.length > 1 && c.indexOf(skipClass) != -1 && s.substr(0, 1) == '#' ) {
            this.setTabIndex(links[ i ]); 
          }
        }
      } 
    }
  },

  setTabIndex: function( skiplink ){
    var target = skiplink.href.substr(skiplink.href.indexOf('#')+1);
    var targetElement = document.getElementById(target);
   
    if (targetElement !== null) {
      // make element accessible for .focus() method 
      targetElement.setAttribute("tabindex", "-1");
      skiplink.setAttribute("onclick", "document.getElementById('"+target+"').focus();"); 
    }
  }
};

YAML_focusFix.init();

Welche Änderungen habe ich nun im Detail vorgenommen? Das Script springt nun sowohl bei der Webkit-Engine, als auch beim Internet Explorer an und kann mehrere Skiplinks verarbeiten, indem es alle Links mit der Klasse .skip auswertet und entsprechend mit dem Workaround versieht. In YAML-basierte Layouts kann man es daher ohne weitere Konfiguration einbinden.

Beim Internet Explorer wurde bewusst auf einen Versionstest verzichtet, denn wie in dem weiter oben verlinkten Tutorial von Tomas Caspers zu lesen, haben die älteren IE-Versionen ein ähnliches Problem, sobald das Zielelement das proprietäre Merkmal hasLayout nicht besitzt. Da ich per JavaScript schlecht ins Layout eingreifen kann, um hasLayout zu triggern, ist es einfacher, das Script auch in den älteren IE’s pauschal durchlaufen zu lassen. Und letzten Endes setzt das Script auf dem Zielelement das Attribut tabindex="-1". Der Wert -1 erlaubt das dynamische Setzen des Tastaturfocus per JavaScript, fügt das Element aber nicht in die Tabreihenfolge ein. Damit werden die oben beschriebenen, unschönen Nebeneffekte von tabindex="0" vermieden.

Fazit

Ich muss gestehen, ich bin von der aktuellen Situation alles andere als begeistert. Nicht einmal ein so einfaches Konzept wie Skiplinks lässt sich problemfrei crossbrowser implementieren – auch nicht in den sonst so hoch gelobten, 100% ACID 3 unterstützenden Vertretern Chrome oder Safari. Erschwerend hinzu kommt, dass man – zumindest soviel ich im Moment weiß – um JavaScript nicht herumkommt.

Nun kann ich mir einerseits auf die Schulter klopfen, wie schlau ich doch bin, weil ich das Problem in den Griff bekommen habe. Doch das kann nicht darüber hinwegtäuschen, dass die Implementation von Skiplinks im normalen Webdesign-Alltag eigentlich nicht mehr als eine Fingerübung sein sollte und kein für Einsteiger fast unüberwindlicher Stolperstein (wer bringt als Einsteiger schon JS- und DOM-Kenntnisse mit).

Doch so gern und trefflich die Blogosphäre sich auch über den IE6 und dessen Schwächen auslässt so gründlich wird in der Diskussion meist außer acht gelassen, dass auch andere Browser einem Alterungsprozess unterliegen. Wer testet denn heute noch ernsthaft seine Projekte gegen den Firefox 1, Safari 2 oder Opera 8? Der Firefox 1.0 beispielsweise stammt aus dem Jahre 2004 und hat damit ebenfalls bereits 5+ Jahre auf dem Buckel. Schon mal drüber nachgedacht?

In den Focus rückt diese Fragestellung bei mir durch Googles aktuelle Ankündigung, den IE6 bei den eigenen Applikationen nicht mehr zu unterstützen - worüber auch sofort wieder reichlich berichtet wird. Nur steht in Googles Ankündigung weit mehr als das Ende des IE6-Supports. Auch die nächste Generation der “Guten” - Firefox 2.x, Opera 9, Chrome 2.x usw. nähert sich dem Ende ihrer Unterstützung. Zwar findet man diese Aussage in dieser Deutlichkeit nicht in diesem Google-Blogpost, dafür beispielsweise bei Yahoo’s Aufstellung für den abgestuften Browsersupport der YUI Library.

Interessant an der Yahoo-Tabelle ist beispielsweise, dass selbst der Firefox 3.0 unter Windows Vista/7 bereits den A-Grade Status verloren hat. Von Opera ist generell nur die aktuelle Version 10 in der Liste vertreten und auch der Safari unter Mac nur in der aktuellen Version 4 gelistet wird. Alle älteren Versionen werden aktuell als B-Grade eingestuft. Sie werden selbstverständlich weiterhin unterstützt werden - jedoch bereits heute mit geringerer Priorität. Nun dreht es sich sowohl bei Google als auch bei Yahoo in allererster Linie um die JavaScript-Unterstützung/-Performance. In Sachen CSS ist es vor allem der Internet Explorer 6, der mit zahlreichen Bugs gesegnet ist, die Webentwicklern bei den immer komplexer werdenden Applikationen mehr und mehr zu schaffen machen. Doch auch bei den modernen Browsern werden die Unterschiede momentan eher größer als kleiner. Konkretes Beispiel: Die JavaScript-Performance des aktuellen Firefox 3.6 ist nicht einmal halb so gut wie die des Chrome 4. 

Abgestufter Browsersupport bei HTML5 & CSS3?

Die Frage, die ich deshalb in den Raum stellen möchte lautet: Wie geht man mit den älteren Generationen der “guten” Browser um? Ich klammere hier bewusst den IE 6 und 7 aus, mir geht es um Firefox 1.x,2.x,3.0.x, den Opera 8.x,9.x, den Chrome 1,2 oder auch Safari 1,2. Was die immer weiter wachsende Unterstützung für beispielsweise CSS3 und HTML5 angeht, so gibt es mit den älteren Generationen sicherlich weniger Probleme. Doch was ist mit waschechten CSS-Bugs?

Der Firefox 3.6 ist beispielsweise der erste Firefox überhaupt, der CSS-Tabellen endlich fehlerfrei darstellt. Alle seine Vorgänger hatten da so ihrer Schwierigkeiten. Der Firefox 2.x ließ teilweise Labels hinter Formularelementen verschwinden. Im Gegensatz zum Internet Explorer 6, der neben seinen zahlreichen CSS-Bugs ebenso zahlreiche Parser-Bugs mitlieferte, über deren Ausnutzung viele Probleme gefixt werden konnten, steht man bei den “guten” Browsern meist im Regen. Bugfixes für deren CSS-Probleme sind Mangelware. Mit der wachsenden Verbreitung von Firefox und Co. und den immer neuen Versionen/Generationen wird auch die Streubreite bei den Anwendern zunehmen und damit wird es zwangsläufig dazu kommen, dass diese Bugs “sichtbar” werden, wenn aktuelle Webtechnologien vermehrt Anwendung finden.

Wir beginnen gerade erst, die ersten graphischen Spielereien von CSS3 in unsere Projekte einzubauen. Ein falscher Schatten oder eine runde Ecke stellen in der Regel kein Problem dar. Doch wie sieht es aus, wenn wir damit beginnen, die neuen Layout-Module zu verwenden (Mehrspaltigkeit, Alternative Box-Modells, ect)? Das sind layoutkritische Elemente, was wenn hier Bugs auftreten, weil die ersten Implementationen noch nicht ausgereift waren - aber noch nicht vom Browsermarkt verschwunden sind?

Thema HTML5: Auch hier hat die Entwicklung deutlich an Fahrt gewonnen. Im letzten Jahr gab es reichlich Tutorials, wie HTML5 schon heute angewandt werden kann. Doch auch hier werden wir bei der aktuellen Geschwindigkeit Mühe haben, dass ältere Browsergenerationen von FF und Co. bereits aus den Statistiken verschwunden sind, bevor wir damit richtig anfangen zu arbeiten - oder wir warten bis 2020 (das will niemand wirklich, oder?). Dem Firefox 2 kann man nur sehr mühevoll den Umgang mit den neuen Elementen beibringen, vernünftiges Styling ist fast unmöglich. Für den IE7 und 8 gilt das gleiche, doch beide werden uns vermutlich noch eine ganze Weile begleiten.

Es bleibt spannend und unberechenbar ...

In die Browserwelt ist sichtlich Bewegung gekommen. HTML5 und CSS3 nehmen Woche für Woche weiter Fahrt auf. Die Performance-Entwicklung der JavaSript-Engines von Google, Safari und Opera (v10.5) eröffnet Möglichkeiten, die vor 1..2 Jahren noch völlig undenkbar waren - ganz unabhängig von den zahlreichen neuen Features, die uns durch jedes Browserupdate beschert werden. Jetzt also, wo der IE6 so langsam von der Bildfläche verschwindet, haben wir nicht zwingend Eitel Sonnenschein. Stattdessen wird sich der Focus einfach etwas verschieben, weg von dem einen zentralen Problembrowser hin zu den zahlreichen alten Browsergenerationen, welche die neuen Webtechnologien unzureichend oder fehlerhaft implementiert haben.

Nach so vielen vagen Gedanken würde mich Eure Meinung interessieren:

• Wie geht mit der wachsenden Versionsvielfalt und den damit verbundenen Leistungsunterschieden um?
• Wie reagiert Ihr auf Browserbugs, die sich nicht mehr so leicht fixen lassen, wie im guten alten Internet Explorer 6?
• Wie handhabt Ihr die unterschiedliche Unterstützung von Standards (HTML5, CSS3)?

Entfernen wir uns wieder von “Graceful Degradation” und “Progessive Enhancement” weil die Leistungsunterschiede im Vergleich zu heute tendentiell geringer werden oder bleiben wir als Webentwickler so tolerant wie bisher und sorgen uns in Zukunft auch um die älteren Guten, auch wenn deren Aufkommen in der Statistik geringer sein wird als es der IE6 momentan noch ist?

Wie schon im letzten Jahr war auch dieses Mal YAML wieder zahlreich unter den Finalisten und Preisträgern vertreten. Insgesamt 5 der 24 Webseiten im Finale des Wettbewerbs setzen auf das bekannte CSS-Framework, drei davon wurden letztlich mit einer Biene in Bronze prämiert.

Hier noch einmal die Finalisten und Preisträger mit YAML unter der Haube:

• Gemeinde Issum:www.issum.de – BIENE in Bronze (Kategorie ›Komplexe Informations- und Kommu­nikations­angebote‹)
• Stadt Nettetal: www.nettetal.de – BIENE in Bronze (Kategorie ›Komplexe Informations- und Kommu­nikations­angebote‹)
• Naturheilpraxis Angela Käßner: http://www.naturheilpraxis-kaessner.de – BIENE in Bronze (Kategorie ›Einfache Informations- und Kommu­nikations­angebote‹)
• Stadt Kevelaer: www.kevelaer.de (Kategorie ›Einfache Informations- und Kommu­nikations­angebote‹)
• Stadt Emmerich am Rhein: www.emmerich.de (Kategorie ›Einfache Informations- und Kommu­nikations­angebote‹)

Dabei steuert das YAML Framework nur einen kleinen Teil zur Barrierefreiheit einer Webseite bei, die Hauptarbeit liegt nach wie vor bei den verantwortlichen Webdesignern und Redakteuren, denn so aufwändig die Erstellung einer Webseite auch ist, stellt deren Betrieb mit regelmäßigen Anpassungen/Überarbeitungen und ständigen redaktionellen Änderungen die wahre Herausforderung dar, soll der hohe Qualitätsstandard dauerhaft gehalten werden. Als Technische Basis der verschiedenen YAML-basierten Seiten kamen die Framework-Versionen 2.5.x und 3.0.x zum Einsatz. Schon daran kann man erkennen, dass der Aufbau komplexer Informationsangebote viel Zeit in Anspruch nimmt, denn die Version 3.1 (Januar 2009) sowie die aktuelle Version 3.2 waren noch nicht vertreten. Damit aber genug dazu.

Besonders beeindruckend finde ich die Tatsache, dass trotz der gestiegenen Anforderungen an die Bewerber, vermehrt komplexe Angebote ins Finale einziehen und Preisträger werden. So konnten in diesem Jahr, der Webauftritt der DHL, das Online-Banking-Portal der Credite Suisse oder auch der SWR und die Zeit Online silberne Bienen mit nach Hause nehmen. Für den Webshop Manufaktum gab’s gar eine Biene in Gold.

Ebenfalls immer mit dabei sind die zahlreichen Kritiker, die Finalisten und Preisträger im Nachhinein sezieren und dabei immer wieder vermeintliche Haare in der Suppe finden. Sei es die mangelnde Validität oder die vergleichsweise schlichte Optik mancher Seite oder oder oder. Doch die Biene bewertet keine Photoshop-Künste, sondern Zugänglichkeit. Und so stellt die Riege der Finalisten und Preisträger einen aus meiner Sicht im Bezug auf die Designqualität einen durchaus repräsentativen Querschnitt aktueller Webseiten dar. Darunter sehr schöne Seiten wie www.bund.de oder die Zeit Online und daneben eben auch weniger schicke Angebote wie die des Hamburger Verkehrsverbundes (Biene in Bronze) oder der Stadt Suttgart. Hier mag dem einen oder anderen das Bling Bling  fehlen, dafür überzeugen alle diese Seiten mit hervorragender Zugänglichkeit, was viel zu viele Hochglanz-Webseiten nicht für sich in Anspruch nehmen können. Und an dieser Stelle vertraue ich der Jury, denn ins Finale kommt man nicht allein durch das Abarbeiten von Barrierefreiheits-Checklisten sondern die Seiten müssen sich in zahlreichen Nutzertests beweisen - Design hin oder her.

Allen Kritikern sei daher angeraten: Kritik ist erlaubt, schnödes Meckern ist nur peinlich. Aber wenn Ihr es besser wisst dann geht bei Euren eigenen Projekten mit gutem Beispiel voran und zeigt, dass es besser geht. Entwickelt charmante Lösungen, erstellt attraktive Webseiten, reicht diese zur Biene 2010 ein. Dann könnte der Anteil attraktiver Angebote weiter steigen und vielleicht hört dann auch endlich mal die BF-Szene damit auf, sich selbst der der Lächerlichkeit preiszugeben, indem permanent gegenüber Berufskollegen gemeckert und Preisträger seziert werden. Tomas Caspers hat es auf der diesjährigen Webtech-Konferenz auf den Punkt gebracht.

“Auch bei Beachtung der WCAG 2.0 und dem Einsatz moderner Webtechniken wie WAI-ARIA kann man dennoch an einzelnen Details scheitern. Doch passiert dies immernoch auf einem weitaus höheren Niveau als bei jenen, die sich aus Angst vor dem möglichen Scheitern gar nicht erst auf den Weg machen.”

Und genau so sehe ich das auch: Der Weg ist das Ziel.

Abschließend sei noch die Stadtbibliothek Marzahn-Hellersdorf erwähnt, die ebenfalls mit einer Biene in Silber ausgezeichnet wurde. Dieses Projekt wurde innerhalb von 3 Jahren ausschließlich von engagierten Mitarbeitern der Bibliothek realisiert – ganz ohne eine professionelle Agentur. Eine solche Leistung verdient höchsten Respekt.

Insbesondere das breitgefächerte Themenangebot hat es mir dieses Mal angetan. So umfasste mein persönlicher Sessionplan eine CMS-Diskussion, Rechtfragen in Social Networks, Rapid Prototyping mit jQuery, User Interface Design aus Spiele-Sicht, Erfahrungsberichte von Freelancern sowie zahlreiche kurze und einige längere Gespräche bei Kaffee und leckerem Kuchen. Ich selbst habe die Gelegenheit genutzt, nach ca. 8 Monaten und ca. 6000 Zeilen JS-Code ein erstes Feedback zu meinem aktuellen Projekt einzuholen.

Und abseits der Sessions sind Barcamps eben auch immer wieder eine tolle Gelegenheit, bekannte und unbekannte Gesichter zu treffen, sich auszutauschen und über alle möglichen und unmöglichen Dinge zu schwatzen. Und genau für diese entspannte Atmosphäre danke ich dem Orga-Team. Allen voran Darren Cooper, dessen herzerwärmende, lebensfrohe englische Art ich an zwei Abenden im #csshaus als Gast von Jens erleben durfte. Und so war ich denn einerseits etwas traurig, dass Sonntag 15:00 das Barcamp für mich bereits zu Ende war - mein Flieger nach Dresden wartete auf mich - andererseits bin ich selten so motiviert aus einer Veranstaltung gegangen wie dieses Mal.

Jederzeit gerne wieder ... wir sehen uns Mainz.

Die Vorgeschichte

Es begab sich im Sommer zu 2009, als ein aufstrebener Webentwickler, ich nenne ihn Herrn X. seine eigene Webseite neu einrichten wollte. Da die eigene Kreativität wohl gerade gemeinsam mit seinem Verstand auf Badeurlaub in der Karibik waren, griff Herr X. von jeglichen Hemmungen befreit in eine der unteren Schubladen des guten Benehmens, setzte seine copy & paste Mütze auf und streifte durchs Internet: Warum sich etwas neu ausdenken, was andere schon so übersichtlich und ansprechend hinbekommen haben? Letztlich sind wir doch eh eine große Familie im Web … und so fand er meine Webseite. Und diese gefiel ihm vom Aufbau und Design so einmalig gut, dass er seine ganz genauso aufgebaut und aussehen sollte. Nur hier und da einige winzige Änderungen – der individuellen Note wegen – ein Tüpfelchen Farbe hier und eine runde Ecke da, ganz dezent natürlich, die Vorlage war für ihn schließlich schon so nahe der Perfektion. Schön auch, dass ich seinerzeit einen längeren Blogbeitrag zu meinen Designentscheidungen verfasst hatte. Das hatte auch Herr X. bemerkt und erwähnenswerte Passagen kurzerhand in den Relaunch-Beitrag seines neuen Layouts übernommen.

Einige Monate später trug es sich zu, dass ich beim Sichten einiger Kommentare zufällig auf der schönen neuen Webseite des Herrn X. landete und dort ein ein selten-klares Déjà-vu erlebte. Das alles hatte ich schon mal gesehen … ja richtig, bei mir selbst. Und weil ich wenig begeistert war, die Mühen meiner Freizeit weitgehend deckungsgleich als das Aushängeschild des "professionell" arbeitenden Herrn X. wiederzuerkennen (einzelne Grafiken flossen sogar in eines seiner Referenzprojekte ein), kontaktierte ich Herrn X. per Skype um ihm mein Unbehagen bezüglich seines Handelns zu verdeutlichen. Herr X. berief sich im weiteren Verlauf auf selektiven Gedächtnisausfall ("Ich weiß nicht, was ich mir dabei gedacht habe.") gab jedoch nach mühsamer Diskussion, wie anders ein eigenständiges Layout denn mindestens sein müsse, letztlich doch nach und beseitigte das Problem weitgehend. Damit war das Thema aus der Welt und die Welt drehte sich langsam weiter…

Nicht daran anlehnen oder erinnern!

Letzten Samstag, nur knapp 4 Monate später bekam ich nun eine e-Mail von Herrn X. In dieser Mail sandte mir er mir sein kleines "HTML5/CSS Framework" zu mit der Bitte, es auf mögliche Verletzungen meiner Schutzrechte zu prüfen. Was für mich irgendwie merkwürdig klang, denn Zitat: "Selbstverständlich erreicht mein kleines Framework nicht die Komplexität von Yaml,  soll auch nicht daran anlehnen oder erinnern". Frage: Wenn es etwas nicht an YAML anlehnt oder auch nur daran erinnert, was und warum soll ich dann prüfen?

Die Frage beantwortete sich von selbst, nachdem ich einige Minuten im CSS dieses Projekts verbracht hatte. Der folgende Screenshot zeigt 5 Seiten eines kommentierten PDF’s mit CSS Code, zusammengefasst aus den drei Frameworkdateien (screen.css, print.css und patch.css), die ich Herrn X. zusammen mit meiner Sicht der Dinge zurückgesandt habe.

Zur Erläuterung: Die gelb markierten Bereiche sind dabei weitgehend 1:1 übernommene Passagen aus YAML (weitgehend, weil z.T. die erläuternden Kommtare fehlten). Die enthaltenen CSSDOC-Komentare stammten jedenfalls von mir. Beim verbleibenden Rest stimmten Selektorenabfolge und Eigenschaften zu 90% überein. In der Summe bilden die zusammenkopierten YAML-Brocken etwa den Stand von YAML 1.0, also die Basis für einen flexiblen 3-Spalter. Crossbrowser funktionstüchtig ist das Ergebnis leider dennoch nur bedingt, da mein Bugfix-Konzept wohl nicht gänzlich verstanden wurde und deshalb von einzelnen Bugfixes nur Teile übernommen wurden (was im konkreten Fall wirklich unschöne Auswirkungen hat) oder falsch angewandt wurden. Selbst die JS-Expression aus dem YAML-Builder zur Simulation von min-/max-width (deren dynamische Generierung mir während er Anfangszeit meiner JS-Programmierung doch etwas Mühe bereitet hat) gelangte ohne Umwege in dieses Projekt.

Die rosa eingefärbten Bereiche dokumentieren echte Eigenleistung des Herrn X. Inhaltlich beschränken sich diese jedoch darauf, dem YAML-Rohbau ein Screenlayout, bestehend aus zahlreichen runden Ecken und Dropshadows zu verpassen. Die einzige wirkliche Änderung des gesamten Projekts bestand darin, im Markup die vier Standard DIV’s #header, #footer, #col1 und #col2 gegen die entsprechenden HTML5-Elemente header, footer, article und aside auszutauschen. Die dafür notwendigen Arbeitsschritte erledigt man mit der Suchen/Ersetzen Funktion eines Texteditor innerhalb von Minuten. Ist das also die Kreativität, die etwas Neues, Eigenständiges hervorbringt? Der Code und das Konzept, welches YAML als CSS-Framework seit Beginn definieren, wurde – soweit vollständig – unverändert übernommen. Das "neue" CSS ersetzt lediglich das schichte, himmelblaue Screendesign der mitgelieferten Layoutbeispiele, die Markupänderungen kommen einer simplen Umbenennung gleich. Und dennoch steht das Gesamtpaket plötzlich unter dem Copyright von Herrn X. Als Überblick soll das an dieser Stelle genügen.

Ich erlebe diese Dinge leider nicht zum ersten Mal. Nicht jedes Mal habe ich darüber gebloggt wenn meine Arbeit unverändert und in großem Umfang kopiert unter fremdem Copyright auftauchte. Aber es ist das erste Mal, dass jemand so dreist ist, mir den Code unter seinem Namen auch noch zur Begutachtung und Freigabe unter die Nase zu halten. Um ein paar weitere Zitate aus der e-Mail zu bemühen…

• "Solltest Du widererwarten etwas daran auszusetzen haben, …"
• "Solltest Du noch evtl. eine Anregung haben, wäre ich auch dafür sehr dankbar!"

Ich sollte die Fragmente meiner eigenen Arbeit reviewen und Anregungen geben? Kommt das vielleicht außer mir noch jemanden seltsam vor?

Ich hatte eigentlich vor, diesen Beitrag ähnlich leicht verdaulich zu schreiben wie den des letzten Jahres. Doch der damals zurecht gescholtene Herr K.  war ein Freizeit-Bastler mit etwas falschen Vorstellungen von e-Commerce. Dieses Mal sieht es anders aus. Herr X. erschien im Frühjahr 2009 auf der Webstandards-Bühne und ist seither intensiv bestrebt, sich als professioneller Webdesigner zu profilieren. Zum wiederholten Male (siehe Vorgeschichte) versucht er das nicht mit eigenen Ideen oder eigenen Lösungen, sondern auf Basis meiner Arbeit. Und es zieht einem sprichwörtlich die Schuhe aus, wenn ich – angesprochen auf diese Dreistigkeit – in seiner Antwort lesen darf, dass bei meiner Einschätzung der Lage ja wohl nicht alles so ganz stimmt – Kommentare und Bugfixes aber wohl kopiert wären. Weiterhin sei er völlig überrascht von der frapierenden Ähnlichkeit, die selbstredend nicht beabsichtigt wäre. Warum wird die unverkennbare Herkunft dann aber bereits in der ersten Mail bereits durch die Blume angedeuetet? Er habe, Zitat: "…übrigens nach CSSDOC so gut dokumentiert, wie es mir möglich war." Schön wär’s. Er hat nicht etwa versucht, die Funktion der jeweiligen Codeabschnitte mit eigenen Worten wiederzugeben, stattdessen finde ich überall meine eigenen, zweisprachig verfassten Kommentare vor – unverändert.

Rhetorische Frage: Wenn man aus einer Kiste mit fünf Äpfeln drei herausnimmt und in eine andere, leere Kiste legt, liegt der neuen Kiste plötzlich ein Glas Gurken oder liegen da drei Äpfel?

Was ist die eigene Arbeit wert?

Bezüglich der Motivation kann ich natürlich nur raten. Aus meiner Sicht stand nicht ein besseres Framework oder der Test einer neuen Idee im Vordergrund. Das Ziel war, schnell etwas Eigenes zum Vorzeigen zu haben – was leider nicht aus eigener Kraft schaffbar war.

Um Missverständnissen vorzubeugen: Der Sprachumfang von CSS ist begrenzt und niemand erfindet mal eben neue CSS-Selektoren oder Eigenschaften. Wir alle stützen unsere Entwicklungen auf Bekanntes, auf die Vorarbeiten kreativer Köpfe (on the shoulder of giants). Etwas Neues entsteht dann, wenn Bekanntes neu miteinander kombiniert wird, um neue Ideen/Konzepte zu verwirklichen, Probleme zu lösen. Es gibt mehr als ein Dutzend CSS-Frameworks und jedes besitzt eine eigenständige Codebasis. Selbst innerhalb des Gridkonzepts kommen Blueprint und 960.gs zu grundlegend verschiedenen Lösungen, obwohl alle nur mit scheinbar "simplen Bausteinen" wie floatenden Divs und z.B. dem Clearfix-Hack arbeiten. YUI oder OOCSS sehen wiederum völlig anders aus. Das übergeordnete Konzept und dessen individuelle Implementation machen aus der bloßen Ansammlung von CSS-Deklarationen etwas Neues, Eigenständiges. In diesen Fällen CSS-Frameworks. Und wenn ein neues Konzept die Basis einer Entwicklung bildet, dann kann die großzügige Codeübernahme per copy & paste aus anderen Projekten gar nicht funktionieren, denn die kopierten Codeschnipsel würden ganz einfach nicht unverändert in das neue Konzept passen.

Was Herr X. hier abzieht, hat mit diesem Grundverständnis selbstständiger, kreativer Arbeit nichts zu tun. HTML/CSS-Teile zu übernehmen, sich von eleganten Lösungen inspirieren zu lassen, ist nichts Verwerfliches. Aber es besteht nach meinem Verständnis ein entscheidender Unterschied darin, ob dies lediglich der Problemlösung und der eigenen Weiterbildung dient oder ob man fremde Arbeit achtlos kopiert und als eigene Kreativleistung ausgibt und/oder verkauft.

Zum Glück sind dies Ausnahmen, dennoch fällt es schwer, ruhig zu bleiben. Aber auch dafür ist dieses Blog eben da und ich hoffe, für die nächsten Monate wieder mit angenehmeren Themen aufwarten zu können.

PS: Da ich kein Interesse verspüre, Herrn X. weitere Aufmerksamkeit zukommen zu lassen, verzichte ich auf Namen und Verlinkung. Ich bitte meine Leserschaft, dies auch in eventuellen Kommentaren hier im Blog zu respektieren.

Schlankerer Framework-Core

Die wichtigste Änderung gleich zu Beginn: YAML besteht nunmehr nur noch aus zwei Kernbausteinen. Die base.css ist das Herzstück des Frameworks und stellt dem Nutzer ein schonendes Browser-Reset, oft benötige CSS-Klassen für die Layouterstellung (Float Clearing, Skiplinks, ect.), die “Subtemplates” als flexible Grid-Bausteine, ein universelles Fallback auf ein dreispaltiges Basislayout und wichtige Vorgaben für eine fehlerfreie Druckausgabe bereit. Über den zweiten Baustein, die iehacks.css werden die älteren Versionen des Internet Explorers 5.x bis 7.0 mit Bugfixes versorgt, die so formuliert sind, dass sie ohne Eingreifen des Anwenders den überwiegenden Teil der CSS-Bugs dieser Browser korrigieren. Der ehemaliige dritte Baustein, die print_base.css ist in der base.css aufgegangen.

Eine Umstrukturierung der medienspezifischen Definitionen innerhalb der base.css ermöglichte weiterhin einige Vereinfachungen der Codebasis, sodass trotz der Erweiterung der Grid-Komponente der gesamte Framework-Core insgesamt fast 600 Byte (ca. 10%) kleiner geworden ist. Mit den Wegfall der print_base.css kann zudem ein HTTP-Request eingespart werden (zumindest, wenn man die finalen Stylesheets nicht zusammenfasst) und in modernen Browsern wie dem Internet Explorer 8, Firefox, Opera, der Safari benötigt der YAML-Core nur noch 2,34 kB (slim_base.css). Ausschließlich die veralteten Versionen des Internet Explorers 5.x – IE 7.0 müssen den vollständige Core mit 5,04 kB laden.

Neue Features & Altlastenentsorgung

Wie mit fast jeder YAML-Version wird auch mit YAML 3.2 der Funktionsumfang des Frameworks leicht erweitert. Die Subtemplates (die Grid-Komponente von YAML) erhält vier weitere Unterteilungen (20%, 40%, 60% und 80%). Selbstverständlich besteht auch hier die Möglichkeit, gleiche Containerhöhen über die Klasse .equalize zu erzwingen. Daneben steht mit einem weiteren Add-on, dem SyncHeight-Plugin für jQuery, eine JavaScript-Alternative für das Erzwingen gleichhoher Container zur Verfügung.

Der Formularbaukasten ist ebenfalls flexibler geworden. So ist die Klasse .yform nicht mehr an das form-Element gebunden, was den Einsatz in Content Management Systemen wie z.B. ExpressionEngine vereinfacht, bei denen der form-Tag automatisch vom CMS generiert wird. Die zusätzliche Darstellungsklasse .full hilft bei Platzproblemen (schmale Formulare) und erzeugt Input-, Select-Felder und Textareas mit voller Breite des umgebenden Elternelementes. Ein neues Layoutbeispiel demonstriert, wie einfach und komfortabel sich mehrspaltige Formulare mit YAML erstellen lassen.

Neben diesen neuen Möglichkeiten, wurden mit diesem Release auch einige Altlasten beseitigt. So wurden die IE-Fixes für die ehemaligen ID’s #page_margins und #page aus der iehacks.css entfernt. Beide ID’s werden seit YAML 3.1 (Januar 2009) in mehrfach verwendbare Klassen umgewidmet. Einen echten Feature-Drop betrifft der Verzicht auf die Möglichkeit, Spaltenhintergründe mit Hilfe der Border-Definition von #col3 zu erzeugen. Zwar ist diese Technik denkbar einfach in der Umsetzung, sie beschwört aber in Verbindung mit den Windows-Kontrastmodi ein Zugänglichkeitsproblem herauf, da in diesen Modi Vordergrund- und Rahmenfarben auf den gleichen Farbwert gesetzt werden, infolgedessen Inhalte mit dahinterliegenden farbigen Rahmen (den simulierten Spaltenhintergründen) z.T. nicht mehr lesbar sind. Erschwerend kam hinzu, dass diese Technik im Internet Explorer ein Anpassung des z-index von #col3 bedurfte, was in seltenen Fällen das Selektieren von Inhalten mit der Maus im Browser blockierte.

Ein oft diskutierter Punkt unter vielen Framework-Anwendern war bisher der Workaround zur Vermeidung seitlich springender, zentierter Layouts im Firefox und Safari durch Erzwingen eines vertikalen Scrollbalkens. Mit der Veröffentlichung der neuen Browsergenerationen Internet Explorer 8, Firefox 3.5, Safari 4 und Opera 10 wurde die bisherige Lösung unbrauchbar und deshalb aus dem Core entfernt. An ihre Stelle tritt eine CSS3-basierte Lösung (overflow-y: scroll), welche nunmehr in den Nutzerstylesheets (basemod.css) verankert ist und somit von jedem Anwender bei Nicht-Gefallen einfach deaktiviert/entfernt werden kann.

Ebenfalls ersatzlos gestrichen wurde das Debug-Stylesheet (debug.css), welches mit der Version 3.0 Einzug in das Framework gehalten hatte. Zu sehr litt die Übersicht bei der Vielzahl der gleichzeitig eingeblendeten Informationen. Die fehlende Konfigurierbarkeit und die umständlichen Handhabung waren ebenfalls nicht vorteilhaft. Mit dem bereits im Febuar 2009 veröffentlichten Codeanalyse-Tool YAML Debug steht YAML-Entwicklern eine deutlich bessere und vielseitigere Alternative zur Verfügung, die mit einem einzigen Klick jedes Layout analysiert.

Handwerkszeug für die Barrierefreiheit

Kein Framework, auch nicht YAML, ist ein Garant für barrierefreie Webseiten. Dennoch zeigt sich mehr und mehr, wie sinnvoll und richtig es ist, Webentwicklern das grundlegende Handwerkszeug innerhalb des Frameworks zur Verfügung zu stellen. In YAML 3.2 wird eine neue Darstellungsmöglichkeit für Skiplinks unterstützt, die ein Überlagern des Layouts für die eingeblendeten Skiplinks ermöglicht und dadurch die sonst üblichen Probleme bei deren Integration beseitigt. Zudem wird für Webkit-basierte Browser ein JavaScript-Fix mitgeliefert, um auch Apple’s Safari und Google Chrome dazu zu bewegen, den Focus auf die angesprungene ID zu setzen.

Ein weiterer Schritt ist die konsequente Einbeziehung von WAI-ARIA. Sämtliche bei YAML mitgelieferte Beispiellayouts wurden mit ARIA-Landmarkroles versehen. Zwar handelt es sich hierbei nicht wirklich um ein Feature des Frameworks (die korrekte Auszeichnung sollte der Webentwicklers vornehmen), dennoch halte ich auch diesen Schritt für wichtig, um als Framework-Entwickler trotz der noch fehlenden Validierungsmöglichkeiten im W3C-Validator die positiven Effekte des kommenden Standards hervorzuheben. Schon heute können alle modernen Browser (einschließlich des IE8) mit WAI-ARIA umgehen und ermöglichen somit einen deutlichen Zugewinn an Barrierefreiheit auf Webseiten jeder Komplexitätsstufe.

Das “Accessible Tabs” Plugin von Dirk Ginader wird mit YAML 3.2 als Add-on ein fester Bestandteil des Frameworks. Das dahinter stehende Konzept habe ich zusammen mit Dirk Ginader bereits vor zwei Jahren entwickelt, die Umsetzung im Rahmen dieses Plugins ist mittlerweile ausgereift und umfangreich getestet. Auch dieser Baustein ist weniger als Feature des Frameworks zu sehen. Stattdessen bemühe ich mich darum, zusammen mit YAML sinnvolle Best-Practice-Lösungen zu vermitteln und die Verbreitung dieser Techniken zu fördern.

Zusammenfassung

Neben diesen großen Neuerungen/Verbesserungen stehen zahlreiche kleinere Korrekturen hier und da, über die das Changelog im Detail Ausfunft gibt. Wie mit jedem Release wurde auch die Projektvorlage “Simple Project” auf den aktuellen Stand gebracht.Der YAML Builder beherrscht momentan WAI-ARIA noch nicht und auch die neue Skiplink-Variante ist dort noch nicht implementiert, die Codeausgabe ist aber selbstverständlich kompatibel zu YAML 3.2.

Der Release-Zyklus war diesmal deutlich länger, zudem zwischen v3.1 und v3.2 keine sogenannten Maintenance-Releases eingeschoben wurden. Der Hauptgrund hierfür lag in der eng gestaffelten Veröffentlichung der aktuellen Browsergeneration, angefangen mit dem Internet Explorer 8 im Frühjahr 2009. Gerade bei diesem war es wichtig, die zuverlässige Funktion der Kernfunktionen des Frameworks ohne jegliche Hacks zu überprüfen. Nach nunmehr einem halben Jahr lässt sich dieser Fakt bestätigen. Einzig bei der Darstellung von Formularen benötigt der Internet Explorer 8 noch wenige individuelle Hilfestellung, die notwendigen Anpassungen kennt der Formularbaukasten jedoch.

Daneben stellt das 3.2-Release für mich eine weitere Schärfung des Profils von YAML hinsichtlich des modularen Aufbaus auf Basis eines sehr schlanken Kerns und der Focussierung auf flexible, barrierefreie Webseiten dar. Und die Entwicklung geht weiter ...

Im Grunde ist der Umstieg auf Adobe AIR nicht weiter schwer und so bringt die AIR Applikation gleich mehrere Vorteile mit sich. Zum einen ist kein Flash-Plugin mehr erforderlich denn AIR bringt eine native Unterstützung zur Befütterung des Clipboards mit. Zum zweiten – und das dürfte der interessantere Punkt sein – hat man in einer Adobe AIR Applikation Zugriff auf das lokale Filesystem. Und drittens benötigen AIR Applikationen keinen Browser und auch keine Internetanbindung mehr, womit sich auch die Anwenderfreundlichkeit weiter erhöhen dürfte.

Der Screenshot des experimentellen YAML Builders unter AIR zeigt deshalb bereits ein neues Feature, den vollständigen Exports des YAML-Projekts in ein lokales Nutzerverzeichnis. Die copy & paste Orgien könnten damit der Vergangenheit angehören. Der vom Builder generierte Code kann mit einem Klick lokal gesichert werden als indiviudell konfiguriertes “Simple Project”. Parallel steht die Clipboard-Ausgabe einzelner Files weiterhin zur Verfügung.

Das ist zunächt einmal ein Testbalon – zu einer stabilen Version ist noch ein Stückchen hin. Im nächsten Schritt werde ich mir anschauen müssen, wie unter AIR die Versionsverwaltung und automatische Updates funktionieren, sonst macht eine solche Applikation auf Dauer keinen Sinn. Das ist der Vorteil eines Online-Dienstes, hier hat man immer volle Versionskontrolle.

Natürlich schreibe ich diesen Blogbeitrag nicht grundlos. Ich möchte Feedback zu dieser Idee an sich und weitere Tipps für kleine Änderungen, welche bei dieser Gelegenheit gegebenenfalls am Builder vorgenommen werden könnten/sollten. Falls jemand der Mitlesenden bereits Erfahrungen mit Adobe AIR gesammelt hat wäre ich ebenfalls dankbar, wenn ich gelegentlich die eine oder andere Frage loswerden könnte, die sich sicherlich noch auftun wird.

Zum Thema CSS-Sprites gibt es weiterhin eine kleine Demo von David, welche er soeben online bereit gestellt hat.

Weitere Vorträge im Netz:

• Jan Eric Hellbusch, “WCAG 2.0 und BITV2 für Einsteiger”
• Jens Meiert: HTML5: Barrierefreiheit, Performance, Wartbarkeit
• Christian Heilmann: Barrierefreiheit im Datennetz