Funktion aufrufen - welche Methode?

[Sebastian Goertz]

Hallo,

ich habe schon versucht, mich schlau zu lesen, aber bin es nicht geworden. Wenn ich bei Click eine Javascript-Funktion ausführen möchte, wie tue ich es am Besten? Mir fallen spontan 3 Methoden ein:

<a href="javascript:meineFunktion()">Klick mich</a>  
  
<a href="#" onClick="meineFunktion()">Klick mich</a>  
  
<span onClick="meineFunktion()" style="cursor:hand">Klick mich</span>

Welche Unterschiede gibt es?

Viele Grüße,
Sebastian

[ChrisB]

Hi,

Wenn ich bei Click eine Javascript-Funktion ausführen möchte, wie tue ich es am Besten?

So, dass
a) möglichst eine sinnvolle Alternative geboten wird, falls JavaScript nicht verfügbar ist (z.B. normaler Link auf eine andere Ressource, die die gleichen Inhalte/Funktionalitäten bereitstellt), und
b) die Trennung von Inhalt, Präsentation und (Script-)Logik gewährleistet bleibt, Stichwort unobtrusive JavaScript.

Mir fallen spontan 3 Methoden ein:

<a href="javascript:meineFunktion()">Klick mich</a>

<a href="#" onClick="meineFunktion()">Klick mich</a>

<span onClick="meineFunktion()" style="cursor:hand">Klick mich</span>

  
Die sind alle ziemlich von Vorgestern.  
  
MfG ChrisB  
  

-- 
RGB is totally confusing - I mean, at least #C0FFEE should be brown, right?

[Kai345]

[latex]Mae  govannen![/latex]

ich habe schon versucht, mich schlau zu lesen, aber bin es nicht geworden. Wenn ich bei Click eine Javascript-Funktion ausführen möchte, wie tue ich es am Besten? Mir fallen spontan 3 Methoden ein:

<a href="javascript:meineFunktion()">Klick mich</a>

Ein Link, der nur funktioniert, wenn JS eingeschaltet ist. Nutzer ohne JS sehen einen Link und beim draufklicken passiert nichts. Daher unbrauchbar.

<a href="#" onClick="meineFunktion()">Klick mich</a>

Ein Link, der nur funktioniert, wenn JS eingeschaltet ist. Bei Nutzern ohen JS wird zum Seitenanfang gesprungen, man muß mühevoll die vorherige Position wiederfinden. Insbesondere bei umfangreichen Seiten unschön. Daher unbrauchbar.

<span onClick="meineFunktion()" style="cursor:hand">Klick mich</span>

Die beste deiner drei Methoden. Allerdings auch mit Nachteilen:

a) Man kann diesen Bereich nicht per Tastatur erreichen, daher sollte man schon ein a-Element nehmen, dieses allerdings erst per Javascript ins Dokument einfügen.
b) Heutzutage ist es Usus, Inhalt und dynamische Funktionalität trennen, d.h. JS in eine grtrennte Datei auszulagern. Dies beinhaltet (hallo Martin) auch die Zuweisung von Events. Beispielsweise per addEvent ff

Stur lächeln und winken, Männer!
Kai

[Sebastian Goertz]

Hallo,

Ein Link, der nur funktioniert, wenn JS eingeschaltet ist. Nutzer ohne JS sehen einen Link und beim draufklicken passiert nichts. Daher unbrauchbar.

Ich habe nicht vor, diesen Link überhaupt darzustellen, sofern Javascript deaktiviert ist. Also per CSS grundsätzlich erst einmal ausgeblendet und erst durch Javascript wird dies geändert.

b) Heutzutage ist es Usus, Inhalt und dynamische Funktionalität trennen, d.h. JS in eine grtrennte Datei auszulagern. Dies beinhaltet (hallo Martin) auch die Zuweisung von Events. Beispielsweise per addEvent ff

Also einen EventListener einbauen und der tatsächliche Link sähe dann nur noch so aus:

<a href="#" id="meineID">Klick mich</a>

Wird dann natürlich ebenfalls per CSS ausgeblendet, per JS gezeigt. Richtig so?

Viele Grüße,
Sebastian

[ChrisB]

Hi,

Also einen EventListener einbauen und der tatsächliche Link sähe dann nur noch so aus:

<a href="#" id="meineID">Klick mich</a>

Wenn nichts verlinkt werden soll, braucht es keinen Link.
Die von Kai angesprochene Bedienbarkeit per Tastatur erreicht man durch das tabIndex-Attribut.

Wird dann natürlich ebenfalls per CSS ausgeblendet, per JS gezeigt. Richtig so?

Nein, wird per JS erzeugt und ins Dokument eingefügt.

MfG ChrisB

[Kai345]

[latex]Mae  govannen![/latex]

<a href="#" id="meineID">Klick mich</a>

Wenn nichts verlinkt werden soll, braucht es keinen Link.
Die von Kai angesprochene Bedienbarkeit per Tastatur erreicht man durch das tabIndex-Attribut.

Stimmt, href sollte man dann gar nicht setzen, dann spart man sich den ganzen Müll mit der Unterdrückung der Standard-Aktion.

Es bleibt also <a tabindex="3" id="meineID">Klick mich</a> übrig

Stur lächeln und winken, Männer!
Kaiig.

[molily]

Wenn nichts verlinkt werden soll, braucht es keinen Link.
Die von Kai angesprochene Bedienbarkeit per Tastatur erreicht man durch das tabIndex-Attribut.

Wie bitte? Ihr plädiert dafür, ein a-Element mit JS zu erzeugen, aber ohne href-Attribut, dafür mit festem tabindex, damit es anspringbar ist?

Sorry, das ist doch Quatsch. Den tabindex überhaupt zu setzen ist eine sehr schlechte Idee, und wenn, dann wäre lediglich »0« ein sinnvoller Wert für ein Element, welches fokussierbar gemacht werden soll, weil es standardmäßig nicht fokussierbar ist.

Davon abgesehen weiß ich nicht, was das Problem von href="#" oder href="javascript:" sein soll. Das Problem, dass ich bei letzterem sehe, ist vielmehr, dass die Handlerfunktion global erreichbar sein muss, im globalen Kontext ausgeführt wird und damit weder Zugriff auf das Eventobjekt noch auf das Ziel-Element hat. Daher ist der Hinweis auf ein vernünftiges addEvent natürlich wichtig; nur damit lässt sich Event-Handling flexibel umsetzen. »Es ist kein Link, daher lass das href weg und bastel dir was mit tabindex« ist jedoch kein brauchbares Argument.

Mathias

[ChrisB]

Hi,

Wie bitte? Ihr plädiert dafür, ein a-Element mit JS zu erzeugen, aber ohne href-Attribut, dafür mit festem tabindex, damit es anspringbar ist?

Nicht unbedingt ein A-Element.

Sorry, das ist doch Quatsch. Den tabindex überhaupt zu setzen ist eine sehr schlechte Idee

Weil?

MfG ChrisB

[molily]

Nicht unbedingt ein A-Element.

Das wäre noch schlimmer.

Sorry, das ist doch Quatsch. Den tabindex überhaupt zu setzen ist eine sehr schlechte Idee

Wieso sollte man es so umständlich und gleichzeitig unzuverlässiger machen? Normale Hyperlinks bringen die Funktionalität, die man sich wünscht, von Haus aus in sämtlichen User Agents mit. Alles andere heißt, Teilfunktionalitäten zu emulieren, bspw. mit tabindex="0". Das ist in der Regel schlechter als das Original.

Mathias

[molily]

Das wäre noch schlimmer.

Dieser Link sollte hierauf zeigen, nicht auf das Posting, auf das ich geantwortet habe:

</archiv/2009/2/t183584/#m1215982>

[Gunnar Bittersmann]

@@molily:

nuqneH

Davon abgesehen weiß ich nicht, was das Problem von href="#" oder href="javascript:" sein soll.

Das Problem von @href="#" wurde schon genannt: Es wird zum Seitenanfang gesprungen, was man wohl nicht will.

Wenn schon ein Link, dann @href="?" — no harm done.

Das Problem, dass ich bei letzterem sehe, ist vielmehr, dass die Handlerfunktion global erreichbar sein muss, im globalen Kontext ausgeführt wird und damit weder Zugriff auf das Eventobjekt noch auf das Ziel-Element hat.

Wenn den die Funktion denn per @href aufgerufen wird. Das muss (sollte) man nicht tun. Einfach @href="javascript:{}" oder @href="javascript:;" – damit wird dem Nutzer in der Statuszeile angezeigt, dass beim Klick kein Link angesprungen, sondern JavaScript ausgefüht wird. Die eigentliche Funktion wird per
„vernünftigem addEvent“ zugewiesen.

Qapla'

[molily]

Das Problem von @href="#" wurde schon genannt: Es wird zum Seitenanfang gesprungen, was man wohl nicht will.

Schon klar. Das passiert aber nur, wenn man die Standardaktion nicht unterdrückt. Ich sehe kein Problem darin, das zu tun. Kai schon, Zitat: »dann spart man sich den ganzen Müll mit der Unterdrückung der Standard-Aktion«.
Das ist vielleicht nervig, aber wenn man das sinnvoll implementiert, stört es auch nicht und muss nicht ständig wiederholt werden.

Einfach @href="javascript:{}" oder @href="javascript:;" – damit wird dem Nutzer in der Statuszeile angezeigt, dass beim Klick kein Link angesprungen, sondern JavaScript ausgefüht wird. Die eigentliche Funktion wird per „vernünftigem addEvent“ zugewiesen.

Ja, das ist natürlich möglich.

Mathias

[Kai345]

[latex]Mae  govannen![/latex]

Das Problem von @href="#" wurde schon genannt: Es wird zum Seitenanfang gesprungen, was man wohl nicht will.

Schon klar. Das passiert aber nur, wenn man die Standardaktion nicht unterdrückt. Ich sehe kein Problem darin, das zu tun. Kai schon, Zitat: »dann spart man sich den ganzen Müll mit der Unterdrückung der Standard-Aktion«.

Nö, ich sehe darin überhaupt kein Problem; es ist aber nun einmal Tatsache, daß die Meisten, die sowas machen, genau diese Unterdrückung (in welcher Form auch immer) eben nicht vornehmen. Zumindest taucht die Frage, weshalb beim Kick auf einen Link die Funktion ausgeführt, aber dann doch eine neue Seite geladen/zum Seitenanfang gesprungen wird, hier im Forum sehr regelmäßig auf. Insofern hatte ich das als Chance gesehen, eine andere Möglichkeit vorschlagen zu können, bei der man sich eben nicht mehr um die Unterdückung der Standard-Aktion kümmern und die Notwendigkeit selbiger erklären muß.

Ich persönlich habe meist die Methode mit href="javascript:;" gewählt.

Vielleicht ist tabindex wirklich nicht der Weisheit letzter Schluss.

Stur lächeln und winken, Männer!
Kai

[Kai345]

[latex]Mae  govannen![/latex]

Ein Link, der nur funktioniert, wenn JS eingeschaltet ist. Nutzer ohne JS sehen einen Link und beim draufklicken passiert nichts. Daher unbrauchbar.
Ich habe nicht vor, diesen Link überhaupt darzustellen, sofern Javascript deaktiviert ist. Also per CSS grundsätzlich erst einmal ausgeblendet und erst durch Javascript wird dies geändert.

Und der blinde Nutzer mit seinem Screenreader ohne CSS sieht den Link wieder und kann ihn nicht aktivieren.

Also einen EventListener einbauen und der tatsächliche Link sähe dann nur noch so aus:

<a href="#" id="meineID">Klick mich</a>

Wird dann natürlich ebenfalls per CSS ausgeblendet, per JS gezeigt. Richtig so?

Siehe oben. Wie man es nun effektiv „richtig“ macht, hängt auch sehr von der beim Klick ausgeführten Funktionalität ab. Wird beispielsweise zusätlicher Inhalt eingebunden/angezeigt, würde sich wiederum eine ganz andere Vorgehensweise empfehlen. Wird nur irgendwas Unwichtiges ausgeführt, auf das man ggf. verzichten kann, geht obige Lösung schon eher in Ordnung

Stur lächeln und winken, Männer!
Kai

[molily]

Und der blinde Nutzer mit seinem Screenreader ohne CSS sieht den Link wieder und kann ihn nicht aktivieren.

Du kannst sicher verschiedene Screenreader nennen, die JavaScript, aber kein CSS unterstützen, oder?

Mathias

[Kai345]

[latex]Mae  govannen![/latex]

Und der blinde Nutzer mit seinem Screenreader ohne CSS sieht den Link wieder und kann ihn nicht aktivieren.

Du kannst sicher verschiedene Screenreader nennen, die JavaScript, aber kein CSS unterstützen, oder?

Was tut das zur Sache? Wenn der Link direkt im Quelltext steht und „nur“ per CSS ausgeblendet ist, sieht man ihn ohne CSS-Unterstützung in jedem Fall -- unabhängig davon, ob JavaScript aktiv/unterstützt wird oder nicht.

Stur lächeln und winken, Männer!
Kai

[molily]

Und der blinde Nutzer mit seinem Screenreader ohne CSS sieht den Link wieder und kann ihn nicht aktivieren.

Du kannst sicher verschiedene Screenreader nennen, die JavaScript, aber kein CSS unterstützen, oder?

Was tut das zur Sache?

Das Beispiel ist hanebüchen und nicht praxisrelevant.

Wenn der Link direkt im Quelltext steht und „nur“ per CSS ausgeblendet ist, sieht man ihn ohne CSS-Unterstützung in jedem Fall -- unabhängig davon, ob JavaScript aktiv/unterstützt wird oder nicht.

Das ist ja richtig. Wenn eine JS-Funktionalität nicht in der Sache von CSS abhängig, ist es nur nachteilig, sie ohne Grund davon abhängig zu machen. Das ist allerdings mehr eine methodische Frage der Separation of concerns und damit der korrekten Umsetzung des Schichtenmodells, in dem JavaScript und CSS nicht immer übereinanderliegen, sondern teilweise nebeneinander. In der Praxis gibt es so gut wie keine Fälle, in denen die genannte Kopplung von JS und CSS zu gravierenden Nachteilen führt. Screenreader, in denen eine solche Einstellung Standard ist, gibt es meines Wissens nicht. CSS zu deaktivieren, während JavaScript aktiv ist, ist natürlich in verschiedenen Browsern und damit auch Screenreadern möglich.

Mathias

[Kai345]

[latex]Mae  govannen![/latex]

Wenn der Link direkt im Quelltext steht und „nur“ per CSS ausgeblendet ist, sieht man ihn ohne CSS-Unterstützung in jedem Fall -- unabhängig davon, ob JavaScript aktiv/unterstützt wird oder nicht.

In der Praxis gibt es so gut wie keine Fälle, in denen die genannte Kopplung von JS und CSS zu gravierenden Nachteilen führt. Screenreader, in denen eine solche Einstellung Standard ist, gibt es meines Wissens nicht. CSS zu deaktivieren, während JavaScript aktiv ist, ist natürlich in verschiedenen Browsern und damit auch Screenreadern möglich.

?? Irgendwie redest du über einen anderen Anwendungsfall als den in https://forum.selfhtml.org/?t=204126&m=1381874.

Dort lese ich, daß er den Link in den Quelltext schreibt, per CSS verstecken will (also per display: none oder negativem margin) und ihn per JS wieder sichtbar machen will. (direkt oder per Änderung einer Klassenzugehörigkeit, tut nichts zur Sache)

Also wird bei fehlender CSS-Fähigkeit der Link angezeigt, egal was im Bereich JS passiert. Insofern ist das für mich ein gravierender Nachteil.

Javascript     CSS    Link sichtbar  Sinnvoll

aus            an     nein            ja
 an             an     ja              ja
 aus            aus    ja              nein
 an             aus    ja              nein

Die letzen beiden Fälle sind es, von denen ich rede.

Ich weiß nicht, was das mit einer (unrealistischen) Einstellung des Screenreaders "JS unterstützt/an aber CSS aus", von der du redest, zu tun haben soll.

Stur lächeln und winken, Männer!
Kai

[molily]

Also wird bei fehlender CSS-Fähigkeit der Link angezeigt, egal was im Bereich JS passiert.

Ah, jetzt, ja. Geschnallt. Klar, da hilft aktiviertes JavaScript nicht weiter.

Ich weiß nicht, was das mit einer (unrealistischen) Einstellung des Screenreaders "JS unterstützt/an aber CSS aus", von der du redest, zu tun haben soll.

Du hattest Screenreader in Verbindung mit »CSS abgeschaltet« gebracht. Keine Ahnung, warum. Vielleicht um mich zu verwirren. ;)

Mathias

[Sebastian Goertz]

Hallo,

vielen Dank alle zusammen. Die Diskussion sowie die darin verlinkten Archiv-Einträge haben mich schon sehr viel weiter gebracht.

Ich denke, ich werde noch 2 Runden JS lernen und dann den für mich nur logischen Weg gehen, dass alles, was mit JS-Funktionalität zu tun hat, eben auch nur mit JS gelöst wird.
Also nichts von wegen Links mit CSS ausblenden und per JS ändern, sondern dann auch überhaupt erst mit JS einfügen.
Das Ausführen der Funktion soll dann mit addEvent passieren und <a href="javascript:;">Click mich</a> wirkt sehr harmonisch auf mich :)

Viele Grüße,
Sebastian

[Der Martin]

Hi,

Das Ausführen der Funktion soll dann mit addEvent passieren und <a href="javascript:;">Click mich</a> wirkt sehr harmonisch auf mich :)

wenn sichergestellt ist, dass dieser Pseudo-Link nur im DOM steht, wenn Javascript ausgeführt wird, ist das okay. Ansonsten ist das vor allem mit einigen älteren Browsern sehr unangenehm (falls das für dich ein Kriterium ist).

Beispielsweise reagiert ein IE6 mit deaktiviertem JS beim Klick auf einen solchen Link mit dem Anzeigen der Eieruhr am Mauszeiger und einer nicht mehr enden wollenden Ladefortschrittsanzeige; ältere Operas zeigen ein Meldungsfenster mit dem Text "Nicht unterstützter Adresstyp javascript:".

So long,
 Martin

[Sebastian Goertz]

Hallo,

wenn sichergestellt ist, dass dieser Pseudo-Link nur im DOM steht, wenn Javascript ausgeführt wird, ist das okay.

Davon möchte ich ausgehen, wenn ich ihn überhaupt erst mit JS einfüge.

Ansonsten ist das vor allem mit einigen älteren Browsern sehr unangenehm (falls das für dich ein Kriterium ist).

Ist das nicht immer ein Kriterium!? ;-)

Viele Grüße,
Sebastian

[Der Martin]

Hallo Sebastian,

Ansonsten ist das vor allem mit einigen älteren Browsern sehr unangenehm (falls das für dich ein Kriterium ist).
Ist das nicht immer ein Kriterium!? ;-)

für manche nicht - viele sind nicht bereit, Browserversionen zu berücksichtigen, die älter als zwei bis drei Releases sind. Ich finde das zwar nicht okay, kann es aber akzeptieren, wenn der Aufwand unangemessen hoch wäre.
Voraussetzung ist für mich aber, dass man auch Steinzeitbrowser noch soweit unterstützt, dass die Seite lesbar und benutzbar bleibt (meinetwegen komplett ohne CSS und in Schwarzweiß) und nicht die Auslieferung der Inhalte mit der blöden Ausrede verweigert "Sie benutzen einen nicht unterstützten Browser".

So long,
 Martin

[Gunnar Bittersmann]

@@Der Martin:

nuqneH

Steinzeitbrowser […] (meinetwegen […] in Schwarzweiß)

[x] Done ;-)

Qapla'