Weblog

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.

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.

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

Leider ist die Implementation dieser interessanten und nützlichen Funktion in Wordpress eher unglücklich gelöst. Die Jungs von WPEngineer haben bereits im Februar vorbildlich darüber informiert, welche Klassennamen das Tag ins Markup rendert. Darunter befinden sich zahlreiche allgemein gebräuchliche Klassenbezeichnungen wie:

• archive
• author
• blog
• category
• date
• home
• page
• search
• tag

Das Problem bei der Verwendung derart gebräuchlichen Bezeichnungen sind fast zwangsläufig Kollisionen bei der Implementation bestehender CSS-Layouts in Wordpress. Gerade heute habe ich eine Mail zu diesem Thema bekommen:

Man kann sich ja mittlerweile im BODY-Tag CSS-Klassen einfügen lassen je nachdem welcher Typ von Seite aktuelle von WordPress ausgegeben wird. Dabei gibt es auch die Klasse “page” für die Seiten in WordPress. Resultat ist, dass sich das dann mit der Klasse “page” aus YAML überschneidet.

Ich kann im Moment froh sein, dass es nur eine CSS-Klasse von YAML trifft. Schon innerhalb dieses Bloglayouts hier – würde dieses Blog mit Wordpress laufen – würden weitere Klassenbezeichnungen kollidieren, denn ich verwende in meinem Bloglayout auch Klassenbezeichnungen wie “date” oder “category”. Nur sind diese Klassen in meinem Layout nicht dafür gedacht, an das body-Element geheftet zu werden. Nun könnte ich mein CSS-Framework YAML in einer nächsten Version natürlich anpassen, um der Kollision aus dem Wege zu gehen, aber ich halte dies für den falschen Weg, denn die Welt dreht sich nicht um Wordpress und YAML ist nicht allein von diesem Problem betroffen. Wordpress als Blogtool oder CMS sollte eigenständig kein Markup generieren (soweit die graue Theorie) und es sollte ebenso die Implementation bestehender Layouts nicht durch die Kollision von Klassennamen unnötig erschweren.

Ein relativ einfacher und unkomplizierter Lösungsweg heisst: Namespacing. Wordpress könnte allen dynamisch ins Markup generierten CSS-Klassen das Kürzel “wp-” voranstellen (oder dieses sogar im Backend konfigurierbar machen). Bei anderen Content Management Systemen (Bsp: TYPO3) kommt dieses Verfahren bei den meisten Extensions zum Einsatz. Auf diese Weise ließen sich die angedeuteten Probleme leicht vermeiden, während die durchaus sinnvolle Funktionalität weiterhin uneingeschränkt verfügbar bleibt. Leider bin ich selbst zu wenig bewandert in PHP und auch nur ein Gelegenheitsnutzer von Wordpress, dennoch hoffe ich, dass diese Idee auf irgendeinem Kanal an das Entwicklerteam herangetragen wird.

Das Rendering der CSS-Tabellen funktioniert prinzipiell, es ist also kein einfacher CSS-Bug. Ich verwende diese Technik in YAML zur Erstellung gleichhoher Container per CSS. Das eigentlich perverse an diesem Bug - er ist extrem schwer nachvollziehbar. Ich habe die CSS-Tabellen mittlerweile in mehreren Real-Live-Situationen ausprobiert und dabei bereits im Winter erstmals Bekanntschaft mit diesem Bug gemacht. Allerdings war die Fehldarstellung meist nach einem Reload oder auch nur dem Versuch eines Elementchecks mit Firebug verschwunden. Die Ursachenfindung hat das extrem erschwert. Erst vor einigen Wochen hat dann im YAML-Forum ein User einen weiteren Tipp beigesteuert, der letztlich einen Testcase ermöglichte.

Gestern Abend habe ich mich nochmals hingesetzt und endlich einen - zumindest bei mir - funktionierenden Testcase erstellt, sowie den Bug bei Bugzilla gemeldet (Bug 510350) . Die Einzelheiten zum Wie und Warum sind übrigens im Testcase ausführlich beschrieben.

Im Testcase wird der Bug durch eine fast leere Script-Node getriggert, wobei diese hier direkt im HTML-Code der Tabelle steht. Es ist die einzige halbwegs verlässliche Möglichkeit, den Bug zu erzwingen, die ich kenne. In meinen Real-Life-Layouts reichte meist schon die pure Anwesenheit von JavaScript in Form von jQuery oder sonstigem.

Und abschließend: Dieser Bug ist derart fies, dass sein Auftreten auf wundersame Weise sogar vom Dateinamen des Testcases beeinflusst wird. Auf meinem lokalen Rechner tritt der Bug - genau wie in der Netzversion - sporadisch auf. Wenn ich den Testcase jedoch in “index.html” umbenenne, wird er plötzlich permanent getriggert. Das verstehe wer will. Ich hoffe daher, die Mozilla-Jungs finden und eleminieren die Ursache möglichst schnell.