nicht angemeldet
Hört sich für mich nach Missbrauch[tm] an.
Es ist aus einer reinen Sicht auf die Semantik natürlich wenig sinnvoll. Aber das ist Markup selten, wenn man JavaScript-Anwendungen schreibt. HTML ist keine UI-Sprache. Außer <button type="button"> gibt es in JavaScript nichts für diesen Zweck. Eine JavaScript-Anwendung ist nicht notwendig Hypertext, trotzdem nutzt sie dessen Konventionen.
Welche Nachteile ergeben sich durch diesen angeblichen »Missbrauch«? Keine. Es ist nicht anderen zweifelhaften Fehlauszeichnungen zu vergleichen. Dieses Argument habe ich schon vor Jahren widerlegt.
Wenn man es semantisch will, dann sollte man sich nicht über <a href> vs. <button> Gedanken machen, sondern um Anwendungsstatus, der sich als URL ausdrücken lässt, sodass die Anwendung letztlich doch Hypertext ist. Wenn man das richtig macht, ergibt sich von selbst, dass man gewöhnliche <a href> mit gewöhnlichen URLs nutzt. Wenn man sich ein wenig mit JavaScript-Anwendungen beschäftigt, sieht man, dass das längst Best Practice ist.
@href dient zur Angabe eines Linkziels. Kein Linkziel, kein @href.
Dann halt href="javascript:", wenn das das Semantikherz höher schlägen lässt.
… Tastaturzugänglichkeit und Fokussierbarkeit.
… Man bräuchte zusätzlich ARIA- und tabindex-GewurschtelDafür wären dann @tabindex und ggfs. ARIA-Attribute da. Was wäre daran unpraktikabel?
Es funktioniert nicht so robust wie <a href>. <a href> kann jeder Browser. Kein weiteres Markup nötig. Kein Wissen über obskure HTML5-Features und ARIA nötig. Man muss Fokussierbarkeit/Zugänglichkeit nachträglich »hinzufügen«, was viele vergessen werden.
Man kann mit JavaScript die Standardaktion von @href unterdrücken; ohne JavaScript gibt es aber wildes Herumgehüpfe bzw. gar Neuladen der Seite.
Das ist ein anderes Thema und hat mit <a href> vs. andere Lösungen wenig zu tun. Ein <button type="button"> oder <span> mit tabindex, ARIA und einer Menge an CSS wird auch nicht funktionieren, wenn JavaScript deaktiviert ist. Da klickt sich der Nutzer tot, was aus Sicht der Bedienbarkeit genauso schlimm ist.
Am besten ist man sicher mit einem button-Element dran. Und wenn man will, kann man das ja wie einen Link stylen.
Damit ist man nicht am besten dran. Man kann einen button nicht browserübergreifend und halbwegs abwärtskompatibel umstylen. CSS hat Formularelemente lange als Replaced Content definiert, und das wirkt sich auch heute noch aus. Die Umformatierung ist sehr aufwändig, benötigt eine Menge an Reset-Code und eine Menge an Cross-Browser-Wissen. Warum der Aufwand?
»Semantischer« wird der Code dadurch nicht. <button type="button"> hat mit semantischer Textauszeichnung genauso wenig zu tun wie <a href="javascript:"> oder sonst ein Element, das einen JavaScript-Handler verpasst bekommt und visuell als Schaltfläche erscheint.
<button type="button"> ist bloß eine erlaubte Ausnahme, die vor 12 Jahren geschaffen wurde, als JavaScript noch nichts konnte und man JavaScript noch in HTML-Attribute (onclick usw.) geschrieben hat. Es gab noch kein DOM, geschweige denn DOM Events. Diese Notlösung, die in HTML eigentlich nichts zu suchen hat, heutzutage für moderne Websites mit JavaScript-Logik zu promoten, ist schlicht Humbug. Hyperlinks mit JavaScript-Funktionalität zu belegen ist weit verbreitet und anerkannt. Es ist robust und und hat keine praktischen Nachteile.
Ich hab auch gerade mal rumgetabbt: Auf dem Mac bezieht lediglich Chrome a-Elemente mit ein; auf Firefox, Opera und Safari werden nur Buttons angesprungen.
Das lässt sich in Safari, Chrome und Opera einstellen. Opera hat dafür standardmäßig eine gesonderte Navigation (Command + Hoch/Runter bzw. die Spatial Navigation mit Shift + Pfeiltasten).
Mein Firefox springt auch Links an, vielleicht habe ich ihn so eingestellt.
Mathias
Gunnar Bittersmann
JürgenB