nicht angemeldet
Hallo,
Es dient dazu, eine logische Verbindung zu einer anderen Ressource (oder zu einem bestimmten Punkt der aktuellen Ressource) herzustellen. Was der Browser dann mit der Information, die er in den Attributen des Elements findet, macht, ist erstmal irrelevant.
Also mir ist nicht egal, was beim Benutzer tatsächlich ankommt, ob das Ergebnis verständlich, benutzbar und robust ist. Neben dem Semantik-Elfenbeinturm gibts halt noch andere Sphären, die in Betracht zu ziehen wären.
Ob da nun eine HTTP-URI verlinkt ist oder nur JavaScript getriggert wird, ist praktisch irrelevant, sondern nur eine obskure und esoterische Frage der »Semantik«.
Und allein die ist bei einer Markup Language relevant.
Sorry, aber du weißt offenbar gar nicht, was du da redest, wenn du solche Sätze aufstellst. Damit ignorierst du nämlich jegliche Realität seit ungefähr 15 Jahren.
Eine Linkliste soll doch darstellen, wohin man von einem bestimmten Punkt aus gelangen soll.
Da ist massig Interpretationsspielraum: Ich will von einer Stelle im Formular zu einem Date-Picker für dieses Formularfeld gelangen. Ist das nun ein Link? Oder keiner, nur weil die Funktionalität mit JavaScript gelöst wird?
Da hat eine interaktive Funktionalität innerhalb einer Ressource mal gar nichts zu suchen.
Kann man das so einfach trennen? Wir reden hier über die Paralleldarstellung von mehreren Ressourcen. Über Popups, Iframes und Ajax werden nicht mehr bloß statische Ressourcen im Browser angezeigt, die ausschließlich über Hyperlinks und Formulare (und einem anschließenden Ressourcen-Wechsel im gesamten Fenster) mit dem Server kommunizieren können.
Das Web war noch nie so eindimensional. Oder nur ganz kurze Zeit, als es noch auf Tim Berners-Lees localhost passierte. Dann erfand jemand Browser mit fensterbasiertem GUI, JavaScript, Frames und so weiter.
Oder aber des Entwicklers, der den Button nicht mit einem http://de.selfhtml.org/html/formulare/tastatur.htm#tabreihenfolge@title=Tabindex versehen hat.
Wie gesagt - manche Browser trennen das Durchlaufen von Links und Formularfeldern. Screenreader haben spezielle Formular-Lesemodi. Zu welcher Gruppe gehören wohl Buttons mit tabindex? ;)
Webseiten, die clientseitig dynamisch sind.
Sicher. Aber deswegen dürfen wir die Struktur der Seite/des Dokuments nicht verhunzen.
Noch so ein moralisches Dogma.
Ich sehe das ganz anders, weil ich in der gegenwärtigen HTML-Anwendung keinen reinen Hypertext sehe. Mit HTML lassen sich freilich Hypertexte auszeichnen und ganz klassische Hypertext-Anwendungen mit serverseitiger Dynamik umsetzen. Bei jeder Benutzer-Aktion wird eine Ressource (das »Dokument«) vom Server bezogen, die eine eindeutige URI hat.
Natürlich hat dieses klassische Modell seine Vorzüge. Aber es stirbt aus, die meisten Webseiten werden mit immer mehr clientseitiger Logik aufgebrezelt. Ajax ebnet den Weg für Single-Page-Applications, die das klassisches Web im Sinne von Hypertext-Dokumenten, HTTP-Ressourcen und -URIs verdrängen.
Wenn du die Funktion von HTML auf eine bloße Beschreibungssprache für Hypertexte begrenzt, blendest du diese Realität aus. Und anstatt sich mit ihr auseinanderzusetzen, belegst du sie mit moralischen Verboten. Glaubst du, das das von Erfolg gekrönt ist?
Auf der Ebene von bloßer Dokument-Beschreibung kann man sich sinnvoll über »richtige Semantik« Gedanken machen, darüber hinaus stößt man auf Widersprüche. Eigentlich wirst du keine nennenswerte Webanwendung mit »Dokumenten« mehr finden, die auf andere »Dokumente« verlinken.
Schau dir mal die hunderten Ajax-Anwendungen an, die viele tagtäglich nutzen. Da werden ständig a-Elemente »missbraucht«, weil die Autoren auf das dem Benutzer hinlänglich bekannte UI-Pattern von Hyperlinks zurückgreifen: Blauen Text mit Unterstrich, spezieller Zeiger, spezielle Anspringbarkeit usw.
Ich weiß ehrlich gesagt nicht, wer dadurch einen Nachteil hatte. Im Gegenteil: Wenn man das Dogma »Nur button ist erlaubt« anwenden würde, müssten all diese Webanwendungen Hacks einsetzen, um button oder ein anderes Element dazu zu bringen, sich wie ein a zu verhalten. Die Benutzbarkeit würde dadurch eher geschmälert und die Entwicklung von solchen Anwendungen erschwert.
dem Element, das bei einem Klick irgendwie reagieren soll, den passenden Eventhandler geben - fertig. Wenn es darüber hinaus per Tastatus ansteuerbar sein soll, noch einen Tabindex verpassen. IMHO müsste das (und natürlich die gewünschte Formatierung des Aussehens mittels CSS) reichen.
Schön, aber warum so einen Kopfstand? Der »Semantik« wegen? Ich schreibe keine reinen Hypertexte, sondern Webanwendungen. Da HTML nicht XUL oder XAML ist, habe ich keinen Anspruch, etwas, was nicht vom HTML-Vokabular abgedeckt wird, in HTML korrekt auszuzeichnen (wobei ich a nicht weit hergeholt halte - eigentlich sogar weniger als button).
Wenn ich eine UI-Control haben will, die wie ein Hyperlink aussieht, sich wie ein Hyperlink anfühlt, setze ich einen Hyperlink. Auch wenn ich kein reines Hypertext-Dokument habe, sondern eine JavaScript-Anwendung auf HTML-Basis. Auch wenn ich gar nicht notwendig auf ein Hypertext-Dokument oder eine andere HTTP-Ressource verlinke, sondern gegebenfalls nur ein Script anstoßen will, dass die Sache mit den Ressourcen im Hintergrund oder eben im Popup-Fenster erledigt.
Schau dir mal HTML 5 und Web Forms 2.0 an, da trägt man der Praxis Rechnung, dass HTML viel mehr ist als bloß »Dokumentbeschreibung« und Hypertextualität. Wenn du command, datagrid, progress, output usw. in HTML 5 seht, muss dir ja die Semantik-Hutschnur platzen. ;) Da wird genau das angegangen, was ich sagen will.
Aber wenn hier jemand fragt, warum was nicht geht oder wie er es besser machen sollte, dann darf man ihn doch wohl darauf hinweisen, dass das, was er bisher gemacht hat, eigentlich nicht richtig ist und ihm Tipps geben, wie er es besser machen kann?
Dann viel Glück dabei, mit abgehobenen Argumenten bei Leuten zu landen, die bloß funktionierende Websites bauen wollen. JavaScript-Logik einbauen geht nicht immer »semantisch«. Zumindest nicht mit dem derzeitigen HTML. Das ist nicht schlimm, sondern muss man akzeptieren, um sich der wichtigen semantischen Textauszeichnung zuwenden zu können.
Mathias