Zunächst muss man den Schlüssel konvertieren, dass geschieht mit dem Programm PuTTYgen. Unter Ubuntu installiert man das wie folgt:

$ sudo apt-get install putty-tools

Dann konvertiert man den Schlüssel, und speichert diesen unter dem .ssh-Ordner im Home-Verzeichnis ab.

cd /path/to/orginalkey/
puttygen orginalkey.ppk -O private-openssh -o mynewkeyfile.sec
mv mynewkeyfile.sec ~/.ssh/
chmod 600 ~/.ssh/mynewkeyfile.sec

Damit die Schlüssel auch akzeptiert werden, gelten bestimmte Zugriffsrechte für das .ssh Verzeichnis (700) und die darin liegenden Dateien (600). In dieser Form funktioniert der Schlüssel, und man kann sich verbinden:

ssh MyUserName@hostname.de -i ~/.ssh/mynewkeyfile.sec

Soweit so gut, nun kann man den Komfort noch erhöhen. Dafür legt man eine config Datei im .ssh Verzeichnis an, in dem man die Verbindungsparameter dauerhaft speichert:

sudo gedit ~/.ssh/config

Eine genaue Anleitung findet man auf der entsprechenden man-page von ssh_config. Hier ein einfaches Beispiel:

Host mySSHConnection
    HostName 123.456.789.0
    Port 980
    User MyUserName
    IdentityFile ~/.ssh/mynewkeyfile.sec
    DynamicForward 1234

Die letzte Anweisung emuliert per SSH einen SOCKS 5-Proxy, der in meinem Falle ebenfalls nötig war. Man muss in seinem Browser lediglich die Verbindung entsprechend anpassen, das geschieht im Firefox bspw. über Bearbeiten > Netzwerk > Einstellungen. Dort die Angabe für Manuelle Proxy Konfiguration, als SOCKS Host die 127.0.0.1 und als Port den Wert des DynamicForward eintragen. Jetzt kann man sich im Terminal über den folgenden Befehl per SSH mit dem Server verbinden:

ssh mySSHConnection

Wer auf der Unity Oberfläche von Ubuntu unterwegs ist, kann sich noch folgende Launcher Erweiterung ansehen: Gnome-Terminal Quicklist (auto-update from ssh config), damit kann man die in der Konfiguration gespeicherten SSH Verbindungen direkt in seinen Terminal Launcher integrieren.

Eine Lösung für die gleiche Problematik auf einem Mac findet man unter leadingedgescripts.co.uk.

Eine triviale Aufgabe: ein Datum validieren und mit einem anderen Datum vergleichen, dabei kann das Datum eine gewisse Varianz in der Reihenfolge und Schreibweise haben. Ich betrachtete kurz die bereits implementierte Bestandslösung für die Validierung und war erstaunt über das mühsame Arbeiten mit substr. Das kann man doch eleganter lösen: Ein regulärer Ausdruck für die Validierung, dient gleichzeitig der Zerlegung des Datums, um daraus dann ein Date Objekt für den Vergleich zu erstellen:

// eine Pruefung unter vielen, Abbruch der gesamten Pruefung wenn fehlerhaft...
proceed = false;
var date_test = [ '07-11-2011' , '05-11-2011' ];
var date_regexp = /^(0[1-9]|[12][0-9]|3[01])[- /.](0[1-9]|1[012])[- /.](19|20)\d\d$/;
 
if( date_test[0].match( date_regexp ) &&
    date_test[1].match( date_regexp ) ) {
 
   temp = date_test[0].split( date_regexp );
   date_A = new Date();
   date_A.setFullYear( temp[3],  ( temp[2] -1 ) , temp[1] );
 
   temp = date_test[1].split( date_regexp );
   date_B = new Date();
   date_B.setFullYear( temp[3],  ( temp[2] -1 ) , temp[1] );
 
 // Datum A muss vor Datum B liegen
  if( date_A < date_B ) {
     proceed  = true;
  }
}
// Ende der Pruefung - nun Entscheidung...
alert( proceed ); // Test Ausgabe
...

Auf den ersten Blick schien alles zu funktionieren. Wie erwartet wird "false" ausgegeben - Task erledigt, Ticket schließen, Feierabend machen. Nächster Morgen - Ticket ist wieder auf: Die Erweiterung funktioniert nicht. Alle folgenden Prüfungen werden nicht mehr ausgeführt, unabhängig vom Datum. Kann nicht sein, ich hatte das Datum definitiv mehrfach verändert, um alle Variationen zu kontrollieren. Teste daraufhin die Anwendung im Firefox erneut - alles wie gewünscht, Screenshots an das Ticket gehängt, Rückmeldung. Geht Nicht! Noch ein Test, diesmal im Internet Explorer, und siehe da, im Internet Explorer bleibt proceed immer false.

Ein Fehler im regulären Ausdruck? Nicht wirklich, denn der match funktioniert cross-browser. Aber das Datum ist im Internet Explorer NaN während alle anderen getesteten Browser das korrekte Datum ausgeben. Scheitern tut das ganze am split. Laut Spezifikation kann die String Methode sowohl mit Zeichenketten, als auch regulären Ausdrücken umgehen. De facto gibt es da aber einige Unterschiede:

var test_string = 'a,b,c,,,d,e,f,g';
 
// Split mit Zeichenkette
// Erwartet: 9 -> Ergebnis ist 9
var test_a = test_string.split(',');
alert(test_a.length);
 
// Split mit regulärem Ausdruck:
// Erwartet: 9 -> Ergebnis ist im IE: 7
var test_b = test_string.split(/,/);
alert(test_b.length);

Die Methode split reagiert eindeutig anders als die Methode exec des RegExp Objektes. Ändert man das ursprüngliche Script wie folgt:

// eine Pruefung unter vielen, Abbruch der gesamten Pruefung wenn fehlerhaft...
proceed = false;
var date_test = [ '07-11-2011' , '05-11-2011' ];
var date_regexp = /^(0[1-9]|[12][0-9]|3[01])[- /.](0[1-9]|1[012])[- /.](19|20)\d\d$/;
 
if( date_test[0].match( date_regexp ) &&
    date_test[1].match( date_regexp ) ) {
 
   temp = date_regexp.exec( date_test[0] );
   date_A = new Date();
   date_A.setFullYear( temp[3],  ( temp[2] -1 ) , temp[1] );
 
   temp = date_regexp.exec( date_test[1] );
   date_B = new Date();
   date_B.setFullYear( temp[3],  ( temp[2] -1 ) , temp[1] );
 
 // Datum A muss vor Datum B liegen
  if( date_A < date_B ) {
     proceed  = true;
  }
}
// Ende der Pruefung - nun Entscheidung...
alert( proceed ); // Test Ausgabe
...

Dann funktioniert diese Prüfung in allen Browsern. Aber warum? Wieso verhält sich der gleiche reguläre Ausdruck bei zwei Methoden so unterschiedlich? Steven Levithan beschreibt in seinem Artikel JavaScript split Bugs: Fixed! gleich eine ganze Reihe von Fehlern (die nicht nur den Internet Explorer betreffen), und liefert auch gleich eine Lösung, in dem er die ganze Methode überlagert. Auch wenn es in meinem Fall ausgereicht hat, die Methode einfach zu wechseln - dieses Verhalten bleibt ein Mysterium. Bedeutet es doch, dass da unterschiedliche Verabeitungsprozesse ablaufen. Wenn man bedenkt, dass reguläre Ausdrücke für viele ohnehin ein Buch mit sieben Siegeln darstellt, wie passend ist es da, dass es auch noch solche Sprach-Fehler gibt.

Geordnete Listen

CSS-Counter erlauben das Zählen von Instanzen bestimmter Elemente bzw. Selektoren. In Kombination mit den Pseudo-Elementen :before und :after lassen sich dann ganze neue Formen der Nummerierung erstellen. Die CSS-Counter sind dabei deutlich leistungsstärker als das alte HTML start Attribut, das ohnehin als deprecated gilt, und ausschließlich die Nummerierung einer Ebene bzw. eines Listenelementes beeinflusst.
Die Nummerierung mit Hilfe von CSS basiert setzt sich aus mehreren Eigenschaften und Funktionen zusammen:

• counter-reset: Setzt einen oder mehrere Zähler zurück, ein Zähler ist dabei eine frei wählbare Variable. Optional lässt sich für jeden Zähler noch ein Anfangswert festlegen, der Standardwert ist 1.
• counter-increment: Zählt einen oder mehrere Zähler hoch, auch hier kann man über einen zweiten optionalen integeren Wert die Zählweise beeinflussen (selbst negative Werte sind erlaubt).
• content: Gibt mit Hilfe der Funktionen counter() oder counters() die Nummerierung aus.

Ein Beispiel

OL {
  counter-reset: item;
}
OL LI {
  display: block;
}
 
OL LI:before {
  content: counter(item) ". ";
  counter-increment: item;
}

Betrachtet man dieses erste Beispiel im Browser, so sieht das Ergebnis noch nicht anders aus, als eine ganz normale geordnete Liste (OL), der einzige Vorteil liegt darin, dass sich die Nummerierung nun erheblich besser gestalten lässt, ohne dass man weitere Tag Verschachtelungen vornehmen muss. Auf einen Nachteil sei an dieser Stelle auch gleich hingewiesen. In Sachen “Accessability” sind diese Lösungen negativ zu bewerten, denn über CSS generierter Content manipuliert die DOM nicht (siehe hier), so dass aktuelle Screen-Reader diese Informationen schlicht nicht ausgeben, die Liste hätte also keine Nummerierung mehr.
Für eine fortlaufende Nummerierung, die die übergeordneten Nummern übernimmt, kann man den CSS Code wie folgt verändern:

OL {
  counter-reset: item;
}
OL LI {
  display: block;
}
 
OL LI:before {
  content: counters(item, ".") ".";
  counter-increment: item;
}

Nun werden die Nummern der übergeordneten Listenelemente übernommen. Die Funktion counters() liefert im Gegensatz zu counter alle Instanzen eines Zählers gleichzeitig. Der zweite Parameter ist das Trennzeichen, mit dem diese Instanzen verkettet werden. Doch Vorsicht mit dieser Syntax. Sie führt im Internet Explorer 7 dazu, dass alle folgenden CSS Notationen nicht mehr interpretiert werden, selbst wenn diese in separaten Stylesheet Dateien abgelegt sind. Anscheinend bringt die Notation der Anfürhrungszeichen innerhalb der Klammern den CSS Interpreter völlig durcheinander. Bedeutet, man kann wahlweise sicher stellen, dass der entsprechende Code projektweit wirklich immer an letzter Stelle kommt, oder man nutzt die Funktion counter anstatt counters – wobei diese Lösung den CSS-Code abhängig von der möglichen Verschachtelungstiefe deutlich vergrößern kann:

/* 1. Ebene */
BODY OL {
  counter-reset: level1;
  list-style-type: none;
}
 
OL LI:before {
  content: counter(level1) ". ";
  counter-increment: level1;
}
 
/* 2. Ebene */
OL LI OL {
  counter-reset: level2;
}
 
OL LI OL LI:before {
  content: counter(level1) "." counter(level2) " ";
  counter-increment: level2;
}
 
/* 3. Ebene */
OL LI OL LI OL {
  counter-reset: level3;
}
 
OL LI OL LI OL LI:before {
  content: counter(level1) "." counter(level2) "." counter(level3) " ";
  counter-increment: level3;
}
...

Das Meter Element

Meter ist ein Inline-Element. Er dient der “Darstellung von Größen und Mengenverhältnissen innerhalb eines definierbaren Bereichs. In der Spezfikation heißt es:

The meter element represents a scalar measurement within a known range, or a fractional value; for example disk usage, the relevance of a query result, or the fraction of a voting population to have selected a particular candidate. [...] The meter element also does not represent a scalar value of arbitrary range — for example, it would be wrong to use this to report a weight, or height, unless there is a known maximum value.

Solche Verhältnisangaben werden im Normalfall aber nicht nur textuell gemacht, sie werden durch eine grafische Information ergänzt. Die Darstellung entspricht im Prinzip der eines Fortschrittbalkens, aber er dient eben nicht der Statusanzeige einer Aufgabe sondern der Darstellung von Mengen.Das Meter Element kennt sechs Attribute, alle Werte (wenn gesetzt) müssen valide Ganz- oder Fließkomma Zahlen sein.

• Value: Ist schlicht der aktuelle Wert, laut Spezifikation (Stand Juni 2010) ein Pflichtattribut. Bei <html>5Doctor fand ich noch eine erweiterte Erklärung, hier heißt es: Wenn das Attribut nicht gesetzt ist, wird die erste gefundene Zahl innerhalb des Elements als value genutzt, gibt es keine Zahl, so ist der Wert Null.
• Min: Der minimal erlaubte Wert (optional). Sollte kein Wert gesetzt sein, ist der Wert Null.
• Max: Der maximal erlaubte Wert (optional). In manchen Fällen (bspw. bei Prozentangaben) ergibt sich der maximal Wert von allein. Ist keiner gesetzt ist er 1.
• Low: Bestimmt den Anfangspunkt des unteren Abschnitts innerhalb der Gesamtspannweite (optional). Der Bereich zwischen Min und Low wäre die Ausprägung des unteren Abschnitts. Größer als der High Wert kann Low nicht sein.
• High: Bestimmt den Anfangspunkt des oberen Abschnitts innerhalb der Gesamtspannweite (optional). Der Bereich zwischen Max und Low wäre die Ausprägung des oberen Abschnitts. Kleiner als der Low Wert kann High nicht sein.
• Optimum: Bestimmt den optimalen Punkt des definierten Bereichs (optional). Dieser Punkt – soweit gesetzt kann jeden beliebigen Wert zwischen und inklusive Min und Max einnehmen
• Ein spezielles Attribut für die zugrunde liegende Maßeinheit kennt das Meter Element (noch) nicht. Vorgeschlagen wird in diesem Falle das Universal-Attribut title zu nutzen.

Ein Beispiel

<p>Ihr Ergbnis:
  <meter min="0" low="4" high="8" value="7" optimum="10" max="10">
    7 von 10 Punkten
  </meter>
</p>

Die Semantik des Elements, der informative Mehrwert entsteht also nur durch die Attribute – und wie stellen Browser diese Informationen dar? Kurz: Bisher gar nicht – es gibt zwar Vorschläge wie ein Browser diese Informationen rendern könnte, aber passieren tut zur Zeit nichts. Wie weit kommt man mit CSS, um aus dem Meter Element mehr zu machen als die reine Textdarstellung? Auch nicht weit. CSS, so wie es die Browser momentan unterstützen fehlen dafür zwei entscheidene Möglichkeiten: Die Unterstützung von Attributen als Werte und die Möglichkeit Werte zu berechnen. Leider sind beide Eigenschaften in keinem aktuellen Browser implementiert. Mozilla meldet allerdings, dass es CALC() mit Firefox 4 unterstützen wird. Bis dahin ist eine reine CSS Lösung eine schöne Utopie. Als Basis für so eine zuküftige CSS basierte Lösung der Screenshot aus der Spezifikation:

Beispiel Screenshot aus der Spezifikation: HTML5 (Edition for Web Authors) – The meter element

Könnte man innerhalb von CSS rechnen, und dabei auf die Attribute des Elements zugreifen, dann ließe es sich bspw. wie folgt realisieren (eine Variante mit festen Werten findet man hier):

meter:before {
  height:4px;
  display:block;
  float:left;
  background:#d9d9d9;
  border-left:1px solid #4cb24c;
  /* Dynamische Ermittlung der Breite */
  width: 40 - calc((40 / 100) * (attrs(value) * 100));
  border-left-width:calc((40 / 100) * (attrs(value) * 100));
}

Wie gesagt, das ist Zukunftsmusik, wenn überhaupt, denn was calc leisten wird ist noch unklar. Reine CSS-Lösungen hätten ohne Frage den höchsten Freiheitsgrad in der Gestaltung, aber browserübergreifend kommt man nicht wirklich weit. Ein paar Beispiele habe ich hier zusammengestellt:

Beispiel für eine CSS basierte meter Gestaltung in verschiedenen Browsersystemen

Die Screenshots zeigen, dass es zwar grundsätzlich möglich ist, die Gestaltung über CSS zu realisieren, aber selbst in aktuellen Browsersystem sind die Abweichungen zum Teil enorm. Der Internet Explorer 8 unterstützt ohne JavaScript noch gar kein html5 und würde demzufolge hier nur eine reine Textversion anzeigen. Da alle Werte “hart” gecodet werden müssen ist ein solcher Ansatz bis auf weiteres ohnehin obsolet. Was bleibt als Alternative? Man könnte das CSS mit Platzhaltern versehen, und diese serverseitig ersetzen. Dies würde die Darstellungsunterschiede aber auch nicht beseitigen. Serverseitig Bilder generieren wäre sicher auch eine Option, aber die Qualität solcher Bilder lässt zu wünschen übrig. Ein möglicher Ansatz wäre die Verwendung von Canvas, VML in Kombination mit JavaScript (auch wenn in solchen Fällen all die schöne Semantik wieder hin wäre).

Das Progress Element

Auch das Progress Element ist ein Inline-Element. Es ist eine quasi eine textuelle Repräsentation eines Fortschrittsbalken. Dabei kann er sowohl als Basis für eine dynamische Information (in Kombination mit JavaScript) oder statische Information (bspw. bei “Tunnel-Prozessen” wie einem mehrseitigen Formular) dienen. Die Spezifikation sagt:

The progress element represents the completion progress of a task. The progress is either indeterminate, indicating that progress is being made but that it is not clear how much more work remains to be done before the task is complete (e.g. because the task is waiting for a remote host to respond), or the progress is a number in the range zero to a maximum, giving the fraction of work that has so far been completed.

Letztlich unterscheiden sich das Progress Element und das Meter Element gar nicht so sehr voneinander. Wobei das Progress Element wohl noch wahrscheinlicher erst in Kombination mit JavaScript seine wahre Bedeutung erhält. Im Gegensatz zum Meter Element kennt Progress nur einen Anfgangs- und einen Endpunkt sowie den aktuellen Wert. Javascript basierte Lösungen für solche Fortschrittsbalken gibt es bereits einige, hier wäre eigentlich nur eine Schnittstelle zur Übernahme der Werte zu schaffen.

Genau genommen kennt der IE zwei, nein drei Varianten, um ein Element zu rotieren. Zum einen gibt es den writing-mode. Seit der Version 7 unterstützt der IE eine Vielzahl von “Schreibrichtungen“, aber diese Rotationen sind immer 90 Grad Rotationen. Ähnlich begrenzt ist der BasicImage Filter, hier gibt es für die Rotation nur vier erlaubte Werte (0,1,2,3) – die das Element dann um 0, 90, 180 oder 270 Grad drehen. In meinem Fall hatte die Navigation aber einen Neigungsgrad von -1.5, da blieb nur die Matrix. Es ergibt sich folgende CSS Notation:

-moz-transform:rotate(-1.5deg);
-webkit-transform:rotate(-1.5deg);
-o-transform:rotate(-1.5deg);
filter: progid:DXImageTransform.Microsoft.Matrix(
  sizingMethod='auto expand',
  M11=0.9996573249755573,
  M12=0.026176948307873055,
  M21=-0.026176948307873055,
  M22=0.9996573249755573
);

Nicht wirklich intuitiv. Um ein Objekt über den Matrix-filter zu rotieren, beschreibt man die Winkelverhältnisse, die sich ergeben. Da sich in CSS nicht rechnen lässt, bleibt einem nur der Taschenrechner, oder ein paar Zeilen JavaScript:

function getMatrix(deg) {
  var deg2radians = Math.PI * 2 / 360;
  var rad = deg * deg2radians ;
  var cos = Math.cos(rad);
  var sin = Math.sin(rad);
  return [cos,-sin,sin,cos];
}

Ein entsprechendes Beispiel befindet sich hier. Es sei noch anzumerken, dass die Darstellungsqualität von Tex bei solchen Rotationen m Firefox (3.6.7 Windows XP, 3.5 Ubuntu) und Safari (4.0.3 Windows XP) miserabel ist. Die Buchstaben wirken zerfranst, oder “hüpfen”, d.h. sie laufen nicht sauber auf einer Linie. Chrome (5.0.3 Windows XP) und Internet Explorer (7,8 Windows XP) hingegen lieferten ein erstaunlich gutes Ergebnis.

Habe ein wenig herumgestöbert und siehe da, Microsoft ist das Problem bekannt und bietet eine Lösung. Interessant, dass gerade bei einem HTML-Element, das Usability und Accessibility erhöhen soll, auf eine JavaScript Lösung zurück gegriffen wird. Nicht so richtig sinnvoll, aber besser als gar nichts – hier der Beispielcode:

//Set a temp expando to store the current selectedIndex
function SelectOnFocusIn() {
  try {
    var eSrc = window.event.srcElement;
    if (eSrc)  eSrc.tmpIndex = eSrc.selectedIndex;
  } catch (e) {
    HandleError(e, false);
  }
}
 
//restore the selectedIndex
function SelectOnFocus() {
  try {
    var eSrc = window.event.srcElement;
    if (eSrc) eSrc.selectedIndex = eSrc.tmpIndex;
  } catch (e) {
    HandleError(e, false);
  }
}

Und der dazugehörige HTML-Code:

<select name="test" id="test"
  onfocusin="SelectOnFocusIn()" onfocus="SelectOnFocus()">
  <option value="3">Alien Perm </option>
  <option value="4">Alien Temp </option>
  <option value="1" selected="selected">Native </option>
  <option value="2">Naturalized </option>
  <option value="N">Not Indic. </option>
</select>

Eingebaut, getestet – und anscheinend hat der zuständige Entwickler noch nichts von multiple gehört, denn bei Auswahlfeldern mit Mehrfachauswahl greift der Code nicht. Es wird nur die erste selektierte Option übernommen, alle anderen Auswahlen gehen verloren – Bugfixing der besten Qualität. Welch hoher Maßstab hier angelegt wurde, sieht man schon an der Anweisung im catch Block der Funktionen, wo bitte ist die Funktion HandleError, oder gehört diese Funktion mittlerweile zu einem offiziellen JavaScript Standard? Nein – also weg damit, und dann auch gleich noch die fehlende Unterstützung von Mehrfachauswahlen implementiert:

function SelectOnFocusIn() {
  try {
    var eSrc = window.event.srcElement;
    if(eSrc)  {
      eSrc.firstSelected = eSrc.selectedIndex;
      var tmpIndex = [];
      for (var s = 0, l = eSrc.options.length; s<l; s++) {
        if (eSrc.options[s].selected == true) {
          tmpIndex.push(s);
        }
      }
      eSrc.tmpIndex = tmpIndex;
    }
  } catch (e) {}
}
 
function SelectOnFocus() {
  try {
    var eSrc = window.event.srcElement;
    if (eSrc) {
      /* muss gesetzt werden, anderenfalls wird die
          die erste Option immer mit aktiviert! */
      eSrc.selectedIndex = eSrc.firstSelected;
      for(var i=0, l = eSrc.tmpIndex.length; i<l; i++ ) {
        eSrc.options[eSrc.tmpIndex[i]].selected = true;
      }
    }
  } catch (e) {}
}

Mit diesen Korrekturen lässt sich der Fokus-Bug nun für alle Formen von SELECT-Feldern anwenden, und wenn dem schon so ist, dann würde eine allgemeine Regel für alle solche Felder doch deutlich weiter helfen, als in jedem einzelnen Feld zwei Event-Handler zu notieren. Das Ganze müsste dann nur noch zum frühst möglichen Zeitpunkt geladen werden, und idealerweise nur für den Internet Explorer 6. Meine finale Lösung sieht am Ende so aus:

(function () {
  var d   = document;
  selectFix = function() {
    var selFields = document.getElementsByTagName('select');
    if(!selFields || selFields.length==0) {return;}
    for(var i=0, l=selFields.length; i<l; i++) {
      var elm = selFields[i];
      elm.onfocusin = function() {
        try {
          var eSrc = window.event.srcElement;
          eSrc.firstSelected = eSrc.selectedIndex;
          var tmpIndex = [];
          for (var s = 0, l = eSrc.options.length; s<l; s++) {
            if (eSrc.options[s].selected == true) {
              tmpIndex.push(s);
            }
          }
         eSrc.tmpIndex = tmpIndex;
        } catch (e) {}
      };
      elm.onfocus = function() {
        try {
         var eSrc = window.event.srcElement;
         if (eSrc) {
           eSrc.selectedIndex = eSrc.firstSelected;
           for(var s=0, l = eSrc.tmpIndex.length; s<l; s++ ) {
             eSrc.options[eSrc.tmpIndex[s]].selected = true;
           }
         }
        } catch (e) {}
      }
    }
  };
  try { d.documentElement.doScroll('left'); selectFix(); }
  catch (err) { setTimeout(arguments.callee, 0); }
})();

Fehlt nur noch die Anforderung, das Script nur für den IE 6 laufen zu lassen. Dafür gibt es verschiedene Möglichkeiten. Eine JavaScript basierte “Browserweiche” nutzen (muss aber nicht sein), das ganze Script in eine eigene Datei auslagern und innerhalb eines Conditional Comment einbinden, oder – für den Fall, dass der Code innerhalb einer größeren JavaScript Datei steht über die jscript Variante:

/*@cc_on @*/
/*@if (@_jscript_version == 5.6)
  // dieser Bereich ist für jscript-Interpreter version 5.6 sichtbar
  // (das entspricht dem Internet Explorer 6)
@*/
/*@end @*/

Wie gesagt, es ist alles andere als ideal, die Funktionalität von LABEL mit JavaScript nachträglich zu implentieren, geht es bei diesem Element doch gerade um eine Erhöhung der “Verfügbarkeit” auch ohne Zusatztechnologien. Aber bei dieser Browserversion ist ohnehin schon alles verloren, sollte jemand eine bessere – eine scriptfreie Lösung haben, dann bitte!

Was ist ein Zeichensatz genau, und was versteht man unter Sortierfolgen?

Die Dokumentation von MySQL liefert auf diese Fragen ein sehr anschauliches Beispiel. Ein Zeichensatz (CHARACTER SET) ist eine Gesamtmenge von Symbolen bzw. Elementen – das können sichtbare Symbole wie Buchstaben, Zahlen, Sonder- oder Satzzeichen sein, aber auch unsichtbare Steuerzeichen (wie bspw. Zeilenumbruch) – und deren Kodierung (Zuordnung). So hat im deutschen Alphabet der Buchstabe “Ü” die Kodierung 220. Wechselt man den Zeichensatz, so kann die gleiche Kodierung einem ganz anderen Symbol zugeordnet sein. Im EBCDIC-Zeichensatz kodiert der Wert 220 bspw. die geschweifte Klammer “}“. Auch die Anzahl der darstellbaren Zeichen kann von Zeichensatz zu Zeichensatz stark variieren. ASCII kennt 95 darstellbare Zeichen, Unicode (Standard 5.1) hingegen 100.000.
Je komplexer ein Zeichensatz, desto mehr Regeln braucht man für die Sortierung bzw. zum Vergleich dieser Zeichen. Der einfachste Vergleich von zwei Zeichen bzw. Zeichenketten (Strings) ist die Binärsortierung. Dabei wird verglichen, ob die Kodierung von A (65) größer ist als die von B (66). Soweit – so einfach, aber wie fällt der Vergleich von B (66) mit a (97) aus? In diesem Falle würde der Großbuchstabe B vor dem kleinen a erscheinen. Der Zeichensatz braucht also eine weitere Regel, die Groß- und Kleinschreibung nicht berücksichtigt. Zu Erkennen sind diese Sortierfolgen in MySQL an dem _ci in Namen, kurz für case insensitive. Sonderzeichen erzwingen weitere Regeln: Das deutsche “Ü” stehen in der Sortierfolge für UE, und wie sieht es mit é und è aus, welche Regeln gelten in diesem Fall?
Kurz gesagt: COLLATE legt fest, wie Strings miteinander verglichen werden, und das kann ein durchaus komplexes Regelwerk sein.

Welches ist der “richtige” Zeichensatz?

Trival ist diese Frage nicht, betrachtet man folgendes Beispiel: Es soll einer Tabelle USER angelegt werden, die u.a. folgende Informationen aufnehmen soll: Benutzername, Name, Passwort, E-Mail und Land. Bei allen genannten Feldern handelt es sich Textfelder – aber für jedes gelten andere Voraussetzungen:

• Das Passwortfeld sollte verschlüsselt sein und für die Verschlüssung wird häufig MD5 verwendet. Nun liefert MD5 immer eine Zeichenkette von 32 Zeichen, und diese 32 Zeichen sind immer ASCII.
• Die E-Mail hingegen darf seit der Einführung der Internationalen Domain-Namen 92 Sonderzeichen außerhalb des reinen ASCII-Codes enthalten, so sind bspw. deutsche Sonderzeichen im Domänenteil einer E-Mail Adresse durchaus erlaubt. Dies gilt zwar nicht für den eigentlichen Mailverkehr – hier müssen diese Zeichen kodiert werden – aber kaum ein User wird die “kodierte” Fassung einer solchen Adresse bei seiner Anmeldung verwenden. Im lokalen Teil der E-Mail (vor dem @-Zeichen) sind alle Zeichen oberhalb des ASCII-Codes 127 generell verboten (also auch Umlaute), laut Spezifikation müssen aber Groß- und Kleinschreibung unterschieden werden. Bei den Adressen hans.mueller@email.de und Hans.Mueller@email.de könnte es also um zwei verschiedene Adressen handeln (auch wenn dieses in der Praxis kaum der Fall ist). Und die Länge – aus wievielen Zeichen kann eine E-Mail Adresse maximal bestehen? Legt man RFC 5321 zu Grunde, dann darf der lokale Teil aus maximal 64 Zeichen bestehen und der Domänenteil aus 255 Zeichen, kommt noch das @ Zeichen dazu, ergibt sich eine Gesamtlänge von 320 Zeichen. Ein theoretischer Wert, RFC-konforme SMTP-Server können nur mit einer maximalen Länge von 255 Zeichen umgehen, denn die Definitionen des Path-Elementes im RFC 5321 (in dem die E-Mail Adresse steht), erlaubt nur eine entsprechend reduzierte Zeichenlänge.
• Beim Namen, dem “realen Namen” des Nutzers kann – je nachdem wie international die Seite ist – so ziemlich jeder Buchstabe aus jedem Alphabet auftauchen. Ganz gleich ob es ein hebräischer, russischer oder japanischer User ist, die Spalte sollte mit entsprechenden Zeichen umgehen können.
• Das Länderkürzel besteht in vielen Projekten aus zwei oder drei Zeichen, in denen keine Sonderzeichen erlaubt sind, wie bei der Passwort-Spalte sind diese Zeichen immer Bestandteil des ASCII Zeichensatz.
• Für den Benutzernamen gelten zumeist striktere Regeln, als für den realen Namen. Zeichen, die nicht in der Latin-1 (ISO-8859-1) oder US-ASCII Kodierung vorhanden sind, werden selten zugelassen.

Es ist also durchaus möglich, dass innerhalb einer Tabelle Daten gespeichert werden, die in verschiedenen Zeichensätzen repräsentiert sein könnten. In dem Beispiel ließen sich ASCII, Latin-1 und UTF8 unterscheiden, aber welchen Vorteil würden unterschiedliche Zeichensätze überhaupt bieten, oder entstehen daraus am Ende sogar Nachteile?

Im Web setzt sich UTF8 immer mehr durch, seit 2008 ist es der meist verwendete Zeichensatz im World Wide Web. Mit UTF8 lässt sich fast jedes Alphabet abbilden, kein Wunder also, dass mehr und mehr Seiten auf diesen Zeichensatz wechseln. Der Standard Zeichensatz von MySQL ist Latin-1, gerade mal 256 darstellbare Zeichen (zu denen noch nicht einmal das € Euro Zeichen gehört), Das UTF8 Kodierungsschema, das mit einer variablen Länge von 1-4 Bytes pro Zeichen arbeitet repräsentiert einen ungleich größeren Zeichenraum. Ist es nicht die effizienteste Lösung, dann alle Zeichenfelder, die gesamte Datenbank Kommunikation auf UTF8 umzustellen?

Die UTF8 Kodierung hat ihren Preis

UTF8 kodierte Zeichen aus dem ASCII Raum benötigen 1 Byte an Speicher, für Sprachen wie Hebräisch oder Türkisch, aber auch deutsche Sonderzeichen belegt es 2 Bytes und Japanisch oder Chinesisch beanspruchen 3 Bytes (MySQL unterstützt zur Zeit nur bis zu 3 Byte-Sequenzen). Latin-1 oder ASCII benötigt immer nur 1 Byte. Definiert man bspw. das Passwortfeld wie folgt:

PASSWORD CHAR(32) CHARSET utf8

Ergibt sich folgendes: Eine CHAR Spalte ist eine fixierte Spalte, d.h. es wird immer die gleiche Länge verwendet, sollten weniger Zeichen eingegeben werden, dann füllt MySQL diese fehlenden Zeichen mit einem Leerzeichen auf. MySQL muß in diesem Fall also gewährleisten, dass bis zu 32 Zeichen in diese Spalte passen, bei maximal 3 Bytes pro Zeichen belegt die Spalte damit immer 32*3 (96) Bytes, wäre die Spalte in ASCII kodiert hingegen nur 32 Bytes, bei vielen Datensätzen und vielen solcher Spalten kann sich das im Speicherbedarf durchaus bemerkbar machen. Halb so wild – wechselt man den Typ von CHAR auf VARCHAR, dann wechselt man von einem fixierten Spaltentyp auf einen dynamischen Spaltentyp. VARCHAR braucht immer nur soviel Bytes wie tatsächlich in der Zelle notwendig sind (plus 1 bis 2 Byte für die Anzahl der Zeichen). In diesem Fall sind alles ASCII Zeichen, damit also 32 Byte + 2 Byte für die Länge, also 34 gegen 96 Byte für jeden Eintrag.

Einfach auf CHAR verzichten und ganz auf VARCHAR wechseln?

Ist es nicht sogar so, dass es MySQL mit CHAR und VARCHAR gar nicht so genau nimmt, den Spaltentyp zum Teil selbstständig wechselt?
Hab ich auch so gelernt, aber es stimmt so nicht mehr: Früher galt, dass VARCHAR Spalten, die mit weniger als 4 Zeichen definiert werden, automatisch in ein CHAR konvertiert wurden. Umgedreht galt für CHAR-Spalten mit einer Definition von mehr als 3 Zeichen (unter der Voraussetzung, dass die Tabelle eine dynamsiche Spalte enthielt) die Wandlung in den Typ VARCHAR. Seit der MySQL Version 5 ergibt:

CREATE TABLE testVARCHAR_CHAR (
  col1 CHAR(40),
  col2 VARCHAR(2),
  col3 CHAR(3)
);
DESC testVARCHAR_CHAR;

+-------+------------+------+-----+---------+-------+
| Field | Type       | Null | Key | Default | Extra |
+-------+------------+------+-----+---------+-------+
| col1  | char(40)   | YES  |     | NULL    |       |
| col2  | varchar(2) | YES  |     | NULL    |       |
| col3  | char(3)    | YES  |     | NULL    |       |
+-------+------------+------+-----+---------+-------+

Also keine implizite Typenkonvertierung mehr, dieses Argument entfällt. Aber warum überhaupt fixierte Spalten, wenn dynamische Spalten doch effizienter mit dem Speicherplatz umgehen? Der Unterschied ergibt sich über die Geschwindigkeit. Bei PHPPerformance findet man einen Artikel zum Thema und die dort genannten Zahlen sprechen für sich. Aktualisierungen oder Löschvorgänge können bei dynamischen Tabellen zur Fragmentierung der Information führen, und dies hat eine Auswirkung auf die Performance – bei dem genanntem Test lag der Abfrageunterschied zwischen der dynamsichen und statischen Variante bei 0,6 zu 0,1 Sekunden.

Um bei dem hier gewählten Beispiel zu bleiben, die Passwortspalte ist immer gleich lang, sie besteht immer aus 32 Zeichen, der Typ CHAR ist hier demzufolge die optimale Lösung. Die Zeichen sind immer ASCII – also ist der ideale Zeichensatz für diese Spalte ASCII und nicht UTF8, man gewinnt an Performance und spart zudem noch 1 bis 2 Byte pro Eintrag. Bei der Spalte für das Länderkürzel lässt sich ähnlich argumentieren.
Für die Felder E-Mail, Name und Benutzername hingegen sollte UTF8 verwendet werden. Auch wenn beim Benutzernamen ggf. ausschließlich Zeichen aus dem Latin-1 Zeichenraum verwendet werden, würde hier eine unterschiedliche Kodierung spätestens bei der Ausgabe auf einer Seite Probleme bereiten. Da in allen Zellen dieser Spalten sehr variable Werte stehen können, werden alle als VARCHAR definiert:

CREATE TABLE user (
  password CHAR(32) CHARSET ascii,
  username VARCHAR(20) CHARSET utf8,
  name VARCHAR(50) CHARSET utf8,
  email VARCHAR(255) CHARSET utf8,
  lang CHAR(3) CHARSET ascii,
  UNIQUE KEY (username)
);

Der UNIQUE KEY auf das Feld “username” erzwingt einen eindeuten Benutzernamen (für den Fall, dass dieser Wert für den Nutzer nicht veränderbar ist, könnte man die Spalte “username” auch zum PRIMARY KEY machen.). Aber wie eindeutig ist dieser Name in dieser Form eigentlich? Macht es einen Unterschied ob ich der Nutzer “axel”, “Axel” oder “AXEL” bin?

Warum man auf die Sortierfolge achten sollte

Bei einem Benutzernamen kann man sicher darüber streiten, ob es sinnvoll ist, Groß- und Kleinschreibung zu unterscheiden – also jede Schreibvariante als einen eigenen Namen zu verstehen. In anderen Fällen, bspw. für den Fall, dass Sie mit unverschlüsselten Passwörtern arbeiten (müssen), sollte die Schreibweise unbedingt eine Rolle spielen. Anstatt (und das ist die Standard Einstellung) Groß- und Kleinschreibung nicht zu berücksichtigen, sollte in diesen Fällen die COLLATE Eigenschaft so verändert werden, dass unterschieden wird:

[...]
  username VARCHAR(20) CHARSET utf8 COLLATE utf8_bin,
[...]

COLLATE Angaben, die auf bin oder cs enden, sind case sensitive – berücksichtigen Groß- und Kleinschreibung. Mit dieser Veränderung liessen sich die Nutzer axel”, “Axel” oder “AXEL” in die Tabelle eintragen, anderenfalls gäbe es einen Fehler: #1062 - Duplicate entry 'Axel' for key 'username'.
Die Spalte “name” hatte den Zeichensatz UTF8 erhalten, die Standard-Sortierfolge ist damit utf8_general_ci, für viele Vergleiche korrekt – aber nicht für alle. Ein Beispiel: Angezeigt werden sollen alle deutsche Nutzer, in alphabetischer Reihenfolge:

SELECT name FROM user WHERE lang='DE' ORDER BY name;

+-------------+
| name        |
+-------------+
| Aachen      |
| Aechten     |
| Affe        |
| Ärger       |
| Äußern      |
| Axel Michel |
+-------------+

Die Sortierung entspricht nicht den deutschen Sortierungsregeln, Ein Ä steht für AE, und nicht für A, wie es bei UTF8 der Fall ist. Auch hier kann einem die Sortierfolge weiterhelfen:

SELECT name FROM user
  WHERE lang='DE'
  ORDER BY
   CAST(name AS CHAR CHARACTER SET latin1)
   COLLATE latin1_german2_ci;

+-------------+
| name        |
+-------------+
| Aachen      |
| Aechten     |
| Ärger       |
| Äußern      |
| Affe        |
| Axel Michel |
+-------------+

Nun ist das Ergebnis richtig (im Sinne des deutschen Alphabets) sortiert. Damit der Vergleich richtig funktioniert, wird der Zeichensatz für die Sortierung auf latin1 gewechselt, und dann die entsprechende Sortierfolge gewählt.

Zeichensatz und Sortierfolge sind keine starren, “unveränderbaren” Eigenschaften einer Datenbank. Sie sind im hohen Maße abhängig von den Inhalten und Typ der jeweiligen Tabellenspalten und – wie im letzten Beispiel aufgezeigt – von dem, was man “mit den Daten anfangen will”.

In meinem Artikel Text begrenzen, aber richtig hatte ich einige serverseitige Lösungen zum Begrenzen von Text vorgestellt. Solche Ansätze scheitern, wenn es bei der Begrenzung gar nicht um die Anzahl von Zeichen geht, sondern layoutabhängig sind. Die naheliegende Verwendung der CSS-Eigenschaft text-overflow wäre ideal, hier wird der Text nicht nur abgeschnitten, sondern in der Form Dieser Text geht noch weiter … dargestellt:

Beispielcode – die HTML Syntax

<div class="fixed-box">
  <p class="truncate">Ein viel zu langer Text für das Elternelement.</p>
</div>

Legt man folgenden CSS Code zugrunde, dann wird der Text zwar in allen Browsern “abgeschnitten” (durch overflow:hidden), aber nur im Internet Explorer und im Webkit (Safari, Chrome) greift text-overflow mit der Ausprägung ellipsis:

.fixed-box {
  width:100px;
}
 
.truncate {
  white-space: nowrap;
  text-overflow: ellipsis;
  overflow: hidden;
}

Aber wie hilft man Firefox auf die Sprünge? Sicher – man könnte sich über JavaScript helfen, bei Ajaxian wird auf bspw. ein entsprechendes JQuery Plugin verwiesen. Es gibt aber noch eine Alternative und die basiert auf XBL. XBL (XML Binding Language) ist eine XML-basierte Auszeichnungssprache, mit der man das Verhalten und Aussehen von XML- und HTML-Elementen beschreiben kann. Dies geschieht über sogenannte Bindings (Bindungen) in XBL, die an ein solches Element angehängt werden. Die Bindings werden in einer separaten XBL-Datei definiert. Über ein Binding kann auch Text in das XML- oder HTML-Element eingefügt werden. Ein Binding kann an mehrere unterschiedliche Elemente angehängt werden. Der Code für die Implentierung von text-overflow ellipsis:

<?xml version="1.0"?>
<bindings
  xmlns="http://www.mozilla.org/xbl"
  xmlns:xbl="http://www.mozilla.org/xbl"
  xmlns:xul="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul"
>
  <binding id="ellipsis">
    <content>
      <xul:window>
        <xul:description crop="end" xbl:inherits="value=xbl:text">
          <children/>
        </xul:description>
     </xul:window>
    </content>
  </binding>
</bindings>

Cross Browser text-overflow CSS Syntax

Die XML Syntax wird als Datei abgespeichert und dann über CSS referenziert:

.truncate {
  white-space: nowrap;
  text-overflow: ellipsis;
  overflow: hidden;
  /* Firefox mit text-overflow */
  -moz-binding: url(ellipsis.xml#ellipsis);
  /* und nun auch noch Opera */
  -o-text-overflow:ellipsis;
}

Einen kleinen Schönheitsfehler hat die Sache im Firefox Version 3.6. Aufgrund eines Bugs bei -moz-binding werden einmal gesetzte Werte nicht wieder geändert. Heißt bei Fluid-Designs bleibt der “ellipsis” Effekt auch dann noch vorhanden, wenn er eigentlich nicht mehr benötigt wird.

<?xml version="1.0"?>
<bindings
  xmlns="http://www.mozilla.org/xbl"
  xmlns:xul="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul"
>
<binding id="none">
  <content><children/></content>
</binding>
<binding id="ellipsis">
  <content>
    <xul:label crop="end"><children/></xul:label>
  </content>
  <implementation>
    <field name="label"> document.getAnonymousNodes( this )[ 0 ] </field>
    <field name="style"> this.label.style </field>
    <property name="display">
       <getter>
         this.style.display
       </getter>
       <setter>
         if( this.style.display != val ) this.style.display= val
       </setter>
    </property>
    <property name="value">
      <getter>
         this.label.value
      </getter>
      <setter>
        if( this.label.value != val ) this.label.value= val
      </setter>
    </property>
    <method name="update">
      <body>
         var strings= this.textContent.split( /\s+/g )
         if( !strings[ 0 ] ) strings.shift()
         if( !strings[ strings.length - 1 ] ) strings.pop()
         this.value= strings.join( ' ' )
         this.display= strings.length ? '' : 'none'
      </body>
    </method>
    <constructor> this.update() </constructor>
  </implementation>
  <handlers>
    <handler event="DOMSubtreeModified"> this.update() </handler>
  </handlers>
</binding>
</bindings>

Dafür ist der erwähnte Bug bei dynamisch modifizierten Elementen (sei es über Javascript oder flexibel skalierbare Boxen) nicht mehr aktuell und kann gestrichen werden (wurde gestrichen). Hier sind noch einmal alle Tests zusammgefasst zu finden.

In Sachen Schrift war das World Wide Web lange Zeit eine echte Wüste. Es gab nur wenige unterschiedliche Schriftarten, die man verwenden konnte. Was blieb, wenn das Design anderes vorgesehen hatte?

• Variante 1: Das “Ersetzen” von Text mit Bildern – wahlweise über eine Vordergrundgrafik (ganz schlecht für Suchmaschinen), oder via CSS über eine Kombination von verwendeten Hintergrundgrafiken (die schönen Schriften) und versteckten Inhalten.
• Variante 2: Über den Einsatz von Flash, wie es bspw. die Bibliothek sIFR (Scalable Inman Flash Replacement) macht.
• Variante 3: Über eine Kombination von Canvas und VML, bei der mit Hilfe von JavaScript eine spezielle Schriftdatei gerendert wird, dies ist bspw. bei Cufón, oder Typeface der Fall.

Die CSS Syntax

Alles aufwendige, zeit- und lade-intensive Verfahren. Und jetzt, alles ganz einfach: Quell-Datei im CSS angeben und fertig. Nein, so einfach ist es leider nicht. Auch die schöne neue CSS3 Welt hat noch einige Tücken, wenn es um die Einbettung von Schriften geht. So schaut es von der blanken Theorie zunächst einmal aus:

@font-face {
  font-family: derFontName ;
  src: url( /location/of/font/FontDateiName.ttf ) format("truetype");
}  
 
/* Nun hat man über den Font-Namen (derFontName) Zugriff,
    und verwendet den Schrifttyp wie andere Schriftarten auch... */
h1 {
  font-family: derFontName , verdana, helvetica, sans-serif;
}

Die hier gewählte Syntax entspricht der CSS3 Spezifikation, diese läßt verschiedene Schriftformate zu: “TrueType” (ttf), “opentype” (ttf,otf), “TrueType-aat (ttf), “Embedded OpenType” (eot) und “Scalable Vector Graphic” (svg,svgz). Im Internet Explorer läuft das Ganze ein wenig anders ab (dafür unterstützt der IE die Möglichkeit Schriften einzubetten aber auch schon seit der Version 4.0!). Zunächst: Der IE kennt nur das “eot” Format (Embedded OpenType), und weil er nur ein Format kennt, entfällt im IE eben auch die Angabe zum Format. Für den Internet Explorer sähe die gleiche Syntax wie folgt aus.

@font-face {
  font-family: derFontName ;
  src: url( /location/of/font/FontDateiName.eof );
}

Eine solche Abweichung ließe sich leicht über conditional comments realisieren. Wenn solche “IE-only” Stylesheets ohnehin schon für ein Projekt genutzt werden, ist das ein absolut gangbarer Weg. Paul Irish schlägt in seinem Artikel “Bulletproof @font-face syntax” eine andere Vorgehensweise vor. Er kombiniert IE und Non-IE Anweisungen in einem CSS-Element:

/* Die CSS Syntax aus dem Artikel Bulletproof font-face syntax
    von Paul Irish */
@font-face {
  font-family: 'Graublau Web';
  /* der IE stoppt hier...*/
  src: url('GraublauWeb.eot');
  /* weil er damit nicht umgehen kann */
  src: local('☺'),
    url('GraublauWeb.ttf') format('truetype');
}

Der Smiley in local('☺') ist kein Fehler, sondern ein Feature. Die local Anweisung erlaubt es Browsern auf dem Clientsystem nachzusehen, ob eine entsprechende Schriftdatei dort vorhanden ist und im Erfolgsfall auf sie zurückzugreifen, anstatt die Typo von der URL zu laden. Das kann Ladezeiten minimieren, birgt aber ein Problem. Paul Irish weist in seinem Artikel darauf hin, dass eine lokale Schrift mit gleichem Namen nicht unbedingt der gewünschten (im CSS eingebundenen) Schrift entsprechen muß. Um diesen “Fehler” zu umgehen, nutzt er den Smiley – laut Spezifikation schlicht ein ungültiger Font-Name. Ob man in der local Anweisung einen solchen Weg geht und damit auf die Möglichkeit verzichtet, ggf. auf eine bereits installierte Schrift zuzugreifen sollte Fallweise entschieden werden.

Zum konvertieren der Schriften in das eot Format lässt sich das kostenfreie Microsoft Werkzeug WEFT verwenden, oder man nutzt einen Online Konverter wie den von Kirsle.net.

Ob über conditional comments oder über die von Paul Irish vorgeschlagene Variante – @font-face läßt sich in der Mehrheit der Browser einsetzen, und im Vergleich zu manch anderen CSS-Weichen, die man für die Unterstützung einer großen Browser-Palette eingehen muß, ist die Syntax relativ einfach zu verwenden. Alles halb so wild…

Stolpersteine

Nicht so schnell, es gibt noch einige Auffälligkeiten in Sachen font-face. Eine Reihe von “Stolpersteinen” über die man sich im Klaren sein sollte, bevor man font-face einsetzt:

• Nicht alle Formate funktionieren browserübergreifend: Auch wenn laut CSS3 Spezifikation das eot (embedded-opentype) Format unterstützt wird, damit kann nur der Internet Explorer umgehen (siehe bspw. diese Forumsdiskussion). WOFF (Web Open Font Format) hingegen läuft momentan nur im FireFox 3.6.
• Konvertierungen können unterbunden werden: Will man möglichst viele Browser unterstützen, kommt man ohne eot nicht weiter. Konvertierungen von ttf auf eot sind aber nur dann möglich, wenn der Urheber der Schrift dieses nicht unterbindet. Und selbst wenn sich die Schrift konvertieren lässt, kann dieses schon eine Verletzung der Lizenz-Rechte darstellen.
• Fehlende Zeichen: Viele der frei verfügbaren Fonts sind nicht vollständig, es fehlen bspw. Umlaute oder Zahlen. In solchen Fällen greift die alternativ definierte Schrifttype, die Schrift wechselt im schlimmsten Fall also mitten im Wort.
• Beachtung der Lizenzrechte: Was für die Konvertierung in das eot Format gilt, gilt natürlich auch für die Verwendung von ttf-Schriften. Eine interessante Diskussion hierzu findet man bspw. in dem Artikel: “Aller – wirklich großes FreeFont Tennis“.
• Kleinste Syntax-Fehler werden bestraft: Minimale Abweichungen in der CSS Notation führen zu Fehlern. Lässt man bspw. die Anführungszeichen bei der Local-Anweisung weg, läuft das Ganze im Opera nicht mehr. Nennt man die Microsoft spezifische eot Anweisung nicht zuerst, scheitert der IE.
• Schwierigkeiten mit font-style: Bei dev.opera.com wird darauf hingewiesen, dass die Version 10 einen Bug bei der Implementierung von font-face hat. Fett und Kursiv Variantionen der Schrift können nicht über das CSS Element font-style gesetzt werden.
• Das Render-Verhalten von Schrift bei @font-face: Die Qualität der Darstellung von Schrift kann sehr unterschiedlich sein. Das zugrundeliegende Problem steckt tief im System: Unter Windows werden nur die Schriften ordentlich und lesbar auf dem Bildschirm angezeigt, die auch für den Bildschirm optimiert wurden. Diese Optimierung nennt sich Hinting, ein zeitaufwendiges und mühsames Verfahren bei der Erstellung von Schriften. Deshalb gibt es nur recht wenige Schriften, die ein gutes Hinting beinhalten, und noch viel weniger, die kostenfrei zur Verfügung stehen. Daher sehen viele der derzeit für @font-face zur Verfügung stehenden Schriften im Web unter Windows so miserabel aus. Den Schriften fehlt das Hinting.
• Render-Verhalten die Zweite: Schriftenglättung: Auch bei der Glättung von Schrift fällt das Ergebnis von System zu System zum Teil sehr unterschiedlich aus. Zum einen kann es sein, dass die Kantenglättung gar nicht aktiviert ist (Cleartype muss unter Windows XP erst aktiviert werden), zum anderen sind die Verfahren von MAC und Windows unterschiedlich. Abweichungen in der Darstellung sind daher unvermeidlich.
• Rendering die Dritte, das Verhalten beim Laden der Seite: Das Laden einer Schriftdatei kostet Zeit – wie lange, das ist abhängig von vielen Faktoren – aber es ist spürbar und manchen Fällen sogar sichtbar. Firefox rendert den Text zunächst mit einem Webstandard-Font. Erst wenn die individuelle Font-Datei vollständig geladen ist, wechselt die Ansicht, die Seite “flackert”. Je größer die Unterscheidung zwischen dem nachgeladenen Font und dem websicheren Fallback, desto augenfälliger wird das Ganze. Beim Webkit hingegen werden die Inhalte erst eingeblendet, wenn die entsprechende Datei geladen ist. Steve Souders gibt in seinem Blog noch den wichtigen Hinweis, dass im Internet Explorer überhaupt nichts passiert, bis die Schriftdatei fertig geladen ist – unter der Vorraussetzung, dass es vor der CSS Syntax einen SCRIPT Block gibt. Paul Irish beschreibt in seinem Artikel Fighting the @font-face FOUT eine JavaScript basierte Lösung, die das Verhalten vom Webkit nachbildet, um so den “flash of unstyled text” (FOUT) zu unterdrücken, eine alternatives Szenario – in Kombination mit Jquery findet man bei BoxCar Press.
• Am Ende hängt es vom Client ab: Auch wenn alles richtig läuft, sicher sein, dass die Seite nun im gewünschten Layout angezeigt wird, kann man sich nicht. Sowohl im Internet Explorer (Extras > Internet Optionen > Sicherheit > Spezieller Level > Downloads > Font Download) als auch bei FireFox (Extras > Einstellungen > Inhalt > Schriftarten & Farben > Erweitert > Seiten das Verwenden von Schriften erlauben) lässt sich die Unterstützung einfach abschalten bzw. muß eingeschaltet werden. In den Versionen IE7 and IE8 werden eigene Fonts unter der höchsten Sicherheitsstufe nicht angezeigt und im IE6 taucht bei höchster Sicherheitsstufe nach jedem Neuladen der Seite, jedem internen Verweis ein Dialog auf, ob man die Schrift herunterladen will – ein unerträglicher Zustand.
• Richtiger Mime-type: Auf Windows Servern kann es notwendig sein, die Dateiformate OTF und TTF mit dem korrekten MimeType (application/octet-stream) auszuliefern.
• Cross-Domain @font-face: Eine volle url für die Schrift-Datei lässt sich so ohne weiteres nicht angeben, Firefox erlaubt keinen cross-domain Zugriff bei den Schriften. Wie man diese Sicherheitseinschränkung umgehen kann zeigt der Eintrag von Paul Straw.

Fazit

font-face gehört die Zukunft und es lässt sich auch heute schon einsetzen. Aber bevor man eine so gestaltete Seite online stellt, ist intensives Testen erforderlich. Die Schwierigkeiten in Sachen Rendering, Schriftenglättung sind so systemspezfisch, dass man mit allem rechnen muß – da reicht ein Rechner mit einem Betriebssystem zum Testen nicht aus. Ladezeiten abhängige Darstellungsprobleme – die “ungestalteten Inhalte” erfordert wohl auch nach wie vor den Einsatz von JavaScript. Nichts desto trotz ist diese Variante performanter als ein komplett scriptbasierter Ansatz. Mit dem WOFF (Web Open Font Format) kommt zudem ein neues, weiteres Format ins Spiel. Es wird browserübergreifend funktionieren, und schneller geladen werden (WOFF ist kein neues Schriftformat, sondern eine komprimierte Fassung einer TTF oder OTF Datei). Noch läuft WOFF zwar nur im FireFox 3.6, soll aber im Internet Explorer (ab Version 9), Opera und Chrome implementiert werden. Dass der Internet Explorer unter bestimmten Umständen das Laden der Dateien vollständig unterbindet bzw. unmöglich macht, legt die Verwendung von conditional comments nahe – auch wenn der Ansatz von Paul Irish sicher eleganter ist. Die Verwendung von @font-face ist nicht ganz so unproblematisch, wie es zunächst den Anschein hat. Die Tage der ewig gleichen Schriftlayouts sind dennoch gezählt. Wie schnell und wie weit das gehen wird, hängt sicher auch von den jeweiligen Lizenzen und damit verbundenen Kosten ab, aber auch auf dem “freien Markt” lassen sich immer mehr Schriften finden. Wie bei vielen neuen Techniken ist Vorsicht geboten, doch der Mehrwert (Suchmaschinen Optimierung, geringe bis gar keine Scriptlast, selektierbarer, skalierbarer und druckbarer Text) gegenüber den anderen Alternativen (Flash, Grafiken, Canvas+VML) spricht für den Einsatz von @font-face.

Weiterführende Artikel

• Real Web Type in Real Web Context: Der umfassende Einstieg in das Thema:”I need to know how my type renders on screens, in web browsers“.
• Testing Cufón, @font-face, and Typekit: Ausführlicher Vergleichstest zwischen den scriptbasierten Lösungen Cufón und Typekit mit der CSS basierten @font-face Lösung.
• Fighting the @font-face FOUT: Das Problem mit den “ungestalteten Inhalten, FOUT steht für: flash of unstyled text. Und zum gleichen Thema: @font-face and performance
• The Essential Guide to @font-face: Der Titel ist Programm, umfassender Wegweiser zum Thema von Six Revisions.
• @font-face in IE: Making Web Fonts Work: Jon Tan’s (einer der Konzepter von Fontdeck) wegweisender Artikel zum Thema aus dem Jahre 2008.
• Web Design is 95% Typography: Ein Artikel nicht zur Technik, sondern über das “Warum”, Typografie im World Wide Web. Und zur gleichen Thematik: The Elements of Typographic Style Applied to the Web.
• Google WebFont Loader: Recht neu, und ein weitere Variante, um “flash of unstyled text” zu unterbinden.

Die Übernahme durch Nokia sahen die einen als Grund zum Feiern, bei anderen klang schon damals wesentlich mehr Skepsis mit. Verfolgt man die Blogs und Nachrichten rund um Plazes seit der Übernahme, dann fällt auf, dass es merklich stiller und die Plattform geworden ist. Besser gesagt, man findet seit Mitte 2009 eigentlich gar keine News mehr. Der Plazes eigene Blog ist abgeschaltet, die News auf der Startseite von Plazes informiert noch immer über den Kauf durch Nokia. Da stellt sich einem doch die Frage, ob die Plazes Plattform überhaupt noch aktiv ist.

Sicher, grundsätzlich funktioniert der Service noch und zugegeben ich nutze ihn nur sporadisch, damit reicht es für meine Zwecke, aber es gibt einige zum Teil gravierende Mängel:

• Bilder zu Orten hochzuladen ist mir nicht möglich, stattdessen ein Flash-Fehler.
• Einen neuen Ort über den Plazer hinzufügen, nur bedingt – die Daten werden nicht richtig übernommen.
• Die Zeitleiste im Profil – nur wenn man angemeldet ist, anderenfalls gibt es über den entsprechenden Ajax-Request einen 404 Fehler.

Eine Anfrage beim Support – keine Reaktion. Eine Anfrage bei den Gründern, wie es um die Plattform steht – keine Antwort. Eine lebendige Community? An vielen Tagen bin ich der einzige User online im Umkreis von 15 oder mehr Kilometern, und das in der (ehemaligen) Heimatstadt von Plazes.

Nokia has acquired the services provided through plazes.com. Together with the Plazes team, Nokia will work on further improving and developing this service for you. See more on location based services at www.maps.nokia.com.

Welchen Focus Nokia hat(te), als es Plazes übernahm, das Vorantreiben der Online Plattform Plazes gehört anscheinend nicht dazu. Schaut man unter www.maps.nokia.com mal nach, dann führt es einem u.a. zu der Seite maps.ovi.com. Vielleicht hat der Wissens- und Techniktransfer in diese Richtung stattgefunden, zu Vergleichen sind die beiden Anwendungen aber nicht.

Am Ende haben die Skeptiker wohl doch Recht behalten, die meinten, dass es Plazes an einem eindeutigen Konzept mangelte: “…hatte ich den Eindruck, Plazes würde in alle möglichen Richtungen ballern, ohne wirklich zu treffen.”, schreibt Johnny Haeusler in seinem bereits weiter oben erwähnten Artikel. Sechs Jahre nach dem Start von Plazes liegt die Plattform in ihrer alten Form anscheinend danieder, andere Services sind zum Teil recht erfolgreich auf den Zug der “Location Based Services” aufgesprungen. Claudio Schapsis liefert 2009 in seinem Blog eine Liste von 60 verschiedenen Anbietern, die noch nicht einmal vollständig ist. Auch hier ist Plazes noch gelistet, aber in dieser Form findet es kaum noch Zuspruch. Wie frustrierend das für manche ist, kann man anhand einer Fehler-Anfrage bei Plazes ganz gut nachvollziehen. Manchmal wäre es wohl besser, den Anwendern ein wenig genauer zu kommunizieren, wo die Reise eigentlich hingehen soll. So bleibt mir, wie vielen anderen auch, nur der Weg einen anderen Anbieter zu nutzen.