href ist niemals #

Veröffentlicht am 14. Dezember 2007

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 &nbsp; 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?

Nachtrag vom Februar 2012: wie man Javascript-URLs für moderne Webapps mit HTML5 umsetzt, erklärt dieser Artikel.

Anführungszeichen in Internet Explorer und Safari

Veröffentlicht am 27. November 2007

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.

CSS-Navigation ohne Javascript: Reloaded (Screenreader-Tauglich)

Veröffentlicht am 23. August 2007

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

Überflüssige Scrollbalken in Opera

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.

Links mit target="_blank" gesondert markieren

Veröffentlicht am 4. August 2007

Unerwartet viel Gegenwind bekam ich für meinen Artikel Warum target="_blank" nervt und verboten gehört. Ich dachte, ich würde damit offene Türen einrennen, doch anscheinend werden neue Fenster erzwingende Links (und die Menschen die sie mögen) so bald nicht aussterben. Deswegen mein Appell: Wenn target="_blank" schon sein muss, sollten solche Links gekennzeichnet werden! Dieser Artikel erklärt, wie das mittels CSS ohne zusätzliches Markup sogar im Internet Explorer zu bewerkstelligen ist.

Wie man es nicht machen sollte

Die naheliegendste Lösung wäre es, allen Links mit target="_blank" eine Klasse zu verpassen und über diese per CSS zu gestalten. Das hätte den Nachteil, dass dabei zusätzlicher HTML-Code anfiele, den diese Lappalie eigentlich nicht wert ist. Auch dürfte es nicht immer einfach sein, eine Extra-Klasse zu implementieren, gerade wenn man die Markierung nachrüsten will.

Angriff der CSS32-Selektoren

Mit den schicken neuen Selektoren von CSS32 (danke Greg!) kann man HTML-Elemente anhand beliebiger Attribute auswählen. Damit wird das Markieren von Links mit target="_blank" zur Fingerübung:

a[target=_blank] {
    background:yellow;
}

Wenn man weiß, dass man nie Links haben wird, deren target-Attribut etwas anderes als _blank ist (was außerhalb von Framesets die Regel sein dürfte), kann man auch einfach alle Links mit target-Attribut markieren:

a[target] {
    background:yellow;
}

Mit der Unterstützung für diese Attribut-Selektoren sieht es ausgesprochen gut aus. Alle gängigen Browser kommen mit diesem Teil von CSS32 klar... wie erwartet mit einer Ausnahme.

Der Internet Explorer 6

Der IE6 kann mit element[attribut] nichts anfangen. Möchte man trotzdem bequem Links mit target="_blank" zu markieren, kann man Javascript zu Felde führen. Einfacher macht man es sich in diesem Falle aber mit einer proprietären IE-Spezialität. Die so genannten Dynamic Properties sind eine reichlich perverse Geschichte, denn sie ermöglichen nicht weniger als Scripting in Stylesheets. So ist es natürlich ausgesprochen einfach, a[target] { background:yellow; } für den Internet Explorer zu simulieren.

<!--[if lt IE 7]>
    <style type="text/css" media="screen">
        a {
            background: expression((this.target) ? 'yellow' : 'none');
        }
    </style>
<![endif]-->

Das ist vom Standpunkt des Webstandards-Advokaten aus absolut kriminell, funktioniert aber, wie diese Demoseite zeigt prächtig und ist dabei ausgesprochen handlich.

Fazit

Mit nur wenigen Zeilen CSS (und etwas perversem IE-only-Code) lassen sich Links, die das nicht unstrittige target="_blank" in sich tragen, gesondert auszeichnen. Das sollte man meiner Meinung nach auch dringend tun, denn nur so kann ein Nutzer wissen, ob ihn ein neues Fenster erwartet oder nicht.

Ich bleibe freilich bei meiner Meinung, dass Links, die ein neues Fenster erzeugen, aus den im vorherigen Artikel genannten Gründen eine Seuche sind. Wenn man target="_blank" denn unbedingt benutzen muss, dann doch bitte so.