Peter Kröner, Webtechnologie-Erklärbär

Seit den Releases von Firefox 3 und Opera 9.5 stehen wir in einem neuen Browser-Zeitalter. Zwar wird der Internet Explorer dieses Zeitalter erst in 2-3 Jahren erreichen, aber trotzdem kann man mittlerweile eine ganze Menge CSS sinnvoll einsetzen, das noch vor ein paar Monaten kaum irgendwo funktionierte. Klar, im IE sieht man nichts davon, aber das muss uns nicht aufhalten, progressive enhancement ist das Zauberwort. Heißt: Die Website ist im Internet Explorer benutzbar, aber mit den neueren CSS-Features verleihen wir dem Ganzen in allen ordentlichen Browsern zusätzlichen Glanz. Ein Beispiel dafür ist text-shadow.

Was macht text-shadow?

Diese Frage lässt sich einfach beantworten: Mit text-shadow zaubert man sich mittels CSS einen Schatteneffekt unter Text. Sowohl Farbe als auch Versatz und Schattenradius lassen sich festlegen.

Wie benutzt man text-shadow?

Es gibt vier Paramter:

.schatten {
	text-shadow: #000000 4px -4px 2px;
}

Der erste Wert beschreibt die Farbe des Schattens, die nächsten beiden den Versatz auf X- und Y-Achse, während der letzte Wert die Härte des Schattens bestimmt; je höher der Wert, umso weicher der Schatten. Im Übrigen kann man auch mehrere Schatten definieren:

.schatten {
	text-shadow: #000000 4px -4px 2px, #FF0000 -1em 1em 0.5em, #CC0000 -2px -4px px;
}

Damit könnte man zum Beispiel einen Feuer-Effekt zaubern.

Welche Browser können text-shadow?

Opera seit Version 9.5 und Safari bereits seit Urzeiten – Firefox wird Ende dieses Jahres mit Version 3.1 nachziehen. Ob der Internet Explorer jemals text-shadow unterstützten wird, wissen allein die Götter. Es existieren für den IE mit DropShadow und Glow zwei proprietäre Funktionen, die einen ähnlichen Effekt wie text-shadow haben, die jedoch um einiges weniger gut ausehen, weniger flexibel sind und so keine ernsthafte Alternative darstellen.

Sofern man allerdings die Lesbarkeit seines Textes nicht vom Schatteneffekt abhängig macht, kann man text-shadow ohne Bedenken benutzen.

Noch mehr schönes neues CSS?

Falls Interesse besteht, könnte ich noch ein paar weitere Aspekte unserer schönen neuen CSS-Welt vorstellen. Unter anderem stünden die neuen Möglichkeiten der Farbangabe (RGBA und HSLA) oder font-size-adjust zur Auswahl. Lasst mich wissen falls ihr irgendwas davon haben wollt.

Läuft man einem Javascript-Link in freier Wildbahn über den Weg, ist die Wahrscheinlichkeit sehr hoch, dass dieser in etwa die Form <a onclick="tolle_funktion()" href="#"> hat. Warum nur!

Es scheint so, als würden Leute dies tun, weil sie nichts besseres haben, das sie den Link referenzieren lassen können. Sie benutzen das Rautezeichen quasi als Ersatz für nichts. Dass das recht wenig Sinn ergibt, versteht sich von selbst. Warum die Raute nehmen, wenn es auch gleich sein lassen könnte? Ich glaube das ist eine dieser seltsamen Traditionen als grauer Frontpage-Zeit, genau wie auch die Verwendung von   als normales Leerzeichen.

Statt Rautezeichen oder gar nichts gehört in das href-Attribut eines Links eine schöne URL, mit der man dem User möglichst genau das serviert, was auch die Javascript-Funktion zu bieten hat. Dann kommen nämlich auch jene, die kein Javascript zur Hand haben, in den Genuss der hinter dem Link verborgenen Informationen. Außerdem interpretieren Browser href="#" als Sprunglink zum Seitenanfang. Das will man doch wirklich nur in Ausnahmefällen.

Es gibt also keinen Grund, warum das href-Attribut eines Links jemals # sein sollte. Besser:

<a href="/ersatz-url/index.html" onclick="return tolle_funktion()">

Wenn man auf diesen Link klickt, und tolle_funktion() läuft wie sie soll, gibt sie (ordentliche Programmierung vorausgesetzt) false zurück und der Link ruft die url in href nicht auf. Wenn aber die Funktion auf Probleme stößt, wird nichts bzw. true zurückgegeben und der Benutzer landet bei der Ersatz-URL. Eine Testseite zur Demonstration steht bereit.

Wenn man das alles haben kann, warum noch zur Raute greifen?

Das Problem des <q>-Elements ist kein neues. Obwohl es steinalt ist, können es noch lange nicht alle Browser so verarbeiten wie es sein sollte. Eigentlich sollte es möglich sein, dem Element mit der CSS-Eigenschaft quotes Anführungszeichen zu verpassen, aber besonders Internet Explorer und Safari können dies aus irgendwelchen Gründen nicht ohne dass man etwas nachhilft. Für diesen Artikel wurden funktionierende Lösungen für beide Browser zusammengetragen.

Wie es funktionieren sollte

Normalerweise sollte die Zuweisung von Anführungszeichen für <q> wie folgt aussehen:

q {
    quotes:"0BB" "0AB" "203A" "2039";
}
q:before {
    content:open-quote;
}
q:after {
    content:close-quote;
}

In der quotes-Eigenschaft von q wird notiert, welche Anführungszeichen verwendet werden sollen. In diesem Fall sind das » als öffnendes und « als schließendes Zeichen sowie › und ‹ als Anführungszeichen für Zitate in Zitaten. Platziert und mit Styles versehen wird das Ganze in q:before und q:after.

Mit Attributselektoren wie z.B, body[lang=de] q, body[lang=en] q usw. lassen sich so (bei Bedarf) bequem viele unterschiedliche Systeme von Anführungszeichen definieren, aber trotzdem einheitlich gestalten. Soweit die Theorie.

Safari

In der Realität ist es jedoch so, dass Safari (laut Hersteller The world's best browser) schlichtweg quotes nicht versteht, wie mike zu berichten weiß. Will man dem Apple-Browser trotzdem Anführungszeichen verpassen, kommt man nicht umhin, diese direkt in in q:before und q:after zu notieren.

q:before {
    content:"0BB";
}
q:after {
    content:"0AB";
}
q q:before {
    content:"203A";
}
q q:after {
    content:"2039";
}

So bedient man zumindest bis zu einmal verschachtelte <q>-Elemente.

Internet Explorer

Die Internet Explorer der Versionen 6 und 7 machen es uns besonders schwer, da sie nicht nur wie Safari quotes nicht verstehen, sondern auch mit den Pseudoklassen :before und :after nichts anzufangen wissen. Da führt kein Weg an Scripts vorbei - zum Glück gibt es so etwas bei willCode4Beer.com.

Der erfahrene CSS-Nerd weiß, dass eine solche htc-Datei einfach hochgeladen und mit der IE-Eigenschaft behavior in einen Stylesheet eingebunden werden muss. Das könnte zum Beispiel so aussehen:

q {
    behavior:url(fixQuotes_en.htc);
}

Mehr ist nicht zu tun. In den Zeilen 9 und 10 der htc-Datei kann man fast wie in CSS festlegen, welche Anführungszeichen verwendet werden sollen.

Und jetzt ist alles bestens?

Mit diesen Lösungen kann man zwar beiden Browsern Anführungszeichen aufzwingen, aber richtig optimal sind beide Lösungen nicht. Für die Safari-Lösung muss man zumindest mehr CSS-Code aufwenden um zum gleichen Endergebnis wie quotes zu kommen.

Die Methode für den Internet Explorer hat das große Manko, dass htc-Dateien eben Scripts sind; stellt ein IE-Nutzer Javascript aus, gibt es für ihn keine Anführungszeichen. Mit validem CSS hat die behavior-Eigenschaft selbstverständlich auch nicht viel zu tun und eigene Styles kann man diesen Anführungszeichen ebenfalls nicht auf den Weg geben.

Aber am Ende hat man doch lieber solch hingewürgte Zeichen als gar keine. Wie man überhaupt richtig Anführungszeichen setzt, sagt euch dieser Artikel.

Ich war vorgestern morgen noch nicht mal richtig wach, da schrieb mich jemand über ICQ an und meinte, er hätte einen Vorschlag zu meinem Drop-Down-Menü mit CSS und (fast) ohne Javascript. Nach einem kleinen Test stellte sich dieser Vorschlag als ausgesprochen nützlich heraus, denn er macht auf einfache Art und Weise die alte Navigation für Screenreader lesbar.

Was ist anders?

Eine umgebaute Navigation ist weder optisch noch codeseitig großartig anders als eine Navigation alter Machart. Die Kernunterschiede: Die Navigationspunkte haben fest definierte Höhen und das „Verstecken“ der Untermenüs geschieht nicht durch Ausblenden via display:none; sondern dadurch, dass sie vom Elternelement abgeschnitten werden - overflow macht es möglich.

Das ist denkbar schwer in Worte zu fassen, also lassen wir CSS sprechen. Alt:

/* Normalzustand eingeklappt */
#navi li ul {
    display:none;
}

/* Ausgeklappt */
#navi li:hover ul {
    display:block;
}

Neu:

/* Normalzustand eingeklappt */
#navi > li {
    height:24px;
    overflow:hidden;
}

/* Ausgeklappt */
#navi > li:hover {
    height:auto;
    overflow:visible;
}

Angesichts dieser Zeilen dürfte es der geübte CSSler verstehen um was es geht. Diese Methode hat den großen Vorteil, von Screenreadern verstanden zu werden.

Navigation im Screenreader

Moderne Vorlese-Programme sind nämlich sehr exakte Maschinen, die vielleicht nicht unrichtig der Marschroute was nicht angezeigt werden soll, das lese ich nicht vor folgen. Das heißt, dass sich die alte Navigation vorgelesen so anhört, während die Neue wie folgt klingt.

Es zeigt sich: Die Navigation nach der neuen Methode wird vom Screenreader (in diesem Falle in der Kombination Jaws/Internet Explorer/Windows 2000) komplett vorgelesen, während beim alten Menü die Unterpunkte einfach verschluckt werden.

Ehre wem Ehre gebührt

Ausgebrütet hat diese Idee Sebastian Gebhard, der unter s.gebhard@friesenservice.de für Nachfragen und Lob bereit steht. Er bat mich um die Veröffentlichung, da ich seiner Ansicht nach mehr Leute erreichen könnte als er. Dafür ist seine Beispiel-Navigation viel schöner als meine.

Letzte Anmerkungen

Opera hat zur Zeit Probleme mit overflow, die zu überflüssigen Scrollbalken an den Navigationsleisten führen. Das ist nicht schön, aber eben ein nicht zu ändernder Programmfehler. Dieser Fehler kann dazu führen, dass das Menü gar nicht mehr benutzbar wird, weswegen gründliches Testen (natürlich) nötig ist.