Weblog

Sublime Text 2 kommt mit einer ganzen Reihe verschiedener Color-Schemes daher. Ich persönlich mag dunkle UIs, weil ich oft bis tief in die Nacht programmiere und kann das Monokai-Theme empfehlen (gibt’s übrigens auch für Coda).

Eines der Highlights des Editors sind die zahlreichen Plugins. Zunächst solltet Ihr Euch aber Package Control installieren, einen bequemen Paket-Manager für Sublime Text 2. Über diesen könnt Ihr dann bequem aus Liste die zu installierenden Pakete auswählen, die Installation geschieht in der Regel vollautomatisch. Als Empfehlung hier eine kleine Auswahl der bei mir installierten Pakete:

• Alignment - erleichtert die Ausrichtung des Quelltextes, z.B. vertikale Ausrichtung an Gleichheitszeichen
• BracketHighlighter - Hervorhebung zusammengehöriger Klammern
• Sublime JSLint - vollautomatisiertes Linting für JavaScript Code aus dem Editor heraus. Bequemer geht es nicht mehr
• Tortoise - Speziell für Windows User interessant, erweitert es den Editor um Menüeinträge und Keyboard-Shortcuts zur Ansteuerung von Tortoise, dem defakto Standard-SVN-Client unter Windows
• Zen Coding - komplexes Plugin zur Code-Vervollständigung für HTML & CSS

JSLint Konfiguration

Obgleich das JSLint Plugin auf Anbieb funktioniert (um eine Java-Runtime braucht man sich nicht kümmern, die kommt gleich mit), ist es dennoch sinnvoll, dem Linter ein wenig Wind aus den Segeln zu nehmen, um nicht von tausenden angeblichen Fehlermeldungen zugeschüttet zu werden. Die Konfiguration erfolgt über ein Config-File, welches man im Editor selbst über Preferences->Package-Settings->JSLint->Settings-Default erreicht.

Unter “jslint_options” kann man hier den Linter entsprechend der eigenen Vorlieben anpassen. Folgende Optionen habe ich gesetzt:

—predef $,document

Wer wie ich viel mit jQuery arbeitet, wird um die Option predef nicht herumkommen. Sie dient dazu, JSLint über globale Variablen zu informieren, auf die der zu prüfende Code zugreift und deren Benutzung somit nicht als Fehler gewertet wird. Für jQuery sind das mindestens $, bzw. jQuery und document.

—white

Ist meinem persönlichen Coding-Stil geschuldet, dass ich nicht von JSLint über die Verwendung von Leerzeichen belehrt werden will.

—browser

Damit werden typische gobale Variablen der Browser verfügbar, z.B. window.

—sloppy

Sollte immer aktiviert werden, solange man noch nicht mit “use strict”; arbeitet.

Das ganze sieht dann fertig so aus:

// Options pass to jslint.
"jslint_options": "--predef $,document --white --sloppy --browser"

Eine vollständige Liste der Optionen gibt es hier. Hat man das hinter sich gebracht, kann man den Linter jederzeit mit Crtl+J anschmeißen und sich anschließend gemütlich durch die Fehlerliste navigieren. So bequem hatte ich es bisher in keinem Editor.

Ein Beispiel: In allen drei Varianten ist der gleiche Tag gemeint – ohne die Landeszuordnung dahinter, ist eine eindeutige Zuordnung von Tag und Monat gar nicht so einfach.

• 6/15/2009 (en-US)
• 15/06/2009 (fr-FR)
• 2009/06/15 (ja-JP)

Um diesem Problem zu begegnen, unterstützen alle halbwegs modernen Browser (und damit auch der IE) die Methode Date.toLocaleString(), welche Datum & Zeit anhand der Browsereinstellungen im jeweils landestypischen Format ausgibt. Aus dem eher hässlichen Standard-GMT-String “Mon Jul 18 2011 11:56:29 GMT+0200” wird hierzulande “Montag, 18. Juli 2011 11:56:29”.

Weniger schön ist, dass im Chromium-Projekt seit langer Zeit ein ungefixter Bug (Issue 29779, eingetragen im Dezember 2009) schlummert, der statt “Monday, 18 January 2010 4:47:42 PM” eine solche Ausgabe provoziert “Mon Jan 18 2010 16:47:42 GMT+1100 (AUS Eastern Daylight Time) “. Nicht nur, dass keine Umformung in ein lokales Datumsformat stattfindet, durch die zusätzliche ausformulierte Zeitzonen-Angabe wird der String sogar noch länger und damit schwerer zu handhaben. Und da sich sowohl Google Chrome als auch Safari bei diesem Projekt bedienen, erben die beide Browser eben jenese Problem.

Ein Workaround – der eigentliche Aufhänger für diesen Blogpost –  ist dabei gar nicht schwer. Denn das was Date.toLocaleString() ausgibt, ist lediglich eine Aneinanderreihung von lokalem Datum ( Date.toLocaleDateString() ) und lokalem Zeitformat ( Date.toLocaleTimeString() ) und für beides gibt es spezielle – und vor allem bugfreie – Methoden. Also einfach die beiden Einzelstrings miteinander verketten und fertig.

var date = new Date();
var localeString = date.toLocaleDateString()+" "+date.toLocaleTimeString();

Ich hoffe, dem einen oder anderen hilft dieser kleine Tipp.

Wenn man ein wenig Erfahrung aus anderen Programmiersprachen wie C mitbringt, dann ist einem der Unterschied zwischen einem Objekt und dem Pointer auf ein Objekt bekannt. Das entscheidende dabei: Bei C kann man sehr einfach festlegen, ob man einer Variable eine Objektkopie zuweist oder nur einen Pointer auf das Originalobjekt erzeugt. Bei JavaScript sieht das etwas anders aus.

Obgleich in JavaScript so ziemlich alles als Objekt betrachtet werden kann, so gibt es doch feine aber entscheidene Unterschiede, wie diese intern behandelt werden. Folgender Code machte mich stutzig:

var layoutCSS = {
    'width': 'auto',
    'min-width': '720px',
    'max-width': '80em'
};
var minSettings = layoutCSS;
minSettings['max-width'] = 'none';
console.log(minSettings); //"none"
console.log(layoutCSS); //"none"

Wie man sieht, wird in diesem Beispiel nicht etwa eine Kopie des Objekts layoutCSS in minSettings angelegt, sondern lediglich ein Pointer auf das Originalobjekt. In der Konsequenz ändert sich der Inhalt des OriginalObjekts layoutCSS bei Zuweisungen an minWidth. Gut zu wissen, denn in JavaScript ist dieses Verhalten auf Arrays und Objekte begrenzt. Strings hingegen werden kopiert, obwohl sie intern ebenfalls wie Objekte behandelt werden. Aufklärung darüber, wie JavaScript mit Pointern umgeht, liefert der Artikel Understanding Pointers in JavaScript.

Soweit so nervig gewöhnungsbedürftig. Wie aber kommt man jetzt zu seiner Kopie bzw. Clone eines Arrays oder eines Objekts? Leider ist es auch hier so – ähnlich wie beim Versuch, ein assoziatives Array zu sortieren – dass JavaScript den Programmierer bei dieser Frage weitgehend im Stich läst. Handarbeit ist demnach angesagt. Einen ersten Lösungsansatz liefert der Artikel von Brian Huisman "How to copy arrays and objects in Javascript", der eine .clone() Methode einführt:

Object.prototype.clone = function() {
  var newObj = (this instanceof Array) ? [] : {};
  for (item in this) {
    if (item == 'clone') continue;
    if (this[item] && typeof this[item] == "object") {
      newObj[item] = this[item].clone();
    } else newObj[item] = this[item]
  } return newObj;
};

Speziell für jQuery-Nutzer gibts von John Resig höchstpersönlich noch einen kürzeren Vorschlag über die jQuery.extend():

// Shallow copy
var newObject = jQuery.extend({}, oldObject);

// Deep copy
var newObject = jQuery.extend(true, {}, oldObject);

Zwar finde ich persönlich diese Inkonsistenz bei JavaScript etwas nervig, dass man selbst nicht über Kopie oder Pointer wählen kann, aber was soll's. Wenigstens gibt es halbwegs einfache Lösungswege aus diesem Dilemma. An dieser Stelle ein ganz dickes Dankeschön an das kalifornische JavaScript-Lexikon Dirk Ginader, der mir mit diesen Links den Abend gerettet hat.

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.

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