Ich werde nun eine mutige Vorhersage machen. Lange nachdem wir nicht mehr auf dieser Erde verweilen wird HTML immer noch da sein. Nicht nur in Milliarden archivierter Seiten unserer Ära, sondern als ein lebendiges, atmendes Wesen. Zu viel Anstrengungen, Energie und Investitionen wurden in die Entwicklung von Webtools, Protokollen und Plattformen gesteckt um es so leicht aufzugeben.

Lasst uns über unsere Verantwortung nachdenken. Durch einen Zufall der Geschichte sind wir mit der Entwicklung eines der wichtigsten Kommunikationswerkzeuge unserer Zivilisation für die nächsten Jahrzehnte verbunden. Also, wenn wir, ob träumerisch oder ernsthaft, darüber nachdenken HTML zu verbessern müssen wir verstehen wie weitreichend die Verzweigungen unserer heutigen Entscheidungen sein könnten.

HTML 5, das W3C verdoppelte kürzlich die Anstrengungen um die nächste Generation von HTML in Form zu bringen, hat im letzten Jahr erheblich an Schwung gewonnen. Es ist ein gewaltiges Projekt, es umfasst nicht einfach nur die Struktur von HTML sondern auch das DOM, Algorithmen für Resourcenfetching, Mediainhalte, 2D Zeichnungen, Datentemplating, clientseitige Datenspeicherung, Modelle für Syntaxanalyse, Ausnahmebehandlung, Sicherheit und Pageloading und vieles mehr.

Es gibt außerdem Verbesserungen der Struktur, Syntax und Semantik von denen einige in „A Preview of HTML 5.“ von Lachlan Hunt gezeigt werden.

Aber in diesem Artikel wollen wir uns auf die Semantik konzentrieren. Sie ist etwas was mich seit vielen Jahren beschäftigt und sie ist meiner Meinung nach fundamental wichtig für die Zukunft von HTML.

Die BBC kündigte vor kurzem an, dass sie, aufgrund von Zugänglich- und Nutzbarkeitsüberschneidungen bei dem abbr-design-pattern, das hCalender Microformat aus ihren Programmübersichten entfernen wird. Dies zeigt das wir ohne jeden Zweifel die Semantik von HTML weit weg von dem was wir eigentlich wollten und auch weit weg von dem was eigentlich mit der Sprache möglich ist gebracht haben. Wir haben einfach die Kontrolle über die HTML Elemente und Attribute mit denen wir semantische Dokumente auszeichnen verloren. Wenn wir weiterhin so geschickt mit dem existierenden Konstrukt umgehen werden noch mehr Probleme wie dieses entstehen. Aber HTML leidet als semantische Auszeichnungssprache unter einem grundlegenden Mangel — die Semantik ist fest und nicht austauschbar.

Dies ist nicht einfach nur ein theoretisches Problem. Hunderttausende Entwickler nutzen das class und id Attribut um die Semantik Ihrer Dokumente zu verbessern. (Sie nutzen sie auch als „Haken“ für das Styling mit CSS aber das ist eine andere Baustelle.) Fast ausnahmslos verwenden diese Entwickler zum Inhalt passende Begriffe — diese sind, anstatt Werte von existierenden Schemas zu nutzten, selbst ausgedacht. Es ist bestenfalls pseudosemantisches Markup.

Viele Seiten im Web nutzen Microformate um mehr strukturierte Semantik einzusetzen als eigentlich in HTMLs dürftigen Satz von Elementen und Attributen vorhanden ist. In diesem Fall sind die Werte die für das class Attribut genutzt werden festgelegte Begriffe, manchmal übernommen aus vorhandenen Standards wie vCard, machmal sind es neu erdachte Begriffe für die vorher kein stabiler Standard vorhanden war (wie im Fall von hReview).

Erweiterbare Semantik

Es ist ein sehr reales Problem welches gelöst werden muss. Wir brauchen einen Mechanismus in HTML welcher Entwicklern die Möglichkeit geben muss klar und unzweideutig bessere und aussagekräftigere Semantik, nicht Pseudosemantik, in ihr Markup zu integrieren. Die ist vielleicht das dringlichste Ziel für das HTML 5 Projekt.

Aber es ist nicht so einfach einen neuen Mechanismus zu entwickeln: Es gibt bedeutende Einschränkungen für jede Lösung. Die vielleicht größte ist die Rückwärtskompatibilität. Die Lösung kann nicht Millionen an vorhandene und auch in den kommenden Jahren genutzten Seiten unbenutzbar machen. Jede Lösung die nicht rückwärtskompatibel ist wird aus Angst vor dem Ausschließen von Nutzern nicht weit genug von den Entwicklern angenommen. Sie würde schnell untergehen.

Die Lösung muss aber auch vorwärtskompatibel sein. Nicht in dem Sinne das sie in zukünftigen Browsern funktionieren muss — das liegt in der Verantwortung der Browserentwickler — aber sie muss erweiterbar sein. Wir können nicht erwarten das eine einzige Lösung die wir jetzt entwickeln alle vorstellbaren und unvorstellbaren semantischen Notwendigkeiten der Zukunft abdeckt. Wir können eine Lösung entwickeln die erweiterbar ist um zukünftigen Anforderungen entgegen zu kommen.

Diese zwei Aufgaben zusammen sind eine große Herausforderung. Aber im Kontext einer Sprache deren nächste große Überarbeitung in einem Jahrzehnt kommt und deren Einfluss auf eine globale Plattform für Kommunikation überragend ist muss diese Herausforderung gelöst werden.

Also wie löst HTML 5 dieses Problem? HTML 5 führt neue Elemente ein. Einige davon sind das was ich als „strukturell bedingt“ bezeichne — section, nav, aside, header, und footer. Das dialog Element ist eine Art Content-Element in Anlehnung an blockquote. Es gibt außerdem einige Datenelemente wie zum Beispiel meter und das time Element welches ein Datum und/oder eine Zeit markiert.

Auch wenn die Elemente nützlich sein können und auch schon einiges Interesse auf sich gezogen haben, lösen sie wirklich die Probleme die wir identifiziert haben, besonders in Anbetracht der Vor- und Rückwertskompatiblität?

Lasst uns jede Bedingung einzeln betrachten.

Rückwärtskompatibilität

Wie gehen gegenwärtige Browser mit neuen Elementen wie dem section Element um? Gut, die aktuellen Versionen von Safari, Opera, Mozilla, und auch der IE7 wird die Seite wie folgt rendern.

<h1>Top Level Heading</h1>

<section>
  <h1>Second Level Heading</h1>
    <p>this is text in a section element</p>
    <section>
      <h1>Third Level Heading</h1>
    </section>
</section>

Sieht nach einem guten Start aus. Aber wenn wir versuchen zu stylen, zum Beispiel das section Elemente mit diesem CSS:

section {color: red}

… können zwar die meisten der oben erwähnten Browsers das Element stylen aber der IE7 (und somit vermutlich auch der 6) können es nicht.

Also haben wir ein ernsthaftes Problem mit der Rückwärtskompatibilität in 75% der momentan genutzten Browser. Wenn wir uns die Halbwertszeit des Internet Explorers ansehen können wir voraussagen das auch noch in einigen Jahren die meisten Nutzer den IE6 oder den IE7 nutzen werden.

Wenn HTML 5 diese neuen Elemente einführt, wie hoch ist die Wahrscheinlich das die Mehrheit der Entwickler sie auch nutzen — das Wissen vorausgesetzt das sie im wesentlichen inkompatibel mit der Mehrheit der genutzten Browser sind?

Wenn wir nach einer alternativen Lösung für das CSS Problem schauen, das Setzen eines class Attributs für die section Elemente um sie dann über die Klasse zu stylen funktioniert es unglücklicherweise auch nicht im IE. Es gibt vielleicht einige Workarounds aber diese stellen auch keine praktikable Lösung da.

Weiter geht es mit der Vorwärtskompatibilität, der zweiten Bedingung.

Vorwärtskompatibilität

Starten wir mit der Frage: „Warum erfinden wir diese neuen Elemente?“ Eine begründete Antwort könnte sein: „Weil HTML nicht semantisch genug ist und durch die neuen Elemente steigern wir die Semantik“ — das kann nicht falsch sein, oder?

Durch das Hinzufügen dieser Elemente zeigen wir das HTML mehr semantische Fähigkeiten braucht. Aber nur in einem engen Anwendungsbereich. Egal wie viele Elemente wir aussieben wir werden immer denken das es nicht ausreicht. Also, wir können so viele Elemente hinzufügen wie wir wollen, es wird das Problem nicht lösen. Wir brauchen nicht spezielle Ausdrücke zu den Begriffen von HTML hinzufügen, wir müssen eine Mechanismus einbauen der es uns erlaubt einem Dokument so viel semantische Fülle zu geben wie es braucht. Wir müssen HTML erweiterbar machen. HTML 5 enthält keinen Mechanismus für Erweiterbarkeit.

HTML 5 implementiert Dinge die in einem großen Prozentsatz der aktuellen Browser nicht funktionieren und uns somit überhaupt nicht erlaubt wirklich die Semantik zu erweitern.

Verschiedene Fragen betreffend dieser neuen Elemente bleiben über. Woher kommen die Namen? Wie wurde es entschieden das es ein Element für die Navigation gibt das "nav" genannt wird? Warum sollen die selbe Bedingung auch auf andere Navigationen zutreffen?

Warum keine Begriffe aus existierenden Systemen, so wie Docbook, übernehmen? Seine Dokumentstruktur ist viel reichhaltiger und es wurde über viele Jahre von Puplishing-Experten entwickelt. Dies ist kein Argument zugunsten von Docbook speziell: Der Punkt ist das die extrem wichtige Aufgabe die Semantik von HTML zu erweitern sich nicht plötzlich stellt weshalb sich ein Blick auf die besten Arbeiten der letzten 30 Jahre lohnt. (Ursprünglich begann die Arbeit an GML in den frühen Siebzigern).

Einige Gedanken über eine Lösung

So, ich kritisiere die gegenwärtigen Bemühungen, habe ich auch eine praktische Lösung für das Problem? Nun, ich habe zumindest einen Anfang.

Wenn das Hinzufügen neuer Elemente in HTML nicht in Frage kommt, zumindest nicht innerhalb dieser Diskussion, sind logischerweise die Attribute der Bereich von HTML auf den wir uns konzentrieren sollten. Für fast ein Jahrzehnt haben wir class und id Attribute zur Erweiterung von HTML genutzt. Ein Großteil der Entwickler sind den Umgang mit diesen gewohnt. Das Microformat Projekt zeigt das die existierenden Attribute von HTML nicht ausreichen um die Semantik von HTML zu erweitern. Also, wenn wir Attribute zur Lösung dieses Problems nutzen möchten, müssen wir ein oder mehr neue Attribute hervorbringen. Bevor wir darauf eingehen wie das funktioniert ist es nur fair wenn wir für diesen Vorschlag die gleichen Anforderungen stellen die wir auch an die neuen HTML 5 Elemente stellen. Das Wichtigste, ist die Einführung neuer Attribute rückwärtskompatibel? Und wenn sie es ist, bietet sie einen funktionierenden Mechanismus um die Semantik zu erweitern?

Erfinden wir ein neues Attribut. Ich nenne es „structure,“ aber der genaue Name ist nicht von Bedeutung. Wir können es so nutzen:

<div structure="header">

Schauen wir wie unsere Browser damit umgehen.

Natürlich werden alle Browser diese Elemente mit CSS gestalten.

div {color: red}

Aber wie ist es hiermit?

div[structure] {font-weight: bold}

Beinahe alle Browser, einschließlich des IE7, stylen das div tatsächlich obwohl das structure Attribut überhaupt nicht existiert! Leider verlässt uns unser Glück nun, der IE6 tut es nicht. Aber wir können das Attribut in HTML nutzen und alle Browser können damit umgehen. Wir können sogar mit CSS unser HTML für alle modernen Browser stylen. Und wenn wir einen Workaround für alte Browser brauchen können wir ein class Attribut anfügen und darüber stylen. Vergleicht das mit der HTML 5 Lösung welche neue Elemente hinzufügt die nicht im Internet Explorer 6 oder 7 gestyled werden können und ihr seht das dies eine definitiv rückwärtskompatiblere Lösung ist.

Erweiterbarkeit der Attribute

Anstelle von neuen Elementen sollte HTML 5 einige neue Attribute hinzufügen. Jedes dieser Attribute würde Bezug zu einer bestimmten semantischen Kategorie oder einem Typ haben. Zum Beispiel, wie ich in einem anderen Artikel detailliert beschreibe, umfasst HTML strukturelle Semantik, rhetorische Semantik, funktionsbezogene Semantik (übernommen von XHTML) und andere Klassen oder Kategorien.

Diese neuen Attribute können genau so genutzt werden wie das class Attribut: Um dem Element Angaben hinzuzufügen die es beschreiben oder ergänzendes zum Inhalt enthalten.

Dies ist nicht unähnlich dem role Attribut von XHTML aber anstatt nur ein Attribut „Behältnis“ zu haben sollten wir die verschiedenen semantischen Typen separieren.

Das XHTML role Attribut arbeitet zum Beispiel so:

<ul role="navigation sitemap">
  <li href="downloads">Downloads</li>
  <li href="docs">Documentation</li>
  <li href="news">News</li>
</ul>

Die Werte des role Attributs sind eine durch Leerzeichen getrennte Liste aus den vorgegebenen Begriffen.

Warum nicht das role Attribut übernehmen so wie es ist? Nun, es gibt noch andere Arten von Semantik für die die Bezeichnung „role“ nicht passt. Zum Beispiel:

<p rhetoric="irony">He’s a fantastic person.</p>

Dies zeigt einen theoretischen Typ von Semantik — „rhetoric“ — welcher eingesetzt werden könnte um die rhetorische Beschaffenheit zu beschreiben. Dieses Element hat natürlich nicht die Aufgabe „Ironie“ in dem Dokument, vielmehr ist der Inhalt des Elements ironisch.

Hier ein anderes Beispiel. Es zeigt sich immer mehr das HTML die Möglichkeit fehlt um maschinenlesbare Angaben an für Menschen optimierte Inhalte anzufügen, wie z.B. bei einer Zeitangabe. Dies ist das Hauptproblem das die BBC wie bereits erwähnt mit dem hCalendar Microformat hatte. Während <span role="2009-05-01">May Day next year</span> nicht wirklich sinngemäß ist, ist <span equivalent="2009-05-01">May Day next year</span> durchaus sinnvoll.

Auch hier ist es egal ob wir „equivalent“ nutzen oder eine andere Bezeichnung. Wichtig zu wissen ist nur das es nicht so simpel ist wie das class Attribut oder das role Attribut als Einheitsbehältnis für alle semantischen Informationen zu nutzen. Für eine sauber erweiterbare Lösung die Rückwärtskompatiblität und genügend Flexibilität gewährleistet wäre eine Lösung in die oben beschriebene Richtung zumindest in Betracht zu ziehen.

Ich habe diesen Absatz mit „Einige Gedanken über eine Lösung“ betitelt weil der wichtige Teil der Arbeit das Entwickeln einer durchführbaren Lösung ist. Offene Fragen sind folgende.

• Wie viele unterschiedliche Semantik-Attribute soll es geben? Sollen diese Kategorien erweiterbar sein und wenn ja, wie?
• Wie werden die Begriffe festgelegt?
• Sollen wir die Werte die wir brauchen einfach erfinden, so wie die Entwickler es bei den class Werten tun oder sollen alle Werte in einer standardisierten Spezifikation festgelegt werden? Oder soll es eine Technik geben um, über eine Art Profil, Begriffe zu erfinden (und hoffentlich auch zu teilen)?
• Wenn ein Konflikt zwischen zwei Begriffen auftritt, beispielsweise wenn zwei identische Ausdrücke durch zwei verschiedene Begriffe definiert werden, wie wird er gelöst?
• Brauchen wir eine Form von Namensraum oder existiert eine andere Technik?

Anstelle von einer gehetzter Beantwortung dieser Fragen werfe ich sie auf um die Aufgaben die erfüllt werden müssen hervorzuheben. Und um einen Dialog zu starten. Die Verzweigungen und der Umfang der Entscheidungen die für HTML 5 getroffen werden müssen sind zu groß um sie ohne tiefgreifende Kenntnisse über Linguistik, Semantik, Semiotik und verwandte Bereiche zu treffen.

Hoffentlich ist es, wenn schon sonst nichts, klar, dass einfaches Erfinden neuer Elemente die Semantik von HTML nicht erweitert.

Lasst uns diese Entscheidungen nicht leichtfertig treffen — mit dem Klimawandel haben wir unsere Enkel schon genug belastet. Lasst uns ihnen das bestmögliche HTML hinterlassen.

Kommentare & Diskussion

Markup

• Trennen Sie Inhalt vom Layout und nutzen Sie passende Auszeichnungen für die Struktur Ihrer Seite. Nutzen Sie beispielsweise Listen (<ul>, <ol>, <dl>) anstelle von Text mit einem <br> nach jedem Punkt.
  • Semantischer Code - Definitionen, Methoden, Zweifel
  • What Beautiful HTML Code Looks Like [en]
• Markieren Sie sorgfältig die Abschnitte Ihrer Seite mit Überschriften (wie <h1>) anstelle von Elementen wie <p> die mit CSS wie Überschriften gestaltet sind.
  • Hinweise zu Überschriften und Hierarchien
  • Studie: Überschriften und Barrierefreiheit
• Geben Sie Ihren Seiten durch das <title> Element klar verständliche Titel.
• Geben Sie die primäre Sprache Ihres Dokumentes über das lang Attribut im <html> Element an. Wenn einzelne Passagen Ihres Inhaltes in einer anderen Sprache sind wenden Sie das lang Attribut auf das umschließende Element an (z.B. "<span lang="es">Hola</span> bedeutet Hallo”).
  • Das lang-Attribut
  • Language information and text direction [en]
• Wenn Ihre Seite noch vor dem Inhalt sehr viele Navigationslinks hat nutzen Sie Sprunglinks am Anfang Ihres <body>.
  • Skip to Main Content Links are Important [en]
• In Datentabellen müssen Überschriften mit <th> gekennzeichnet und mit den Tabellenzellen eindeutig verbunden werden.
  • Barrierefreie Tabellen
• Wenn es nötig ist stellen Sie sicher das Ihre Tab-Ordnung durch tabindex logisch aufgebaut ist (Sind Ihre HTML Elemente in der richtigen Reinfolge ist der Gebrauch von tabindex nicht nicht notwendig).
  • Tabben statt Klicken
  • Tabindex zweitrangig

Äussere Erscheinung und Inhalte

• Ihre Seite sollte auch mit deaktivierten Bildern nutzbar sein (das schließt ein das noch genügend Kontrast vorhanden ist wenn ein Hintergrundbild genutzt wird und selbiges entfernt wurde).
  • Gestaltung mit Bildern - Dekorative Bilder
• Stellen Sie sicher das Ihre Seite nutzbar bleibt wenn der Text auf das doppelte seiner originalen Größe vergrößert wird.
• Jedes Element Ihrer Seite sollte auch mit der Tastatur erreich- und änderbar sein.
  • Navigieren ohne Maus
• Nutzen Sie, wann immer es möglich ist, sinnvolle Überschriften und Linktexte die auch ohne den Kontext verstanden werden (z.B. keine “Klick hier” Links).
  • Was Content-Management-Systeme nicht leisten können - Treffende Linkbezeichnungen
• Ihre Seite sollte auch für Farbblinde und Nutzer mit eingeschränkter Sehkraft ausreichend Kontrast bieten.
  • Farb Kontrast Analyse - Accessibility der Farben
• Setzten Sie keine Inhalte ein die öfter als 3 mal in der Sekunde (auf)blinken.
• Sorgen Sie dafür das die Fokus-Anzeige sichtbar bleibt. Wenn ein Nutzer mit der Tastatur von einem Element zum Nächsten navigiert sollte er immer wissen wo er sich befindet.
  • Keyboard-Friendly Link Focus [en]
• Der Inhalt sollte für den Nutzer auch ohne besondere Kennzeichnung durch Schriftart, Farben oder sonstige gestalterische Mittel verstehbar sein. Schreiben Sie zum Beispiel nicht "Das hervorgehobene Wort in diesem Absatz ist das Wichtigste" oder "Die rot markierten Punkte sind Fehler und sollten berichtigt werden" wenn das Wort oder der Punkt auch anders angezeigt werden könnte.

Dynamische Inhalte

• Benutzen sie Javascript Ereignisse nicht, die den Inhalt der kompletten Seite ändern oder automatisch eine neue Seite laden.
  • Barrierefreies JavaScript

Bilder und Multimedia

• Stellen Sie sicher das alle Bilder über ein alt Attribut verfügen, bei Grafiken, die nur dem Layout dienen, vergeben Sie keinen Wert.
  • Sinnvoller Gebrauch des ALT-Attributs
• Halten Sie den alt Text kurz und prägnant (z.B. “Der Hauptbahnhof Berlin") aber gehen Sie ins Detail wenn es das Verständnis verbessert (z.B. Familie Meier am Gleis 15 im Hauptbahnhof Berline").
• Stellen Sie für alle Audio und Video Inhalte mit Sprachanteilen eine Abschrift, Untertitel und/oder eine Übersetzung in Gebärdensprache zur Verfügung.
  • Multimedia-Inhalte (Video-Filme) barrierefrei im Internet präsentieren
• Stellen Sie, wenn nötig, eine Audiobeschreibung der Inhalte eines Videos die für blinde Nutzer allein durch den Ton nicht vermittelt werden (z.B. Herr A. bewegt sich durch eine Tür und nickt) zur Verfügung.
• Alle Videos sollten zumindest zugängliche Bedienelemente haben.
  • Audio-Beschreibung oder Transcript für blinde Menschen?
• Wenn Text vom Browser ohne Probleme gerendert werden kann vermeiden Sie die Verwendung von Bilder anstelle von Text.
  • Web Fonts
• Vermeiden Sie CAPTCHAs es sei den Sie haben keine andere Wahl und auch dann sollten Sie vermieden werden. Wenn sie unumgänglich sind stellen sie eine Audio Alternative zur Verfügung.
  • Grafische Zugangscodes sperren blinde Internetnutzer aus

Formulare

• Bezeichnen Sie alle Ihre Formularfelder mit dem <label> Element. Wenn für ein Feld keine spezielle Bezeichnung nötig ist fügen Sie trotzdem eine ein und verstecken Sie sie mit CSS oder nutzen Sie das title Attribut.
  • Die explizite Bezeichnung von Eingabefeldern und Auswahlmenüs (mit dem <label>-Element)
• Nutzen Sie Feldgruppe (<fieldset>) mit Legenden (<legend>) um inhaltliche Blöcke zu bilden.
  • Too much accessibility - <fieldset> <legend> [en]
• Geben Sie alle Eingabefehler in Text aus (gegebenfalls mit einem zusätzlichen Bild oder Icon) und platzieren Sie die Fehlermeldung direkt bei dem betroffenen Feld oder in an einer hervorstehenden Position wie dem Seitenanfang zusammen mit einem Ankerlink zu dem betroffenen Feld.
• Wenn es nötig ist versehen Sie Ihre Formularfelder mit Anleitungen oder Hilfe-Links.
• Erlauben Sie dem Benutzer nicht wichtige Aktionen zu beenden ohne sie zu bestätigen oder einer Möglichkeit sie rückgängig zu machen.
• Vermeiden Sie es HTML Elemente für etwas anderes als ihre eigentliche Aufgabe zu nutzen (z.B. Formulare für die Navigation, Links zum Absenden eines Formulars, etc.)

Testen

• Alle Seiten sollten mit dem W3C Validator (http://validator.w3.org/ [en]) getestet werden.
• Schauen Sie, mit Hilfe von Simulatoren oder Browser-Erweiterungen (Empfehlung: http://colororacle.cartography.ch [en] oder http://www.vischeck.com [en]), ob Ihre Seiten auch für Farbenblinde nutzbar sind.
• Testen Sie alle Ihrer Seiten auf Zugänglichkeit (WAVE Web-Accessibility Auswertung [en]).
• Lassen Sie Ihre Seiten von einem Accessibility Experten überprüfen.

Leider war es nicht immer so. In Zeiten von Tabellen-Layouts und Spacer-GIFs war HTML einfach nur Mittel zu Zweck. An den Folgen haben wir bis heute zu leiden. Leider sieht man, auch bei aktuellen Seiten, dass häufig alte Tabellen-Layouts einfach durch vielfach verschachtelte DIVs ersetzt werden. Jedem Element wird eine Klasse oder eine ID zugewiesen, Styleangaben werden direkt in das Dokument geschrieben, viele Inhalte werden durch nichtssagende DIV oder SPAN Container umschlossen.

Doch damit bleibt man weit hinter den Möglichkeiten. HTML ist eine Auszeichnungssprache und sollte auch so genutzt werden. Angaben zum Layout müssen, wann immer es möglich ist, in die CSS Dateien verlagert werden. Leider sind sich viele Web-Entwickler nicht bewusst welche Möglichkeiten sich durch CSS ergeben.

Des weiteren ist es wichtig das die Inhalte mit den dafür vorgesehenen HTML Tags ausgezeichnet werden. Nur so kann eine Maschine die Inhalte vollständig auswerten. Dieser Einsatz reduziert sich im übrigen nicht nur auf die Überschriften (H1 - H6). Auch andere andere Elemente wie Listen und Zitate sollten genutzt werden.

Die Verwendung von semantisch korrekten Elementen ist keine zusätzliche Arbeit. Und auch die effektive Vergabe von IDs und Klassen verbessert die Übersichtlichkeit des Quellcodes deutlich.

Ein kleines (natürlich etwas überspitzes) Beispiel sollte verdeutlichen dass mit wenigen Änderungen viel erreicht werden kann:

Beispiel

Vorher:

HTML

<div id="nav_box">
  <div id="liste">
    <span class="listen_punkt">
      <a class="link" href="#">Link</a>
    </span>
    <span class="listen_punkt" id="aktiv>
      <a class="link" id="link_aktiv" href="#">Link</a>
    </span>
  </div>
</div>

CSS

#nav { ... }
#list { ... }
.link { ... }
.aktiv { ... }
#aktiv { ... }
#link_aktiv { ... }

Nachher

HTML

<div id="nav">
  <ul>
    <li><a href="">Link</a></li>
    <li class="aktiv"><a href="">Link</a></li>
  </ul>
</div>

CSS

#nav { ... }
#nav ul { ... }
#nav li { ... }
#nav li a { ... }
#nav li.aktiv { ... }
#nav li.aktiv a { ... }

Fazit

Wer seine Inhalte mit den semantisch passenden Elementen versieht erleichtert sich nicht nur die Arbeit sondern kommt auch bei den Suchmaschinen besser an. Durch die geschickte Verschachtelung von CSS Regeln kann man den Einsatz von Layout bezogenen Angaben stark reduzieren.

Darum ist bei der Gestaltung von Webseiten die Typografie eine zentrale Herausforderung. Leider ist der Gestalter, anders als bei Printprodukten, durch technische Vorgaben stark eingeschränkt. Auch wenn verschiedene Techniken wie SIFR oder Image-Replacement es theoretisch möglich machen jede Schrift zu verwenden bleibt am Ende doch nur die Gestaltung mit CSS.

Mit CSS kann der Autor durch verschiedene Eigenschaften einfluss auf das angezeigte Schriftbild nehmen. In CSS1 mussten alle Schriften auf dem Client System vorhanden sein, sie wurden nur anhand ihres Namens ausgewählt. Alternative Schriften konnten zwar in den Eigenschaften angegeben werden aber abgesehen davon hatten Browser keine Möglichkeit dem User eine andere Schrift als die allgemein verbreiteten Schriften vorzuschlagen.

Dies sollte sich eigentlich mit CSS2 ändern. Nach der CSS2 Recommendation könnten die Stylesheet Autoren genau angeben welche Schrift verwendet werden soll:

Die @font-face Regel

Jeder Browser enthält eine „Schriftdatenbank“. Diese Schriftdatenbank enthält die Schriften die der User in seinem System aktiviert hat. Auf diese Schriften kann man mit CSS zugreifen. Da diese Schriften aber je nach Betriebssystem stark variieren hat das W3C, um den Autoren die größtmögliche Freiheit zu geben, die At-Regel @font-face erarbeitet. Mit dieser Regel hat man die Möglichkeit dieser Datenbank Schriften hinzuzufügen.

Leider gehörte die Regel zu den Teiltechniken die von den Browserherstellern nur unzureichend umgesetzt wurden, weshalb sie in der Zwischenversion CSS 2.1 nicht mehr vorhanden war.

Nun wurde diese Technik schon im Jahre 2002 wieder aufgegriffen und in das CSS3 Modul Web Fonts eingesetzt. Leider hat es bis jetzt (Stand April 2008) gedauert bis die ersten Browserhersteller diese Funktion in ihre Programme eingebaut haben. Der Safari 3.1 ist der erste stabile Release der mit der @font-face Regel umgehen kann.

Update: Firefox 3.1 wird @font-face ebenfalls unterstützen. Ein Sneak Peek kann man bei Ralf Herrmann betrachten.

Update 2: Status Browserunterstützung 04/09

Die Technische Umsetzung ist relativ einfach. Mit der @font-face Regel hat man die Möglichkeit jeweils einen Schriftschnitt einzubinden sowie ihn genauer zu beschreiben. Die Beschreibung erfolgt durch die bereits weitläufig bekannt und eingesetzten Schrifteigenschaften:

• font-family - Deklariert den Namen der Schriftfamilie. Außerdem kann eine generische Schriftfamilie angegeben werden
• src - Verweißt auf tatsächliche Schriftdaten, egal ob herunterzuladen oder lokal installiert
• font-style - Gibt an ob die Darstellungen normal (manchmal auch als „roman“ oder „upright“ bezeichnet), kursiv oder geneigt ist
• font-variant - Bezeichnet einen Kapitälchenschnitt
• font-weight - Legt das Gewicht des Schriftschnittes fest
• font-stretch - Bezeichnet die Ausdehnung des Schriftschnittes
• font-size - Ist der Deskriptor für die durch diese Schrift unterstützten Größen. Es sind, im Gegensatz zur Eigenschaft font-size, nur absolute Längeneinheiten erlaubt

Zu beachten ist das bei allen Deklarationen Mehrfachnennungen durch Kommaseparation möglich sind.

Übersicht der Eigenschaften sowie der zugelassenen Werte

Beispiel

Die @font-face Regel im Einsatz

Als Schriftfamilie muss die Delicious von Jos Buivenga herhalten.

Da die Implementierung der Regel im Safari 3.1 anscheinend fehlerbehaftet ist (Details) habe ich mich auf die Schriftschnitte Roman, Bold, Italic und Bold Italic beschränkt. Small-Caps und Heavy haben Einfluss auf den Roman Schnitt, hier muss wohl noch nachgebessert werden.

Erläuterung

Definition der Schriftschnitte

@font-face {
font-family: Delicious;
src: url('fonts/delicious/Delicious-Roman.otf') format("opentype");
}

@font-face {
font-family: Delicious;
src: url('fonts/delicious/Delicious-Bold.otf') format("opentype");
font-weight: bold;
}

@font-face {
font-family: Delicious;
src: url('fonts/delicious/Delicious-Italic.otf') format("opentype");
font-style: italic;
}

@font-face {
font-family: Delicious;
src: url('fonts/delicious/Delicious-BoldItalic.otf') format("opentype");
font-style: italic;
font-weight: bold;
}

Diese Regeln fügen die Schriftfamilie Delicious der Schriftdatenbank des Browsers hinzu wobei die erste Regel für den allgemeinen Schnitt (Roman) und die folgenden für die speziellen Schnitte zuständig sind. Das heißt sobald keine Spezifikation über eine der angegebenen Eigenschaften vorliegt wird automatisch auf den Roman Schnitt zugegriffen.

Aus Gründen der Übersichtlichkeit, und da sie vom Validator momentan noch als Fehler erkannt werden, empfiehlt es sich die @font-face Regeln in eine gesonderte Datei zu schreiben und via @import in die eigentlich CSS Datei einzubinden.

Einsatz der Schriftfamilie

Um die hinzugefügte Schriftfamilie zu nutzen reicht es aus sie einfach wie gewohnt in der font-family anzugeben.

font-family: Delicious, Arial, sans-serif;

Browser die @font-face Regel nicht beherrschen greifen so einfach auf die nächste Angabe zu. Die jeweiligen Schriftschnitte werden übernommen sobald eine der Bedingungen (z.B. font-weight: bold;) erfüllt ist.

Anhang

Links

• Demo Seite von fonts.info
• Eintrag in der Typowiki von typografie.info
• Artikel bei A List Apart
• @font-face Twitter Account

Schriften die die Nutzung in @font-face erlauben (Lizenzbedingungen beachten!)

• Delicious
• Graublau Sans Web
• Vollkorn

Methoden gibt es einige. Nur leider ist keine davon universell einsetzbar.

opacity

Opacity ist eine Eigenschaften welche eigentlich erst mit CSS3 in die Browser implementiert werden sollen. Zulässig sind Werte zwischen 0.00 (totale Transparenz) und 1.00 (keine Transparenz). Um z.B. ein Bild zur Hälfte transparent zu machen reicht dieser Code in der dazugehörigen Regel:

opacity: 0.5;

Beispiel

filter:Alpha()

Nicht alles an Microsofts Browser ist schlecht. Er hat zum Beispiel seit der Version 4.0 einige nette CSS Eigenschaften welche man eigentlich nur aus dem Bereich der Bildbearbeitung kennt. Auch für die Transparenz gibt es eine Eigenschaft. Dieser Code bewirkt eine halbe Transparenz:

filter: alpha(opacity=50);

Update für den IE 8: Für den neuen, standardkonformen, CSS Parser musste die Syntax leicht angepasst werden.

Beispiel

Halbtransparentes PNG

Anders als in bei JPEG’s und GIF’s kann man bei PNG’s einem Pixel eine bestimmte Transparenz zuweisen. In Photoshop geht das so:

1. 10×10 Pixel großes Bild mit transparentem Hintergrund erstellen
2. Eine neu Ebene erstellen und mit der gewünschten Farbe füllen
3. Dieser Ebene die gewünschte Transparenz geben
4. Für Web speichern und PNG auswählen

Beispiel

Wie man sieht gibt es keine perfekte Möglichkeit. Wer auf validen Code Wert legt muss wohl oder übel auf den IE 6 verzichten welcher ja leider noch sehr weit verbreitet ist. Aber da der IE 7 nun endlich auch halbtransparente PNG’s unterstützt ist sieht die Zukunft um einiges besser aus.

Leider belässt der Spiegel es beim theoretischen Teil - mit diesem Tutorial will ich deshalb auf die Praxis der HDR-Fotografie eingehen:

HDR Fotografie ist das “Übereinanderlegen” von unterschiedlich belichteten Fotos ein und desselben Motivs. Durch Überbelichten treten Schatten hervor, durch Unterbelichten werden helle Stellen (z.B. der Himmel) besser erkennbar:

1. Motiv: Bewegte Objekte sind grundsätzlich tabu. Fürs erste HDR Bild eignet sich besonders ein Sonnenuntergang, wegen der dunklen Schlagschatten und der vereinzelt grellen Farben, wer von den ewigen Sonnenuntergängen genug hat sollte zumindest auf besagte Hellifgkeitsunterschiede achten.
2. Kamera: Die Anforderungen an die Kamera selbst sind vergleichsweise gering: Sie sollte über einen manuellen Modus verfügen, alternativ reicht auch eine Belichtungsreihen-Funktion (”Bracketing”). Idealerweise setzt man den Weißabgleich fest um jeder Verfärbung vorzubeugen. Besitzer von analogen Kameras haben es ausnahmsweise besonders einfach.
3. Aufbau: Die Kamera muss sicher stehen. Nachträgliche Änderungen an Belichtungszeit und Blendenöffnung müssen ohne Verschiebung des Geräts möglich sein. Ein schweres Stativ und ein sicher befestigter Fotoapparat eignen sich daher besonders gut. Abzüge gibts für weiche Böden (Gras) und wacklige Kugelstative ohne ausreichende Fixierung.
4. Bilderserie: HDR Bilder zeichnen sich vorallem durch Farb- und Detailgetreue aus, daher ist es wünschenswert die Blendenöffnung hoch zu setzen (also die Blende möglichst weit zu schließen). Nachdem die Blende gesetzt wurde fängt man mit einer enorm unterbelichteten Aufnahme (-3.0) and und geht dann in 3-10 Bildern zu einer stark überbelichteten Aufnahme (+3.0) über. Die Anzahl der Bilder ist dabei nicht begrenzt - meist genügen jedoch 3 Bilder, mit 5 ist man auf der sicheren Seite. Vereinzelt findet man Verfechter des RAW-Formats, dabei wird das Rohbild direkt vom CCD abgespeichert, Weißabgleich oder ggf. auch Nachschärfung müssen dann per Software vom Fotografen erledigt werden. Als Belohnung für die Mühen enthält das RAW-Format dafür wesentlich mehr Bildinformation als beispielsweise ein *.jpeg.
5. Überprüfen der Bilder: Am einfachsten läd man die Bilder auf den heimischen Rechner und anschließend in eine Dia-Show (Windows Bildanzeige, bzw Linux- oder Mac-Equivalent) und achtet auf mögliche Verschiebungen während die Bilder wechseln. Sollte alles in Ordnung sein gehts direkt zum nächsten Schritt, falls nicht muss man entweder einzelne Ausrutscher löschen oder den ganzen Prozess wiederholen.
6. HDR Bild: Ein Bild im .hdr Format enthält alle Bildinformationen von sämtlichen Einzelbildern. Die Trial Version von Photomatix erzeugt solche Bilder (Im Menu unter HDR > Generieren) ohne Einschränkungen. Aber auch Photoshop ab Version CS2 weis mit HDR umzugehen (Datei > Automatisieren > HDR).
7. Tone Mapping: Der eigentliche Teil der Arbeit ist das Extrahieren der “nützlichen” Bildinformationen aus dem HDR-Wust. Das oben genannte Photomatix kann eben das, allerdings wird das Bild in der Trial Version mit Wasserzeichen verunstaltet. Aternativ gibt es die kostenlose Basic Version von FDRSoft.
8. Nachbearbeitung: In den meisten Fällen reicht Tonemapping bereits aus um ein sehr brauchbares Ergebnis zu erhalten. Dennoch ist es sinnvoll das HDR Bild in einem Grafikprogramm nachträglich in Helligkeit und Kurven zu verändern. Dazu öffnet man z.B. in Photoshop das Bild, selektiert die gesamte Bildfläche (Strg + A), kopiert den Inhalt (Strg + C) und fügt das Kopierte unter Datei > Neu in ein “normales” Bild ein. Ein Anheben der Kontraste ist oft nicht notwendig, stattdessen sollte man die Farbverteilung anpassen und mit den Kurven experimentieren.

Viele mögliche Ausgänge dieses Vorgangs sind auf Flickr ausgestellt.