addEventListener und # in der Adresszeile

[Siri]

Hallo,

ich hab einen EventListener registriert (elementXY.addEventListener("click", exampleJS, false) ). Beim Anklicken erscheint dann diese kleine, hässliche # in der Adresszeile des Browsers. Hab versucht, das mit return false; in der exampleJS zu unterbinden. Hat aber keine Auswirkung. Gibt's da eine Möglichkeit?

Grüße
Siri

[ChrisB]

Hi,

ich hab einen EventListener registriert (elementXY.addEventListener("click", exampleJS, false) ). Beim Anklicken erscheint dann diese kleine, hässliche # in der Adresszeile des Browsers. Hab versucht, das mit return false; in der exampleJS zu unterbinden. Hat aber keine Auswirkung. Gibt's da eine Möglichkeit?

Stichworte: event.preventDefault, event.cancleBubble.

MfG ChrisB

[Siri]

Hallo,

Stichworte: event.preventDefault, event.cancleBubble.

Danke!

Grüße
Siri

[Gunnar Bittersmann]

@@Siri:

nuqneH

Beim Anklicken erscheint dann diese kleine, hässliche # in der Adresszeile des Browsers.

Hast du etwa <a href="#"> im HTML zu stehen? Dann behebe diesen Fehler!

Qapla'

[Siri]

Hallo,

Hast du etwa <a href="#"> im HTML zu stehen? Dann behebe diesen Fehler!

Sehr gerne, nur wie?
<a href=""> -> Der Eventlistener funktioniert nicht mehr
<a> -> Der Mauszeiger wandelt sich nicht mehr um

<a> weg lassen und Mauszeiger per CSS?

Grüße
Siri

[JürgenB]

Hallo Siri,

wenn du etwas zum "drauf drücken" suchst, nimm einen Knopf (<button type="button">)

Gruß, Jürgen

[Siri]

Hallo,

wenn du etwas zum "drauf drücken" suchst, nimm einen Knopf (<button type="button">)

Wenn ich an der Stelle aber ein Bildchen haben möchte mit einem Pfeil, wieso soll ich erst den Umweg über einen button gehen und den dann wieder mit dem bildchen als Grafik formatieren?

Grüße
Siri

[JürgenB]

Hallo Siri,

Wenn ich an der Stelle aber ein Bildchen haben möchte mit einem Pfeil, wieso soll ich erst den Umweg über einen button gehen und den dann wieder mit dem bildchen als Grafik formatieren?

dann gib dem Bild den onclick, oder leg das Bild in den Button.

Gruß, Jürgen

[Siri]

Hallo,

dann gib dem Bild den onclick, oder leg das Bild in den Button.

Das bekommt es ja, aber dann ändert sich der Cursor nicht. Und man sollte schon sehen, dass man klicken kann. Deshalb meine Frage auf die Antwort von Gunnar, was "best practice ist".

Grüße
Siri

[JürgenB]

Hallo Siri,

dann gib dem Bild den onclick, oder leg das Bild in den Button.

Das bekommt es ja, aber dann ändert sich der Cursor nicht. Und man sollte schon sehen, dass man klicken kann. Deshalb meine Frage auf die Antwort von Gunnar, was "best practice ist".

dann ändere den Cursor per css.

Gruß, Jürgen

[Gunnar Bittersmann]

@@Siri:

nuqneH

Hast du etwa <a href="#"> im HTML zu stehen? Dann behebe diesen Fehler!

<a href="#"> ist immer falsch, wenn (ohne JavaScript) kein Sprung zum Seitenanfang gewünscht ist. Also so gut wie immer.

<a href=""> -> Der Eventlistener funktioniert nicht mehr

Wie hast du das Element selektiert, auf das du das Event registriert hast?

<a href=""> ist genauso falsch. Wenn es kein Link irgendwohin ist, darf das a-Element kein @href-Attribut haben.

<a> -> Der Mauszeiger wandelt sich nicht mehr um
<a> weg lassen und Mauszeiger per CSS?

Ein a-Element ohne @href-Attribut kann durchaus angebracht sein.

Mauszeiger per CSS, ja.

Qapla'

[Siri]

Hallo,

Wie hast du das Element selektiert, auf das du das Event registriert hast?

Inwiefern spielt es eine Rolle, wie das element selektiert wurde (nur um dazu zu lernen)? Ich hab es über getElementById selektiert und dann EventListener geadded.

Grüße
Siri

[Gunnar Bittersmann]

@@Siri:

nuqneH

Inwiefern spielt es eine Rolle, wie das element selektiert wurde (nur um dazu zu lernen)?

Na, hätte ja sein können, du hast es über [href="#"] selektiert.

Ich hab es über getElementById selektiert und dann EventListener geadded.

Dann gibt es keinen Grund, warum der Event-Listener ohne @href nicht funktinonieren sollte.

Qapla'

[Siri]

Hallo,

Dann gibt es keinen Grund, warum der Event-Listener ohne @href nicht funktinonieren sollte.

Funktioniert ja auch ;-)

Grüße
Siri

[molily]

<a> -> Der Mauszeiger wandelt sich nicht mehr um
<a> weg lassen und Mauszeiger per CSS?

Ein a-Element ohne @href-Attribut kann durchaus angebracht sein.

Das ist unpraktikabel. Warum man ein besser a-Element mit href verwenden sollte, lässt sich im Archiv nachlesen. Ein Punkt ist Tastaturzugänglichkeit und Fokussierbarkeit.

Mauszeiger per CSS, ja.

Das ist nicht hinreichend. Man bräuchte zusätzlich ARIA- und tabindex-Gewurschtel, um die Funktionalität zu bekommen, die einem <a href=""> von Haus aus bietet.

Völlig unnötig, wenn man <a href> und sinnvolles Event-Handling verwendet, anstatt etwas Halbgares zusammenbasteln, was nicht ans Original herankommt.

Ziel sollte natürlich sein, Anwendungsstatus möglichst in der URL abbilden zu können, um Adressierbarkeit und gewohnte History-Navigation zu ermöglichen. Dabei können übrigens Hash- und. pushState/popstate-Lösungen helfen:

https://github.com/balupton/History.js/
http://diveintohtml5.info/history.html
http://backbonejs.org/#History

Mathias

[Gunnar Bittersmann]

@@molily:

nuqneH

Das ist unpraktikabel. Warum man ein besser a-Element mit href verwenden sollte, …

Hört sich für mich nach Missbrauch[tm] an.

@href dient zur Angabe eines Linkziels. Kein Linkziel, kein @href.

… Tastaturzugänglichkeit und Fokussierbarkeit.
… Man bräuchte zusätzlich ARIA- und tabindex-Gewurschtel

Dafür wären dann @tabindex und ggfs. ARIA-Attribute da. Was wäre daran unpraktikabel?

Völlig unnötig, wenn man <a href> und sinnvolles Event-Handling verwendet

Man kann mit JavaScript die Standardaktion von @href unterdrücken; ohne JavaScript gibt es aber wildes Herumgehüpfe bzw. gar Neuladen der Seite.

Am besten ist man sicher mit einem button-Element dran. Und wenn man will, kann man das ja wie einen Link stylen.

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. Unter Windows sieht’s besser aus: in IE, Firefox, Chrome funktioniert’s, lediglich Opera fällt durch.

Qapla'

[molily]

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-Gewurschtel

Dafü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

[molily]

Hallo,

siehe Unterdrücken der Standardaktion des Ereignisses.

Mathias