nicht angemeldet
Hallo,
Zitat aus der wikipedia
Ich weiß, was ein Hyperlink ist. Dazu habe ich mich schon im verlinkten Posting ausgelassen.
wenn ich also <a href="javascript:" />oder <a href="#" onclick="" /> verwende, nutze ich das element nicht entsprechend seinr ursprünglichen bedeutung
Wenig verwunderlich, denn HTML antizipiert keine JavaScript-Anwendungen auf HTML-Basis, insofern wird man im HTML-Standard kein Element außer vielleicht <button type=button> finden, das für den Zweck »ursprünglich« gedacht ist.
ich nutze ihn um das von dir genannte spezielle verhalten eines links (automatisch gesetzter tabindex, focus, hover, active) zu nutzen obwohl es da rein um eine funktionalität/visuelle eigenschaft geht, die vom element erzeugt wird = präsentation
Verhalten und Präsentation, ja. Im Übrigen geht es darum, dass ein Link ein Link ist und als solcher behandelt wird und in verschiedenen Kontexten ausgegeben wird, ohne dass das mit CSS oder JavaScript nachbildbar wäre. Versuch mal einem span ein Verhalten zu geben, dass es in einem Screenreader aktivierbar ist. Ja, man kann auch JavaScript-Anwendungen für solche zugänglich machen.
wenn ich eine überschrift ohne umbruch dahinter haben will, verwende ich ja auch nicht <b>blah</b> weil die standardeigenschaften von <b /> besser geeignet dafür sind
Der Vergleich ist genauso unpassend wie der mit Tabellenlayout vs. CSS.
Nochmal, auch hier: Ein hx-Element kann ich mit geringem Aufwand umformatieren und das ist auch die vorteilhafteste Möglichkeit, aus verschiedenen Gründen. Aber was hat das mit JavaScript und a zu tun? Warum es da nicht vorteilhaft ist, irgendein anderes Element zu nehmen und mit viel Aufwand und sehr ineffektiv das Verhalten von a nachzubilden, habe ich beschrieben. Da gehts du einfach nicht drauf ein.
<a /> element kein anker ist und auch kein verweis auf eine andere seite, dann wird er nicht im sinne seines eigentlichen verwendungszwecks gebraucht
»Ursprünglicher Verwendungszweck«, my ass! Du vergleichst Äpfel und Birnen, wenn du triviale Vergleiche aus dem Feld HTML vs. CSS anführst. Es geht aber um JavaScript, den dritten Faktor neben Inhaltsstruktur und Präsentation. Wie ich JavaScript-Logik einbinde und welche (ggf. vorhandenen, bekannten, schon implementierten) UI-Pattern ich nutze, ergibt sich doch nicht aus der Trennung von Textauszeichung (HTML) und Präsentation (CSS). Denn es gibt keine semantische Auszeichnung von JavaScript-Schaltflächen, außer vielleicht button/input type=button, das ist dann aber eher eine Nicht-Auszeichnung - was natürlich nicht unbedingt schlecht ist.
Deshalb kann man die Frage überhaupt nicht aus der Richtung »semantische Auszeichnung« einholen, höchstens negativ bestimmen. Da könnte man natürlich sagen, eine Schaltfläche ist kein Hyperlink. Wenn man das so streng sieht: Stimmt. Andererseits sehe ich keine praktischen Nachteile davon, ein a dafür zu benutzen, denn dessen herkömmliches Verhalten ist mir nur nützlich. Und als UI-Control liegt dessen allgemeine Bedeutung meiner Absicht auch überhaupt nicht fern. (Siehe verlinktes Posting.) Das ist bei den von dir angeführten Vergleichen ganz anders, da wird einfach grob HTML fehlverwendet, sodass handfeste Verwirrungen entstehen.
und das ist eine geschichte, die man nicht tut
Heul.
genausowenig nutzt man blockquote für einrückungen
Noch so ein beknackter Vergleich. Ich will keine Präsentation mit HTML lösen, die ich mit CSS so einfach ersetzen könnte und dabei viele Vorteile bekommen würde. Ganz im Gegenteil. Verhalten und Aussehen von a für den Zweck einer reinen JavaScript-Schaltfläche kann ich nicht äquivalent mit CSS erzeugen und den Gewinn, den ich bei bedeutungsvoller Textauszeichnung plus CSS-Formatierung in anderen Fällen (die meisten deiner Beispiele) habe, kann ich in dem Fall gar nicht erreichen.
oder defintionslisten für bildergalerien
Warum nicht. Da streiten sich die Experten. Ich sehe da eine enorme Grauzone, vgl. auch HTML 5.
und fieldsets und legends für die aufteilung von seiten obowhl in der tat fieldset und legend eigenschaften an den tag legen, die sich mit anderen elementen so nicht reproduzieren lassen
Ja, aber keine essentiellen. Ich habe keinen funktionalen Gewinn, wenn ich fielset/legend missbrauche, sondern funktionale Nachteile, weil ich falsche Informationen einstreue. Das ist bei a mit javascript:-URI tendenziell auch der Fall, z.B. bietet mir der Browser aus, den Link in einem neuen Fenster zu öffnen, was bei javascript: natürlich Unsin ist. Das will ich auch gar nicht leugnen.
Aber wie gesagt. Das ist millionenfache Praxis und ich halte diese nicht generell für gefährlich, sondern für größtenteils vorteilhaft. Wenn man das kritisieren will, gerne, denn es gibt berechtigte Einwände und Unstimmigkeiten. Das bloß theoretische Argument, dass es verquerte Textauszeichnung sei, mag stimmen, ist aber zahnlos und geht am Kern vorbei. Natürlich ist das nicht mehr als ein Hack - die Theorie, also HTML 4, ist da einfach anachronistisch. Das könnte man eher auf Basis von HTML 5 diskutieren, wo die Macher der Textauszeichnungssprache eingesehen haben, dass HTML eben auch als Grundlage für Scripting-Anwendungen dient.
Mathias