Thema: Webtrends

Jetzt wird Maß genommen

21. Januar 2011

Jetzt wird Maß genommen
Mit HTML5 kommen viele neue Auszeichnungsmöglichkeiten. Dazu gehören bspw. die Elemente progress und meter. Die Auszeichnungen haben das Ziel, die Information “sinnvoller”, auszuzeichnen als vorher. Progress – Klassisch der Fortschrittsbalken, Meter für Verhältnisangaben. Was kann man mit diesen neuen Auszeichnungen heute schon anstellen?

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

@font-face: CSS3 basierte Schriftvielfalt

15. Juni 2010

CSS3 basierte Schriftvielfalt
Das gab es doch schon mal – die Einbettung von Schriften über CSS. Richtig, vorgeschlagen wurde diese Möglichkeit schon beim Standard CSS2 aber mit der Fassung CSS2.1 wieder verworfen. Mit CSS3 kehrt font-face zurück und es ziehen alle Browserhersteller mit – Microsoft Internet Exporer, FireFox, Opera und Safari – alle unterstützen mittlerweile die Möglichkeit, eigene Schriften über eine Pfadangabe im CSS auf die Seite einzubinden. Der gestalterischen Freiheit sind damit keine Grenzen mehr gesetzt. Vorbei die Zeiten komplexer “Workarounds”, vorbei die Zeiten, in denen man nur zwischen ein paar “websicheren” Schriftarten wählen konnte. Klingt gut, stimmt es auch?

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

Seite 1 von 41234