Kategorien
Design HTML/CSS

Empfehlungen für gute ID- und Klassennamen

ID– und Klassennamen haben nicht unwesentlichen Einfluss auf die Wartbarkeit von HTML-Dokumenten und entsprechend wichtig ist es, geeignete Namen zu gebrauchen. Zusammenfassend gilt, IDs und Klassen, wenn möglich, zu vermeiden, ansonsten funktionale, im Zweifelsfall generische Namen einzusetzen und dabei auf »verständliche Knappheit« zu achten.

Im folgenden nehmen wir uns den IDs und Klassen in ihrer Funktion als Stylesheet-Selektoren an. Gemäß HTML-Spezifikation haben diese mehrere Rollen. So können IDs beispiels- und bekanntlicherweise auch als Link-Ziel sowie als Elementreferenz beim Scripting dienen.

Grundregeln für gute ID– und Klassennamen

Die Problematik ist alt, die in priorisierter Reihenfolge gegebenen Empfehlungen immer noch jung:

  1. Beschränken Sie den Einsatz von IDs und Klassen auf ein Minimum.
    Diese Vorgehensweise ist am einfachsten zu merken und anzuwenden. Sie stellt das geringste Wartbarkeitsproblem dar. Inhaltliche und funktionale Änderungen, die immer vorkommen können und gegen die man sich nicht schützen kann, muss und sollte, dürfen nicht mit rein optischen Änderungen verwechselt werden.
  2. Verwenden Sie funktionsbezogene ID– und Klassennamen.
    Es ist für gewöhnlich die nächstbeste Wahl, Namen von der Funktion abzuleiten, wie beispielsweise nav, warnung, oder fehler. Solche Namen haben nicht nur einen strukturellen Bezug, sondern können auch einem konzeptionellem Verständnis und der Zusammenarbeit helfen. Funktionsverwandte Namen helfen der Wartbarkeit und es bleibt im Hinterkopf, dass, sollte das jeweilige Element einmal seine Bedeutung ändern,
    substantiellere Änderungen wie neue Inhalte erforderlich sind.
  3. Verwenden Sie neutrale ID– und Klassennamen.
    Wenn Sie keinen vernünftigen funktionellen Namen bestimmen können oder Sie eine ausschließlich darstellungsbezogene ID oder Klasse einführen (wie bei alternierenden Tabellenzeilen), empfiehlt es
    sich, neutrale, generische Namen zu wählen. Beispiel sind alt, »alternativ«/»Alternative« oder aux. Diese Option ist hinsichtlich Verständnis und Kollaboration nicht unbedingt die beste, aber eben auch kein Wartungsproblem.
  4. Allgemein: Bevorzugen Sie Namen, die so kurz wie möglich,
    aber so lang wie nötig sind.
    Versuchen Sie, auf den Punkt zu kommen (nav), aber opfern Sie nicht unbedingt Verständlichkeit (kontakt).

Das wirklich unempfehlenswerteste, was man machen kann, ist, präsentationsbezogene Namen zu verwenden, wie die unseligen rechts, lila, 1024 et cetera. Solche Namen sind um jeden Preis zu vermeiden, da sie letztlich alle Vorteile von CSS rauben, und Sie bei Darstellungsänderungen also gezwungen wären, das HTML zu ändern.

Noch bessere ID– und Klassennamen

Es sind im Zusammenhang mit ID– und Klassennamen mindestens zwei »Boni« zu nennen, die in bestimmten Situationen wertvoll sind, zum einen »Pseudo-Namensräume« und zum anderen »Chamäleonsemantik«:

  1. »Pseudo-Namensräume« sind Präfices vor IDs und Klassen, die primär dazu beitragen können, Code in unbekannter Umgebung zu »schützen« (à la produktname-*). Auch wenn diese Pseudo-Namensräume dem konzeptionellem Verständnis dienen können, ist die Idee dahinter, die Wahrscheinlichkeit von unerwünschten Nebeneffekten zu minimieren (wenn der gewünschte Name bereits vergeben sein könnte oder mehr als einmal vergeben werden soll) und dadurch mehr Freiheit zu gewährleisten. Das Thema verdient insgesamt jedoch separate Behandlung.
  2. »Chamäleonsemantik« bezieht sich auf Namen, die ihre Bedeutung ändern können, wie zum Beispiel spalte-1 und spalte-2. Üblicherweise findet man sie auf mehrspaltigen Seiten vor, und dort in der Bedeutung von »Spalte 1« und »Spalte 2«, weswegen man einen Präsentationsbezug wittern mag. Eine mögliche Layout-Änderung auf ein einspaltiges Design muss aber dennoch keine HTML-Änderung bedeuten und zwar dank besagten Chamäleoneffekts: spalte-1 und spalte-2 könnten durchaus als »Spalte, Teil 1« und »Spalte, Teil 2« verstanden werden.

Kategorien
Webdesign

Kosten der Lösung versus Kosten des Problems

Probleme kosten Geld und Probleme erfordern Lösungen, die ebenfalls Geld kosten. Diese Situation ist in allen Bereichen und Branchen präsent, doch in vielen Fällen wird nur auf eins geschaut: Wieviel kostet die Lösung eines Problems? Vernachlässigt wird die Kehrseite, nämlich die Kosten des Problems.

Die Kosten einer Lösung sind einfach zu bestimmen. Man ermittelt, was für zeitliche und letztlich monetäre Aufwände notwendig sind, um sie zu erarbeiten und zu implementieren. Man konzentriert sich auf die aufzuwendenden Ressourcen.

Die Kosten des Problems entsprechen den finanziellen Folgen, wenn man nichts tut, wenn man das Problem bestehen lässt. Seine Lösung birgt dementsprechend nicht nur Kosten, sondern verfügt auch über einen Wert. Wird das Augenmerk ausschließlich auf Problemlösungen gerichtet. Egal, wie diese motiviert sind, ist zumindest „unklar“, ob tatsächlich wirtschaftlich gearbeitet wird. Einsicht in sowohl Kosten als auch Wert einer Lösung sind essentiell, um ökonomisch handeln zu können. Die einzige Ausnahme mag der Wunsch nach Perfektion sein, denn Perfektion ist ein teurer Sport, ein Luxus von Idealisten, nicht aber von Pragmatikern und das ohne Konnotat.

Die Einbeziehung nicht nur der Lösungs-, sondern auch der Problemkosten entspricht wirtschaftlicher Notwendigkeit. Nur die Kosten und der Wert der Lösung tragen dazu bei, Probleme richtig einordnen und priorisieren zu können.

Beispiele
Eine Firma will ihre Website runderneuern. Ein Pitch mit mehreren Agenturen führt zur Selektion einer Firma, die ihr eine neue Online-Präsenz für pauschal 50.000 Euro zusichert; mitsamt organisatorischer Aufwände kalkuliert das Unternehmen mit Kosten in Höhe von 55.000 Euro. Diese Summe dient der Lösung des Problems „unsere Website lockt und hält zuwenig Kunden (und wir wollen eh was neues)“. So endet die Geschichte in den meisten Fällen, die Website wird überarbeitet.

Dieselbe Firma aber, sofern sie sich Analytik widmet, mag gemessen und errechnet haben: Im Durchschnitt generiert jeder Besucher der alten Website 30 Cent Gewinn. Die neue Website deutet in Tests an, diesen auf 50 Cent steigern zu können. Bei angenommenen 100.000 Besuchern entspräche dies 20.000 Euro mehr Gewinn, je Monat – der antizipierte höhere Besucherstrom nicht einbezogen. Die Firma hat Gewissheit – eine wesentlich höhere Wahrscheinlichkeit – dass sich die Problemlösung lohnt. Würde sie jedoch in einem anderen Szenario feststellen, dass eine Novellierung der Website vierstellige Mehreinnahmen erbringt, aber sie zwei Jahre benötigt, diese wieder reinzuspielen, könnte sie das Problem und seine Lösung anders priorisieren, letztere vielleicht verwerfen.

Allein in der Internetbranche finden sich haufenweise vergleichbare Fälle, und jede Problemlösung sollte sich der Prüfung unterziehen, inwieweit die Kosten des Problems die der Lösung wirklich überwiegen. Ist eine Umstellung von XHTML auf HTML sinnvoll, wenn der Aufwand drei Manntage beträgt, der Nutzen aber nicht messbar, vielleicht nicht vorhanden ist? Sollte die Überarbeitung des Registrierungsbereichs, der unter einer Abbruchrate von 75 % leidet, wirklich um sechs Monate verschoben werden? Muss ein einziger Pixelfehler im Internet Explorer 6 mittels „Conditional Comments“ behoben werden?

Was Marketing-Fachleuten wie auch Vertrauten von Kosten-Nutzen-Analysen (DOC, 17 KB) bekannt sein könnte, darf in diesem Fall getrost noch mehr Aufmerksamkeit erhalten. Strategische oder idealistische Motivation ausgeklammert, müssen immer nicht nur die Kosten der Lösung, sondern auch des Problems betrachtet werden, um wirtschaftliche Entscheidungen fällen zu können. ™

Erstveröffentlichung 20.09.2007

Kategorien
Webdesign

CSS: Pseudo-Namensräume für komplexe Projekte

Die Arbeit an komplexen Projekten oder Projekten, die keine gute Übersicht über noch umzusetzende Seitentypen oder -elemente bieten, kann eine defensive Strategie beim Schreiben von Stylesheets erfordern. Solch eine defensive Strategie beinhaltet bestimmte Sicherheitsmaßnahmen, um bessere Wartbarkeit zu gewährleisten, und eine Taktik dafür sind CSS-Pseudo-Namensräume.

Anmerkung: Dieses Namensraumkonzept ähnelt dem in XML nur grob. Es gibt noch keine „echten“ Namensräume in CSS, daher der Name „Pseudo-Namensraum“.

Beispiele für CSS-Pseudo-Namensräume
Spezielle Icons für Links sind ein guter Anfang: Möglicherweise müssen oder wollen bestimmte Links (zum Beispiel die für Dateitypen oder Aktionen) mit unterschiedlichen Symbolen ausgestattet werden. Vorausgesetzt, dass dafür kein stabiler, verlässlicher Kontext vorliegt (wie bei ausschließlich PDF-Links in der projektspezifischen Marginalspalte), können den betroffenen Links dazu spezielle Klassen geschenkt werden:

 <a href="" class="doc"></a>
      <a href="" class="pdf"></a>
      <a href="" class="ppt"></a>

Das ist okay, auch wenn man dies beispielsweise mit zusätzlichen file-Klassen noch etwas „kultivieren“ könnte. Aber angenommen, dass man a) nicht weiß, welche anderen Seitenelemente noch folgen werden, und/oder man b) nicht alleine am entsprechenden Projekt arbeitet oder arbeiten wird, möchte man möglicherweise sichergehen, dass nicht irgendwelche Konflikte auftreten – zum Beispiel wenn irgendwann ein „Dokumentvoransicht-Modul“ mitsamt doc-Klasse eingeführt wird.

Anmerkung: Diese Problematik kann man natürlich auch mit kontextabhängiger Formatierung adressieren (a.doc vs. div.doc), was für gewöhnlich eine ratsame Sache ist. Aber dies kann wiederum in mehr Code resultieren, als notwendig ist, besonders, wenn es um komplexere Projekte geht, in denen man eher bei Dutzenden und zugleich wesentlich längeren Selektoren landet, und es löst auch nicht das Problem, dass man nicht unbedingt weiß, wer als nächster am Code arbeitet.

Nun, „Pseudo-Namensräume“ können Abhilfe schaffen, wie zum Beispiel:

      <a href="" class="nf-doc"></a>
      <a href="" class="nf-pdf"></a>
      <a href="" class="nf-ppt"></a>

Das nf-Präfix ist hier willkürlich gewählt und bedeutet „Namensraum [für das] Format“. Das „n“ stellt dabei sowohl einen Vorschlag für ein Namensraumkürzel als auch eine weitere Sicherheitsmaßnahme dar, in dem Sinne, dass es es noch unwahrscheinlicher macht, dass sich irgendjemand einen so abgekürzten Namen ausdenkt. Da das nf-Präfix auf Links beschränkt werden könnte, sollte man für diesen (und jeden anderen) Namensraum eine Konvention festlegen und dies entsprechend dokumentieren. (Wie zuvor erwähnt ist dies eine Sicherheitsmaßnahme, so dass jeder, der eine weitere doc-Klasse einführt, keine Probleme verursacht; man will aber gleichzeitig auch Inkonsistenzen bezüglich ID- und Klassen-Namen vermeiden. Ein klarer Fall für ein wenig Dokumentation.)

Neben dem reduzierten Risiko späterer Konflikte ist es nun möglich, einfacheren CSS-Code zu schreiben:

      .nf-doc {}
.nf-pdf {}
.nf-ppt {}

… und man kann mit den nächsten Elementen fortfahren, zum Beispiel mit bestimmten Maßen für Eingabeeelemente:

      .ni-s {}
.ni-m {}
.ni-l {}

… wo ni „Namensraum [für] input[-Elemente]“ bedeuten mag, und wo man ohne Bedenken sehr kurze und prinzipiell gute Klassen-Namen („small“-, „medium“- und „large“-Eingabeelemente, bei denen die Namen eher die Relation der betroffenen Elemente illustrieren sollen als präsentationsbezogen sind – das täuscht hier) einsetzen kann.

Pro und Contra Pseudo-Namensräume
Idealerweise kann hier das Konzept demonstriert werden, ohne zuviel Fokus auf Details zu provozieren (es wird nicht viel Gutes bringen, an dieser Stelle file-Klassen und ähnliches zu diskutieren). Entsprechend folgen nun die Nachteile von CSS-Pseudo-Namensräumen:

  1. Sie erfordern etwas mehr Code-Konventionen und
  2. etwas mehr Dokumentation, da ihre (empfohlene) knappe Form neue Projektmitglieder irritieren kann;
  3. tendentiell gefährden sie die CSS-Code-Konsistenz (jedoch „by design“, da eben beabsichtigt ist, unvorhersehbare Formatierungsprobleme zu verhindern).

Auf der anderen Seite haben diese Namensräume einige entscheidende Vorteile:

  1. Sie ermöglichen kompaktere und effizientere Stylesheets;
  2. sie bedeuten mehr Sicherheit bei
    • neuen Seitenmodulen,
    • Injektionen von fremdem Code und
    • neuen Teammitgliedern;
  3. sie schützen die Semantik von ID- und Klassen-Namen, während
  4. sie zudem mehr Flexibilität aufgrund von nicht notwendigerweise verwirrender Wiederverwendung von nützlichen ID- und Klassen-Namen erlauben;
  5. sie sind schlussendlich kostengünstiger, obwohl sie dennoch Qualität sichern.

Als Daumenregel: Je größer und undurchschaubarer das jeweilige Projekt ist oder tendiert, zu werden, desto mehr wird man von diesem Namensraumkonzept profitieren. Auch wenn es mit Bedacht eingesetzt werden sollte.

Dieser Artikel kann im englischsprachigen Original kommentiert werden.

Erstveröffentlichung 30.03.2007

Kategorien
Webdesign

CSS 3: Verbesserte Textbehandlung

Der Entwurf zu CSS 3 beinhaltet jede Menge Änderungen und Neuerungen. Gänzliche neue Gesichter kommen ins Spiel. Verbesserte Zeilenumbrüche und Silbentrennung, exakter Blocksatz Ausrichtungen.

Da das Texteffekte-Modul bislang nur als Entwurf vorliegt, sind die beschriebenen Eigenschaften und Werte mit Vorsicht zu genießen. Erst wenn der Entwurf Empfehlungs- und damit Spezifikationsstatus erreicht hat und Implementierungen vorliegen, kann mit dem Gezeigten richtig gearbeitet werden.

hyphenate
Die hyphenate-Eigenschaft definiert, ob der Zeilenumbruch-Algorithmus innerhalb von einzelnen Wörtern umbrechen darf, also Silbentrennung über einen Divis (Trennstrich) vorgenommen wird.

Erlaubte Werte

  • none (Standard)
  • auto

text-align-last
text-align-last gibt vor, wie die letzte Zeile in einem Textblock beziehungsweise eine vor einem erzwungenen Zeilenumbruch stehende Zeile ausgerichtet wird, wenn text-align mit dem Wert justify (Blocksatz) versehen wurde. Die Bedeutung der erlaubten Werte entspricht der der text-align-Werte (mitsamt der in CSS 3 ergänzten Werte start und end).

Erlaubte Werte

  • start (Standard)
  • end
  • left
  • right
  • center
  • justify

text-justify
Die text-justify-Eigenschaft greift wie text-align-last ebenfalls nur, wenn für die Textausrichtung bereits justify gilt. Über diese Eigenschaft lässt sich bestimmen, wie genau Blocksatz erzielt wird, was unter anderem der internationalen Vielfalt an Schreibsystemen und Schriften Rechnung trägt.

Der Wert inter-word beispielsweise setzt nur beim Platz zwischen einzelnen Wörtern an, um Blocksatz zu erzielen, inter-character hingegen bei Silbengruppen, während size dafür sorgt, dass die Schriftgröße einer Zeile so angepasst wird, dass die gesamte Zeile ausgefüllt wird. auto überlässt die Berechnung dem User-Agent, in dem Sinne, dass dieser die Balance zwischen Leistungsfähigkeit und Darstellungsqualität zu finden sucht.

Erlaubte Werte

  • auto (Standard)
  • inter-word
  • inter-ideograph
  • inter-character
  • inter-cluster
  • kashida
  • size

text-kashida-space
text-kashida-space wurde bislang noch nicht definiert. Dies ist vielleicht der Preis für zu argen Spezifikationshunger.

text-wrap
Die mit hoher Wahrscheinlichkeit ebenfalls kommende text-wrap-Eigenschaft definiert, wie Zeilenumbrüche im Textfluss vollzogen werden. Der Algorithmus orientiert sich dabei an der Interpunktion, da Zeilen in der Regel mit einem Punkt abgeschlossen werden.

So steht zur Auswahl, ob Zeilen an jeder Stelle umbrochen werden können (normal), sie nicht umbrechen und damit potentiell über den umschließenden Container hinauslaufen (none), sie zwischen Graphemen umbrechen, wobei „Bruchstellen“ vor und nach dem jeweiligen Element Priorität beigemessen wird und keine Silbentrennung stattfindet (unrestricted), oder Umbrüche innerhalb von Zeilen unterdrückt, diese außerhalb von solchen (also nach) aber gestattet werden (suppress).

Erlaubte Werte

  • normal (Standard)
  • none
  • unrestricted
  • suppress

Ein Beispiel
Die Absätzen zugeordnete text-wrap: suppress;-Deklaration resultiert bei dem Markup

 <p>Erste Zeile. Zweite Zeile. Dritte Zeile.</p>

in der folgenden Darstellung, wenn der Viewport relativ wenig Platz lässt:

 Erste Zeile. Zweite Zeile. Dritte Zeile.

Steht noch weniger Platz zur Verfügung, findet auch dann kein Umbruch innerhalb der Zeilen statt, sondern die hier zweite Zeile „rutscht“ ein Stück runter:

 Erste Zeile. Zweite Zeile. Dritte Zeile.

white-space-collapse
white-space-collapse bestimmt, ob und wie Leerraum – wie Leerzeichen, Tabulator-Zeichen oder Zeilenumbrüche – gehandhabt beziehungsweise „zusammengebrochen“ wird. Die übliche Vorgehensweise, dass vorhandener Leerraum auf ein einzelnes Leerzeichen reduziert wird, entspricht dem Standardwert collapse. preserve berücksichtigt Leerraum vollständig, während preserve-breaks mehrere aufeinanderfolgende Leer- und Tabulator-Zeichen wie bei collapse zu einem Zeichen „zusammenfallen“ lässt, aber Zeilenumbrüche im Code beachtet, und discard wiederum jeglichen Leerraum löscht. Genaueres wird durch die Leerraum-Verarbeitungsregeln spezifiziert.

Erlaubte Werte

  • collapse (Standard)
  • preserve
  • preserve-breaks
  • discard

word-break
Die word-break-Eigenschaft legt fest, was für Zeilenumbruch-Beschränkungen für ein Element gelten. Da alle Werte außer normal, dem Standardwert, mehr für chinesische, japanische und koreanische Schriften (CJK) gelten, werden diese hier nicht näher erläutert.

Erlaubte Werte

  • normal (Standard)
  • keep-all
  • loose
  • break-strict
  • break-all

word-wrap
Mit word-wrap sieht die CSS-3-Spezifikation höchstwahrscheinlich eine Eigenschaft vor, die definiert, ob innerhalb eines Wortes umgebrochen werden darf, sofern sonst nicht umgebrochen werden kann, ohne dass Text über die Grenzen seines Elements lappen würde. word-wrap greift dabei auch nur, wenn text-wrap entweder den Wert normal oder break-word hat.

Der Standardwert normal erlaubt Umbrüche nur an generell zulässlichen Umbruchpunkten, womit die Eigenschaft in dem Sinne also gar nicht wirklich zum Einsatz kommt. break-word jedoch gestattet das Umbrechen an willkürlicher Stelle – wenn keine alternativen und geeigneten Umbruchstellen vorliegen.

Erlaubte Werte

  • normal (Standard)
  • break-word

Neues von text-align, letter-spacing und word-spacing
Die text-align-Eigenschaft erhält bei derzeitigem Stand die zusätzlichen Werte start, end sowie einen beliebigen String. Für diese Optionen liegen allerdings noch keine Beispiele vor, so dass auch hier eine exakte Erklärung ausbleiben muss. Für letter-spacing und word-spacing ergibt sich, dass deren Werte ab CSS 3 voraussichtlich auch noch in Prozent angegeben werden können.

Erstveröffentlichung 24.03.2006

Kategorien
Design HTML/CSS

CSS 3: Die :target-Pseudoklasse

Die :target-Pseudoklasse ist Bestandteil des derzeitigen Entwurfs von CSS 3 und Teil einer ganzen Reihe neuer Selektoren. Werfen wir einen Blick auf zukünftige Einsatzszenarien.

Zu Beginn die Spezifikation. Ins Deutsche übersetzt erläutert der derzeitige Stand der Spezifikation :target wie folgt:

“Manche URIs beziehen sich auf eine Stelle innerhalb einer Ressource. Diese Art eines URI endet mit einem „Nummernzeichen“ (#), gefolgt von einem Ankeridentifikator (der Fragmentidentifikator).

URIs mit Fragmentidentifikatoren linken zu einem bestimmten Element innerhalb des Dokuments, das als Zielelement bekannt ist. Hier ist zum Beispiel ein URI, der in einem HTML-Dokument auf einen Anker namens section_2 zeigt:

 http://example.com/html/top.html#section_2

Ein Zielelement kann durch die :target-Pseudoklasse repräsentiert werden. Wenn der URI des Dokuments keinen Fragmentidentifikator besitzt, hat das Dokument kein Zielelement.”

Praktische Anwendungen
Die Beispiele demonstrieren unterschiedliche Einsatzmöglichkeiten der :target-Pseudoklasse. Allerdings wird :target derzeit nur von neueren Gecko- (wie Firefox 1.5) und KHTML-Browsern (wie Safari) unterstützt.

Beispiel 1: Hervorheben
Der einfachste Fall für die Verwendung von :target besteht in einer simplen Umformatierung und Hervorhebung des Zielelements. Weniger technisch ausgedrückt: Nehmen wir an, wir versehen einige Absätze eines Dokuments mit IDs zur internen Referenzierung.

 <p id="einleitung">Lorem ipsum [...]</p>

Damit können wir diese bei Aufruf entsprechend anders gestalten, zum Beispiel in roter Farbe:

 p:target { color: #F00; }

Sind unsere Absätze normalerweise schwarz, so sorgt die :target-Pseudoklasse bei Aufruf des Dokuments mit einem beliebigen Fragmentidentifikator, der einen Absatz betrifft, dafür, dass der jeweils betroffene Abschnitt rot koloriert wird. Siehe Beispielseite.

Screenshot
Der über den Link aufgerufene Absatz wird rot hervorgehoben

Beispiel 2: Ein- und Ausblenden
Interessanter ist es, bestimmte Seitenelemente erst anzuzeigen, wenn diese mit einem internen Anker aufgerufen werden. Nehmen wir hierfür ein Element mit der ID hinweis:

 <div id="hinweis">Dies ist ein Hinweis.</div>

Zuerst einmal blenden wir dieses Element aus. Dazu genügt der Einsatz einer simplen Regel:

 div#hinweis { display: none; }

Verweist jemand direkt auf das Zielelement #hinweis, können wir den div-Container über :target wieder einblenden. Bei der Gelegenheit gestalten wir ihn auch gleich etwas prominenter, indem wir ein „em“ Innenabstand injizieren:

 div#hinweis:target { display: block; padding: 1em; }

Das Ergebnis kann ebenfalls auf der Beispielseite betrachtet werden, jeweils mit und ohne Fragmentidentifikator #hinweis.

Diese Einsatzart der :target-Pseudoklasse birgt einige weitere interessante Spielarten. So könnte unser Hinweiselement auch noch einen Link auf dasselbe Dokument beinhalten – sofern nicht erneut mit dem Identifikator hinweis versehen -, um den Text wieder auszublenden. Durch Klick auf einen solchen Link greift der Selektor div#hinweis:target nicht mehr (die Beispielseite illustriert auch diesen Fall). Sieht dynamisch aus, ist aber „nur“ CSS.

Beispiel 3: Umfassende Layoutänderung
:target kann selbstverständlich noch „radikaler“ eingesetzt werden, indem man den Fokus – also das Zielelement – entsprechend groß wählt und die Formatierung umfassender ändert. Der folgende Ansatz soll dies veranschaulichen. Wir schenken dem html-Element eine ID:

 <html id="alternative"></html>

…und gestalten das dazugehörige Dokument bei Aufruf mitsamt Fragmentidentifikator #alternative um. Der Selektor selbst muss die ID alternative nicht beinhalten, wichtig ist nur, daß dem html-Element eine solche zugewiesen wurde und der Selektor natürlich :target beinhaltet.

 html:target { color: #060; font-size: 2em; }

Das Ergebnis ist ein einfacher CSS-„Stylesheet-Switcher“, der unsere Beispielseite mit großer, grüner Schrift präsentiert.

Screenshot
CSS-„Stylesheet-Switcher“

Aber Vorsicht. Das obige Beispiel geht mit IDs nicht wirklich korrekt um, da das html-Element die ID alternative eigentlich nur erfordert, wenn wir :target anwenden wollen. Obwohl es permanent als „alternativ“ gekennzeichnet ist, ist es dies von der Semantik her jedoch nur zwischenzeitlich.

Sowohl Beispiel 2 als auch 3 sind zudem erstmal als „Spielerei“ zu betrachten und vor einem praktischen und großflächigen Einsatz vor allem auf die Zugänglichkeit zu prüfen. Elemente, die wie dargestellt über display: none; aus- und einen die :target-Pseudoklasse beinhaltenden Selektor wieder eingeblendet werden, sind in Bildschirmlesesoftware genauso vorhanden wie jetzt noch im Internet Explorer – gar nicht. Wenn dies nicht verantwortet werden kann, bleibt nur das Warten auf den Reader-Medientyp und den Internet Explorer 7. Sofern er :target unterstützen wird.

Links zum Thema:

Erstveröffentlichung 19.01.2006

Kategorien
Webdesign

Augenerkrankungen und barrierefreies Webdesign

Barrierefreiheit im Internet dreht sich beileibe nicht nur darum, Menschen mit Augenkrankheiten, wie schwer diese auch sein mögen, Zugang zu Informationen zu ermöglichen. Dennoch dreht sich dieser Artikel ausschließlich um ausgewählte Einschränkungen der visuellen Wahrnehmung.

Blindheit ist nicht das Einzige, das bei der Entwicklung zugänglicher Angebote zu adressieren ist. Damit soll er der Tendenz vorbeugen und auch dem Vorwurf entgegentreten, dass manche Webdesigner und -entwickler eben nur Blindheit mit „Barrierefreiheit“ verbinden.

Anmerkung: Der Autor ist kein Mediziner. Aus diesem Grund ist dieser Artikel eher knapp gehalten und verweist mit Vorliebe auf weiterführende Dokumente. Etwaige Fehler werden umgehend korrigiert. Ausschließlich medizinische Fragen richten Sie bitte an einen Arzt Ihres Vertrauens.

Skotopische Sensitivität

Skotopische Empfindlichkeit oder auch Meares-Irlen-Syndrom ist ein 1983 von Helen Irlen diagnostiziertes Problem mit Lichtempfindlichkeit, das vor allem bei schwarzem Text auf weißem Grund auftritt. Die prinzipiell sowohl im Zusammenhang mit Papier als auch am Monitor zu beobachtenden Symptome umfassen:

  • Die Empfindung, dass die Seite zu hell oder grell ist;
  • Buchstaben scheinen sich zu bewegen oder zu verschwimmen;
  • Konturen oder „Flüsse“ erscheinen im Text („Rivers of White Space„).

Die Symptome können dabei nicht nur das Lesen erschweren, sondern auch Kopfschmerzen und generelle Unlust am Lesen verursachen.

Verbreitung:
~45 %.
Designmaßnahmen:
„Blassere“ Hintergrundfarben, schwächerer Kontrast.

Kurz-, Weit- und Alterssichtigkeit

Weder Kurzsichtigkeit (Myopie) noch Weitsichtigkeit (Hyperopie) noch Alterssichtigkeit (Presbyopie) sind Krankheiten im eigentlichen Sinne, aber weltweit stark verbreitet (DOC, 43 KB). All diese drei Beeinträchtigungen können in der Regel zudem durch Brillen oder Kontaktlinsen ausgeglichen werden. Aber: Eine Fehlsichtigkeit muss natürlich erstmal bemerkt werden. Und nochmal zum Mitsingen für alle, deren Webseitenschriftgröße maximal zehn Pixel betragen darf: Nicht jeder Mensch verfügt über Adleraugen.

Verbreitung:
15-25 % kurzsichtig (USA), ~35 % weitsichtig (Spanien), ~100 % altersweitsichtig ab 40/45 Jahren.
Designmaßnahmen:
Nicht „zu kleine“ Standardschriftgröße, auch im Internet Explorer (bis Version 6) skalierbar.

Wichtig ist, was Jan Eric Hellbusch treffend anmerkt:

Wer sehr starken Vergrößerungsbedarf hat, wird in der Regel ein Vergrößerungssystem oder eine Bildschirmlupe einsetzen – beides Programme, die einen Ausschnitt des Bildschirms vergrößern. Während Bildschirmlupen im Prinzip wie eine Lupe funktionieren und Inhalte in einem beweglichen Fenster anzeigen, bieten Vergrößerungssysteme komplexe Funktionen, die von der Anpassung von Layout und Veränderung von Farben bis hin zu unterstützender Sprachausgabe reichen.

Nicht jeder mit einer Sehschwäche oder Sehbehinderung benötigt aber starke Vergrößerung. Oft reichen einige kleinere Änderungen am System, um den Bildschirm lesen zu können.

Farbfehlsichtigkeit

Wikipedia sagt:

Die Begriffe Rot-Grün-Sehschwäche und Rot-Grün-Blindheit sind die wissenschaftlichen Fachtermini für über 99 % der Farbfehlsichtigkeiten, die umgangssprachlich als Farbenblindheit bezeichnet werden. Die Betroffenen können hierbei die Farben Rot und Grün schlechter als Normalsichtige unterscheiden. Hervorgerufen wird diese Behinderung durch Veränderungen der Aminosäuresequenz in den Sehpigment-Proteinen (Opsin) der entsprechenden Zapfen der Netzhaut, die aus der Veränderung der Gensequenz des entsprechenden Opsins resultiert.

Bekannte Fehlsichtigkeiten:

  • Protanopie: Rotblindheit;
  • Deuteranopie: Grünblindheit;
  • Tritanopie: Blaublindheit;
  • Achromatopsie: Unfarbigkeit (totale Farbblindheit).

[sic]

Farbfehlsichtigkeit ist in der Regel leicht zu berücksichtigen, indem Informationen nicht nur über Farbe, sondern auch Form oder Beschriftungen vermittelt werden. Zusätzlich stellt es selten ein Problem dar, problematische Farbkombinationen insgesamt zu vermeiden. Webdesigner können sich über diverse Werkzeuge, wie zum Beispiel Vischeck, davon überzeugen, dass Informationsangebote auch für Farbfehlsichtige hinreichend dargestellt werden.

Online finden sich vor allem zu Farbfehlsichtigkeiten (oder „Farbenblindheit“) einige wirklich gut bis ausgezeichnet aufbereitete Hintergrundinformationen, unter anderem bei Joe Clark, der englischen Wikipedia, der Florida State University und auch Terrace L. Waggoner.

Testbild für Rot-Grün-SehschwächeAbbildung: Protanopie-Testbild, das Farbfehlsichtigen die Zahl „17“ zeigt, Normalsichtigen „47“ (Lizenzbestimmungen).
Verbreitung:
4-5 %.
Designmaßnahmen:
Entsprechende Farbkombinationen meiden und/oder Farbunterscheidbarkeit gewährleisten.

Retinitis pigmentosa

Die Wahrnehmung von Farben kann im Hinblick auf Kontraste generell eingeschränkt sein. Ausreichender Kontrast sollte zur Informationsvermittlung immer gewährleistet werden; offensichtlich (aber nicht begrenzt auf) ist dies bei Erkrankungen wie Retinitis pigmentosa, bei der verschlechterte Kontrastwahrnehmung eines der Symptome darstellt:

Mit Retinitis pigmentosa bezeichnet man eine Gruppe von erblichen Augenerkrankungen, die eine Zerstörung der Netzhaut zur Folge haben. Diese zur Zeit noch unheilbare Krankheit ist heute noch eine der häufigsten Ursachen des Sehverlustes. Es handelt sich um eine Erbkrankheit, die an die Nachkommen weitergegeben werden kann.

Ein weiteres, wesentliches Symptom von Retinitis pigmentosa ist „Tunnelblick“, so dass am Bildschirm nur ein kleiner Ausschnitt der dargestellten Informationen wahrgenommen wird. Dies erfordert Orientierungshilfen in Form von beispielsweise Umrahmungen oder deutlich unterschiedliche Hintergrundfarben für einzelne Bereiche eines Dokuments.

Verbreitung:
0,025-0,3333 %.
Designmaßnahmen:
Stärkerer Kontrast, deutlichere Abgrenzung von Seitenbereichen.

Fotosensitive Epilepsie

Fotosensitive Epilepsie ist eine besondere Form von Epilepsie und wird durch visuelle, flimmernde Reize verursacht. Untersuchungen zufolge kann „Flackern“ in einer Frequenz von 16 und 25 Hz epileptische Erscheinungen hervorrufen, andere Quellen – via Gez Lemon – sprechen gar von einem Spektrum von 3 bis 60 Hz.

Verbreitung:
~0,0095 %(~5 % der Epilepsiebetroffenen).
Designmaßnahmen:
Vermeiden oder zumindest Verkleinern von flimmernden Flächen.

Farbenblindheit

„Echte“ Farbenblindheit (Achromatopsie) ist ein sehr seltener Gendefekt der Netzhaut und äußert sich darin, dass Betroffene gar keine Farben wahrnehmen können. (Nahezu) vollständige Farbenblindheit, Lichtscheu (Photophobie), Augenzittern (Nystagmus) und reduzierte Sehschärfe sind typische Symptome von Farbenblindheit.

Anmerkung: „Farbenblindheit“ wird im Deutschen fälschlicherweise und vermutlich aufgrund des im Englischen leicht abweichenden Wortgebrauchs oft mit Farbfehlsichtigkeit verwechselt. (Der Autor bildet da kaum eine Ausnahme.)

Verbreitung:
< 0,0001 %.
Designmaßnahmen:
Farbunterscheidbarkeit gewährleisten, stärkerer Kontrast.

Résumé

Auch wenn die vorgestellte Auswahl an Limitationen nicht allumfassend ist – der Einfachheit halber fehlen insbesondere Anmerkungen zu Makuladegeneration und Usher-Syndrom -, sollte deutlich werden, dass eingeschränkte optische Wahrnehmung, ob nun durch eine Sehbeeinträchtigung oder Sehbehinderung bedingt, wirklich nicht nur Blindheit bedeutet. Ganz besonders sollte sie dabei aufzeigen, dass:

  • wesentlich mehr Menschen keine „perfekten“ visuellen Fähigkeiten besitzen, als man denken mag;
  • viele Wahrnehmungsprobleme relativ leicht zu adressieren sind, trotz scheinbarer Konflikte (wie zum Beispiel die Kontrastempfehlungen bei skotopischer Sensitivität und Retinitis pigmentosa).

Vielen Dank für Hinweise und Anregungen an den selbst stark sehbehinderten Jan Eric Hellbusch, der viele Jahre die AG Sehbehinderte geleitet hat. ™

Erstveröffentlichung 21.11.2005

Kategorien
Design HTML/CSS

Präsentationen mit Dave Raggetts HTML Slidy

HTML Slidy ist eine wie Eric Meyers Simple Standards-Based Slide Show System (S5) auf XHTML, CSS und JavaScript basierende Vorlage für Bildschirm- und Projektor-Präsentationen. Die Ähnlichkeit zu S5 ist frappierend, und folgerichtig kann man „HTML Slidy“ wie auch schon S5 als Webstandards-Antwort auf die populären Powerpoint-Folien von Microsoft verstehen.

Funktionsweise
Auch „HTML Slidy“ besteht aus einem einzigen semantischen HTML-Dokument, das über CSS formatiert wird und deren Steuerfunktionen über JavaScript realisiert werden. Das reguläre sowie ein Druckstylesheet adressieren durch ihre Regeln neben der normalen Anzeige sowohl Vollbild-Modus (via projection-Medientyp) als auch Druck (via print-Medientyp).

SCreenshot
Präsentation im Browser: Ein Klick an beliebiger Stelle zeigt die nächste Folie

Das äußerst umfangreiche Skript übernimmt neben der Steuerung (Blättern über Mausklick oder Tastatur) auch die Darstellung der im Dokument definierten Container bzw. Folien. Während „HTML Slidy“ keine besonderen Links zum Blättern oder dem Deaktivieren der Formatierung (zur Anzeige des vollen Dokuments) bereitstellt, wartet es hingegen damit auf, daß auf einzelne Folien über interne Anker verlinkt werden kann – eine Schwäche von S5.

Vor- und Nachteile
Auf der ansonsten so weißen Weste kann zumindest ein Fleck ausgemacht werden, auch wenn dieser in der Regel von den vielen Vorzügen aufgewogen wird:

Vorteile

  • Geringe Ladezeit, da kleine, gut komprimierbare Datei(en);
  • durch semantisches XHTML barrierefrei;
  • standardbasiert und system- bzw. browserunabhängig;
  • leicht individualisierbar durch eigene CSS-Motive.

Nachteile

  • Suchen ist nur auf die aktuelle Folie beschränkt.

Download
Legt man mehr Wert auf das Referenzieren einzelner Folien als auf das Durchsuchen der gesamten Präsentation, wie es S5 erlaubt, ist „HTML Slidy“ eine durchaus empfehlenswerte, schlanke und zugängliche Präsentationsform:

Erstveröffentlichung 07.10.2005

Kategorien
Design HTML/CSS

Präsentationen mit Eric Meyers S5

S5, das Simple Standards-Based Slide Show System, ist eine auf XHTML, CSS und JavaScript basierende Grundlage für Bildschirm- und Projektor-Präsentationen.

Sie wurde vom bekannten CSS-Experten Eric Meyer (inspiriert durch Tantek Çelik, Mitglied der W3C-CSS-Arbeitsgruppe und Schöpfer unter anderem des Boxmodell-Hacks) entworfen und 2004 in einer ersten Version veröffentlicht. Unter S5 kann man die Webstandards-Antwort auf die populären Powerpoint-Folien verstehen. Ihre Vorzüge bestehen darin, sowohl wesentlich schneller zu laden als auch zugänglicher als der „große Bruder“ zu sein.

SCreenshot
Ausschnitt aus der Musterslideshow von Eric Meyer

Funktionsweise
S5 besteht aus einem einzigen semantischen HTML-Dokument (siehe Musterslideshow von Eric Meyer oder ein Anwendungsbeispiel vom 2. Münchner Usabilitytag), das über CSS formatiert wird und deren Steuerfunktionen über JavaScript realisiert werden.

Die „Folien“ funktionieren auch im Vollbild-Modus (projection-Medientyp) und sehen ausgedruckt angemessen aus; das Skript übernimmt neben der Steuerung (Blättern über Mausklick oder Vor- und Zurückspringen) auch die Visualisierung einzelner im Dokument definierter Container, der Folien (oder „Slides“). Diese Funktionalität bedingt, dass sowohl Stylesheet als auch Skript relativ umfangreich sind – auch wenn dies im Vergleich zu Powerpoint nicht der Rede wert ist.

Vorteile

  • Geringe Ladezeit, da kleine, gut komprimierbare Datei(en);
  • durch semantisches XHTML barrierefrei;
  • standardbasiert und system- bzw. browserunabhängig;
  • leicht individualisierbar durch eigene CSS-Motive.

Nachteile

  • Benötigt einen modernen Browser

Download
Die aufgeführten Pluspunkte des S5-Slideshowsystems empfehlen es eindeutig als alternative und vor allem für das Internet besonders gut geeignete, da sofort zugängliche Präsentationsform. Auf der Webseite von Eric Meyer befinden sich alle für S5 benötigten Dateien inklusive der zum Aufsetzen benötigten Informationen:

Eine detaillierte Dokumentation von S5 befindet sich in der S5-Referenz sowie der S5-FAQ. ™

Erstveröffentlichung 08.08.2005

Kategorien
Design HTML/CSS

Eleganter Code durch kontextuelle Selektoren

Kontextuelle Selektoren ermöglichen es, im HTML-Quelltext einer Seite auf das Setzen von id- oder class-Attributen zu verzichten und stattdessen über die Struktur des Dokuments auf bestimmte Elemente zuzugreifen und diese zu formatieren. Dadurch wird der Code einfacher, Arbeit gespart und insgesamt intelligenter vorgegangen.

In der Praxis ist es oft zu beobachten: Jeder Bereich und jedes Element, das ein bestimmtes Aussehen erhalten soll, wird auch gerne sofort mit einer Klasse versehen, heißt, man setzt im betroffenen Markup rasch mal ein class-Attribut, welches als CSS-Selektor herhalten soll, und nimmt dann die Justierung der Darstellung vor. Manchen Autoren wird dieses Problem bereits bekannt vorkommen, wenn sie daran denken, wie oft allein schon ein einfacher Elementselektor (à la h1) reicht, ohne dass man gleich einen eindeutigen Bezeichner oder eine Klasse wählen muss — noch viel häufiger jedoch wird es verpasst, auch aus der Seitenstruktur und damit dem Kontext Nutzen zu ziehen.

Hier ein einfaches Beispiel, ohne großartiges Suchen auf der Webseite von Yahoo entdeckt:

 <div class=ct> <div class=u></div> <div class=u></div> <div class=u></div> <div class=u></div> </div>

Der Inhalt der „u“-Container wurde der Einfachheit halber ausgeblendet, und auf einen Kommentar bzgl. der nicht in Anführungszeichen gesetzten Attributswerte wird an dieser Stelle verzichtet. Es stellt sich vielmehr die Frage, ob die Klasse „u“ wirklich notwendig ist — einen semantischen Sinn hat sie offensichtlich nicht. Auch IDs und Klassennamen verfügen idealerweise über eine Bedeutung, wie es z.B. die Klasse „error“ wunderbar verdeutlicht.

So einfach kann man die dortigen Klassen nicht entfernen, was allerdings durch die prinzipiell notwendigen zusätzlichen Anpassungen egalisiert wird, denn in erster Linie würde man einem solchen Fall Listen und keine bedeutungsleeren div-Elemente gebrauchen. Wie sich dieser Code grundsätzlich vereinfachen lässt, liegt nahe. Hier nun mit einem in Anführungszeichen gesetzten Attributswert „ct“ sowie eingerückten Kindelementen.

 <div class="ct"> <div></div> <div></div> <div></div> <div></div> </div>

Im Stylesheet selbst benutzt man jetzt anstelle des Selektors div.u oder .u einfach .ct div — oder, wenn der Außencontainer nur für analoge Fälle gebraucht wird, lediglich div div, wobei man sich der Klasse „ct“ dann idealerweise gleich ganz entledigt, class=“ct“ also entfernt. Der Code ist eindeutig einfacher geworden, vergleicht man die beiden Codeausschnitte, und die Realisierung ist flexibel — in einem Container „example“ könnte man wiederum div-Elemente verwenden, denen man dann via .example div andere Eigenschaften zuweist.

Grundsätzlich bietet sich der Gebrauch von kontextuellen bzw. „Nachkommenselektoren“ (von kontextuellen Selektoren ist offiziell nur in CSS 1 die Rede, ab CSS 2 heissen diese „descendant selectors) immer dann an, wenn Elemente oder bestimmte Instanzen eines Elements (denn natürlich können z.B. auch Attributselektoren in einen Kontext gebracht werden) in mehr als einem strukturellen Zusammenhang verwendet werden und dabei eine unterschiedliche Formatierung erhalten sollen — denn sonst würde ein alleinstehender Selektor genügen.

Das Vorgehen kann zudem verfeinert werden, indem man absichtlich und gezielt bedeutungsleeres (also nicht semantisches) Markup wie div- oder span-Elemente gebraucht, um in seinen Stylesheets nur Element- und kontextuelle Selektoren zu verwenden, was das HTML noch schlanker werden lässt. Der folgende Quelltext zum Beispiel erlaubt es, zwei ganz unterschiedliche Darstellungen einer Liste auf einer Webseite zu verwenden, ohne dass irgendein zusätzliches Attribut gebraucht werden muss:

 <ul> <li>Punkt 1</li> <li>Punkt 2</li> <li>Punkt 3</li> </ul> <div> <ul> <li>Punkt A</li> <li>Punkt B</li> <li>Punkt C</li> </ul> </div>

Im darauf angewendeten Stylesheet reichen dann selbstredend die Selektoren ul und div ul, um dem Autor alle Freiheit zu schenken.

Mit ein wenig Gespür können HTML-Code und Stylesheets also leicht vereinfacht werden, und es kann allein über den Kontext gezaubert werden. Doch manchmal sind auch IDs und Klassen sehr wohl nützlich, ab und an gar unverzichtbar.

Kategorien
Webdesign

Image-Replacement-Techniken

Image Replacement beschreibt das Ersetzen von HTML-Elementen durch Bilder, wobei der eigentliche Textinhalt selbst nicht mehr angezeigt wird. Bilder bieten mehr Freiheiten, was unter anderem die Typographie anbelangt, und solche Ersetzungsverfahren sollen trotz der Darstellung von Bildern die Struktur und Semantik eines Dokuments erhalten.

Populäres Ziel solcher Techniken sind Überschriften; bekannte Techniken sind das „Fahrner Image Replacement“ (FIR; FIR-Beispiel) oder „Scalable Inman Flash Replacement“ (sIFR), andere hören auf Namen wie „Malarkey Image Replacement“ (MIR) oder „Definitive Solution to Image Replacement“ (DIR).

Vorgestellt wird eine Vielzahl anwendbarer und verbreiteter Methoden. Auf Varianten, die ausschließlich auf JavaScript beruhen, die zu trivial sind (Img-Element anstelle des Textes) oder keinen signifikanten Unterschied oder Mehrwert gegenüber bereits aufgezählten Methoden bieten (wie beispielsweise das „Single Pixel Replacement„), wird nicht eingegangen. Empfehlenswerte Lösungen sind die Phark-Methode sowie SIIR.

Fahrner Image Replacement

FIR ist vermutlich der Urahn aller „Image Replacement“-Methoden und mindestens seit März 2003 bekannt (Stopdesign). Die Methode arbeitet mit separaten span-Elementen, die entweder über die display- oder die visibility-Eigenschaft ausgeblendet werden. FIR ist nicht nur aufgrund des zusätzlichen Markups problematisch, sondern vor allem, weil die meisten Screenreader den ausgeblendeten Text nicht (mehr) vorlesen können – siehe Joe Clarks Artikel für „A List Apart“ -, und gar nichts angezeigt wird, wenn die Anzeige von Bildern deaktiviert, CSS aber zugelassen ist.

HTML
 <h1><span>Muster</span></h1>
CSS
 h1 { background: url(muster.gif); height: 25px; width: 250px; } h1 span { visibility: hidden; }

Dwyer-Methode

Die Dwyer-Methode wurde von Leon Dwyer entworfen und entspricht einem FIR-Derivat, verwendet also ebenfalls zusätzliches Markup in Form von span-Elementen – was man generell als Manko ansehen kann, auch wenn span-Elemente über keine Semantik verfügen. Von der Schwachstelle „Bilder aus, CSS an“ abgesehen arbeitet diese Methode fehlerfrei, es gibt keine bekannten Probleme mit bestimmten Browsern.

HTML
 <h1><span>Muster</span></h1>
CSS
 h1 { background: url(muster.gif); height: 25px; width: 250px; } h1 span { display: block; height: 0; overflow: hidden; width: 0; }

Gilder-/Levin-Methode

Die Gilder-/Levin-Methode verdankt ihren Namen ebenfalls ihren „Entdeckern“, in diesem Fall Tom Gilder und Levin Alexander, die diese im August 2003 publik machten (siehe bei Levin Alexander). Das von beiden beschriebene Vorgehen setzt wie die Dwyer-Methode auf FIR auf, gebraucht also Extra-Markup. Zugänglichkeitsprobleme sind soweit nicht bekannt (wenn auch laut Dave Shea noch nicht verifiziert), und das Verfahren erlaubt sogar die Darstellung des Textes, wenn die Anzeige von Bildern deaktiviert ist. Neben dem benötigten span-Element ist es ein Problem, transparente Bilder zu verwenden, da Text durch diese hindurchscheinen würde.

HTML
 <h1><span></span>Muster</h1>
CSS
 h1 { height: 25px; position: relative; width: 250px; } h1 span { background: url(muster.gif) no-repeat; height: 100%; position: absolute; width: 100%; }

Radu-Methode

Radu Darvas war neben einer Erweiterung von FIR, die das „Single Pixel Replacement“ hervorbrachte, noch an einem anderen IR-Verfahren beteiligt, das nun als „Radu-Methode“ bekannt ist. Diese funktioniert im Gegensatz zu FIR ohne Sonder-Markup und auch mit allen Screenreadern, da die Methode über einen großen negativen Außenabstand (via margin-Eigenschaft) arbeitet; im Gegensatz zur Phark-Methode funktioniert sie außerdem im Internet Explorer 5.0. Das Szenario „Bilder aus, CSS an“ ist auch hier ein Problem.

HTML
 <h1>Muster</h1>
CSS
 h1 { background: url(muster.gif); height: 25px; margin-left: -1000em; width: 1250px; }

Phark-Methode

Die Phark-Methode von Mike Rundle ist ähnlich einfach wie die Radu-Methode, arbeitet aber nicht mit einem großen negativen Außenabstand, sondern mit einem großen „Outdent“ über die text-indent-Eigenschaft. Rundles Vorgehen ist vermutlich der weitaus beliebteste Weg, um Elemente durch Bilder zu ersetzen. Zwei Probleme tauchen jedoch beim Verwenden der Phark-Methode auf: Zum einen funktioniert sie nicht mit dem Internet Explorer 5.0, zum anderen besteht auch hier die „Bilder aus, CSS an“-Problematik.

HTML
 <h1>Muster</h1>
CSS
 h1 { background: url(muster.gif); height: 25px; text-indent: -500em; width: 250px; }

Leahy- bzw. Langridge-Methode

Relativ zeitgleich sollen sowohl Seamus Leahy als auch Stuart Langridge (letztere dann als „Langridge Image Replacement“ bekannt, LIR) eine weitere Ersetzungstechnik erfunden haben, die auf dem Hinzufügen der Deklaration overflow: hidden; aufsetzt und damit auch mit assistiven Technologien wie Screenreadern funktioniert. Schwachpunkte dieser Methode sind das Szenario „Bilder aus, CSS an“ sowie die erforderliche Anwendung eines Boxmodell-Hacks.

HTML
 <h1>Muster</h1>
CSS
 h1 { background: url(muster.gif); height: 0 !important; height /**/:25px; overflow: hidden; padding-top: 25px; width: 250px; }

Anmerkung: Die Verwendung von em ist den im Original gebrauchten Pixeln als Einheit vorzuziehen, da der Abstand auch bei Skalierung der Schrift auf jeden Fall groß genug bleibt.

Lindsay-Methode

Von Russ Weakley kommt die Lindsay-Methode, die darauf basiert, den Text nicht wirklich auszublenden, sondern ihn stark zu verkleinern und dabei in der Farbe des Hintergrunds zu kolorieren. Das bekannte Problem „Bilder aus, CSS an“ wird auch hier nicht gelöst, zudem muss die Übereinstimmung der Text- mit der Hintergrundfarbe gewährleistet sein.

HTML
 <h1>Muster</h1>
CSS
 h1 { background: url(muster.gif); color: #FFF; /* Farbe des Hintergrunds */ font-size: 1px; height: 25px; width: 250px; }

Malarkey Image Replacement

Im März 2005 veröffentlichte Andy Clarke das Malarkey Image Replacement. MIR ist ähnlich simpel wie die Phark-Methode und verwendet prinzipiell nur eine einzige Deklaration, um den zu ersetzenden Text aus dem Weg zu schaffen, und zwar letter-spacing: -1000em;. Soll der Internet Explorer auf dem Macintosh bedient werden, ist eine zusätzliche CSS-Regel zur Verwendung des „Commented Backslash Hack“ erforderlich. Aus Sicht der Barrierefreiheit stellt „Bilder aus, CSS an“ die übliche Achillesferse dar.

HTML
 <h1>Muster</h1>
CSS
 h1 { background: url(muster.gif); height: 25px; letter-spacing: -1000em; width: 250px; }

Definitive Solution to Image Replacement

DIR wurde fast unmittelbar nach MIR von Anatoly Papirovsky präsentiert. Es geht die Problematik von zwei Seiten an, vereinfacht dargestellt: Bei Gecko- oder KHTML-Browsern wird das ersetzende Bild über die content-Eigenschaft eingebunden und der entsprechende Block über einen negativen Außenabstand über den Text geschoben; der Internet Explorer, der content (noch) nicht versteht, wird mit zwei anderen Regeln bedient – eine verwendet einen JavaScript-Ausdruck, um ein span-Element in den Code einzufügen, die andere definiert die Maße sowie das Hintergrundbild dieses eingefügten span-Elements.

Diese „definitive Lösung“ ist aus Zugänglichkeitssicht interessant, da sie eigentlich alle regulären Hindernisse – auch „Bilder aus, CSS an“ – umschifft, die Verwendung von JavaScript-Ausdrücken im Stylesheet aber stellt ein KO-Kriterium da, denn dies entspricht nicht der CSS-Spezifikation. Dies ist der Grund, warum die Methode hier technisch nicht detaillierter vorgestellt und zudem von der Anwendung von DIR prinzipiell abgeraten wird.

Scalable Inline Image Replacement

Ryan Petrellos SIIR ist ebenfalls eine der neueren Bildersatztechniken (Dezember 2004), und sie basiert auf JavaScript – über dieses wird ein PHP-Skript angestoßen, was aus im JavaScript angegebenen Parametern Bilder für die Texte der zu ersetzenden Elemente generiert. Neben den spezifizierbaren Parametern kann eine Schrift vorgegeben werden, die in den Bildern verwendet wird; Performanzproblemen beugt SIIR durch einen Cache für bereits generierte Bilder vor.

Das „Scalable Inline Image Replacement“ funktioniert bei allen User-Agents, in denen JavaScript verfügbar und aktiviert ist, es treten andernfalls aber keine Probleme auf. Das Szenario „Bilder aus, CSS an“ ist ebenfalls nicht kritisch – deaktiviert der Nutzer die Anzeige von Bildern, wird bei gleichzeitig zugelassenem JavaScript der ALT-Text angezeigt. Die Skalierung des Textes stellt das einzige Haar in der Suppe dar, denn sie ist auf regulärem Wege über den Browser nicht möglich – wird aber durch zwei spezielle JavaScript-Funktionen adressiert.

  • SIIR-Download (270 KB) funtioniert leider nicht mehr

Scalable Inman Flash Replacement

sIFR wurde im August 2004 erstmals von Mike Davidson vorgestellt und ist somit ebenfalls eine der jüngeren IR-Techniken. Im Allgemeinen basiert sie auf der Idee, Elemente bzw. deren Texte mit allen typographischen Vorteilen sowie einem generischen „Fallback“ versehen dynamisch durch Flash-Filme zu ersetzen, was Davidson eigenen Angaben zufolge auch bereits 2001 bei ESPN umgesetzt hat; im Speziellen aber setzt sie auf dem im April 2004 präsentierten IFR von Shaun Inman auf. Da sIFR invalides Markup in Form nicht spezifizierter Elemente (embed) und Attribute (sifr) generiert, wird es an dieser Stelle jedoch nicht weiter erörtert und von seiner Verwendung von vornherein abgeraten.

Zum Weiterlesen ist der entsprechende sIFR-Artikel bei Dr. Web sowie Gerrit van Aakens Artikel „sIFR – Revolution der Webtypografie?“ zu empfehlen; sehr Interessierte finden auf der Seite zum aktuellen Release „sIFR 2.0, RC4“ weitere Informationen sowie die benötigten Dateien zum Download.

Résumé

Die Bewertung der vorgestellten Techniken muss Augenmerk auf die Barrierefreiheit legen, und hier gilt es besonders auf zwei Punkte einzugehen: Ein Punkt ist die bei jeder Methode angesprochene Handhabung von „Bilder aus, CSS an“ – dies ist ein Szenario, worauf zu achten ist, was aber tatsächlich eher selten vorkommt. Der andere Punkt wurde nur einmal kurz angerissen, und das ist die Textskalierung – in der Regel lassen sich die ersetzten Texte nicht skalieren (Ausnahmen sind technik- – wie bei SIIR – oder browserabhängig – wie bei Opera). Die schlecht mögliche Textskalierung kann und sollte zum Beispiel durch eine möglichst große Schriftgröße auf den Bildern adressiert werden.

Von einer Aufwertung, die Dave Shea als „Shea Enhancement“ proklamiert (aufsetzend auf der Gilder-/Levin-Methode), können zudem alle vorgestellten Techniken profitieren, indem nämlich dem zu ersetzenden Element (in den obigen Beispielen das h1-Element) ein title-Attribut geschenkt wird, das den darzustellenden Text beinhaltet.

Wenn es darum geht, eine Empfehlung auszusprechen, heben sich zwei Techniken deutlich ab, nämlich die Phark-Methode, bedingt durch ihre Einfachheit, und SIIR, bedingt durch ihr Potenzial sowie dadurch, dass sie die zugänglichste Lösung darstellt. Standards zu brechen, wie es das durchaus interessante sIFR und das nicht „definitive“ DIR tun, disqualifiziert bei der Beurteilung. Andere Techniken, allen voran das „Fahrner Image Replacement„, stellen mit ihren Defiziten hinsichtlich der Barrierefreiheit sowie dem Bedarf nach zusätzlichen Markup keine Alternativen dar.

Kategorien
Webdesign

XHTML und der richtige MIME-Typ

Wer XHTML als Basis für seine Webseiten verwendet, weiß oft nicht, daß der MIME-Typ text/html hier falsch ist. XHTML sollte als application/xhtml+xml ausgegeben werden, und über PHP oder Apaches .htaccess ist dies rasch konfiguriert – wobei speziell dem Internet Explorer eine Sonderrolle zukommt.

Das W3C definiert, dass HTML-Dokumente mit den MIME– (Multi-Purpose Internet Mail Extension) oder Medien-Typ text/html, XHTML-Seiten jedoch als application/xhtml+xml ausgeliefert werden müssen, auch wenn prinzipiell auch die MIME-Typen application/xml sowie text/xml zulässig sind. Als Ausnahme gilt, dass zumindest bei Gebrauch von transitionellem XHTML, also dem Doctype XHTML 1.0 Transitional, weiterhin text/html erlaubt, wenn auch ebenfalls nicht empfohlen ist.

Den MIME-Typ application/xhtml+xml zu verwenden hat allerdings auch nicht nur den Vorteil, dass man die Standards wirklich beherzigt, sondern man ist auch grundsätzlich Nutznießer zweier großer Vorteile von XHTML, nämlich Fehlerbehandlung und echte Interoperabilität mit anderen XML-Derivaten.

Die Umsetzung ist prinzipiell schnell erfolgt: In PHP lässt sich der anzupassende HTTP-Header Content-Type durch

 <?php header("Content-type: application/xhtml+xml"); ?>

ändern, und auch über die Konfiguration des Apache-Webservers (in diesem Artikel wird die Datei .htaccess als Beispiel verwendet, da viele Betroffene bzw. Interessierte nicht unbedingt Zugriff auf die httpd.conf haben) würde

 AddType application/xhtml+xml .html

bereits genügen (für Dateien mit der Erweiterung „.html“) – wenn es nicht User-Agents gäbe, die hiermit Probleme haben, weil sie den MIME-Typ application/xhtml+xml nicht unterstützen. Eines der prominentesten Beispiele hierfür ist der Internet Explorer, der den Download-Dialog öffnet, wenn ihm eine application/xhtml+xml-Ressource begegnet. Glücklicherweise lässt sich das Dilemma aber mit ein paar Handgriffen lösen, indem man zum Beispiel auf die Möglichkeiten von PHP zurückgreift:

 <?php if ( stristr($_SERVER["HTTP_ACCEPT"],"application/xhtml+xml")  ) { header("Content-type: application/xhtml+xml"); } else { header("Content-type: text/html"); } ?>

Alternativ, und zudem eleganter, macht man Gebrauch von der .htaccess und den Fähigkeiten von Apaches mächtigem mod_rewrite-Modul:

 RewriteEngine on RewriteBase / RewriteCond %{HTTP_ACCEPT} application/xhtml\+xml RewriteCond %{HTTP_ACCEPT} !application/xhtml\+xml\s*;\s*q=0 RewriteCond %{REQUEST_URI} \.html$ RewriteCond %{THE_REQUEST} HTTP/1\.1 RewriteRule .* - [T=application/xhtml+xml]

Beide nun angepasste Varianten sorgen dafür, dass nur den User-Agents der „richtige“ MIME-Typ serviert wird, die vorgeben, ihn auch zu akzeptieren: So erhalten beispielsweise auf Gecko basierende Browser wie Mozilla oder Firefox das Dokument als application/xhtml+xml (nachvollziehbar über den Kontextmenüeintrag „Seiteninformationen anzeigen“ bzw. „View Page Info“), während dem Internet Explorer das Dokument in ihm zuträglicher Manier als text/html geliefert wird.

Auf die genaue Erläuterung jeder Zeile muß an dieser Stelle im übrigen verzichtet werden, weil hierzu weiter ausgeholt werden müsste; ebenso sind selbstverständlich diverse Modifikationen möglich, wie etwa im Falle der .htaccess bei der Verwendung von Verzeichnis-Indices (Übersicht über alle Dateien in einem Ordner) REQUEST_URI durch REQUEST_FILENAME zu ersetzen, da diese sonst weiterhin nur als text/html ausgeliefert werden würden.

Am Schluss ist noch eine Warnung auszusprechen, denn so trivial diese wichtige, standardkonforme Anpassung auch ist – sie kann anfangs zu Problemen führen: CSS-Selektoren sind bei Verwendung mit XML-Dokumenten case-sensitiv, die populäre Auskommentierung der Inhalte von <script />- und <style />-Elementen muss, wenn diese beibehalten werden soll, modifiziert werden, um zu vermeiden, dass die Inhalte ignoriert (weil ja wirklich kommentiert!) werden. Bei ausgiebigem Gebrauch von Skripten ist darauf hinzuweisen, dass document.write() nicht mehr funktionieren wird. Weitere Informationen hierzu befinden sich unter anderem in Ian Hicksons legendärem Artikel Sending XHTML as text/html considered harmful.