Methode um Fokussierung auf Element aufzuheben?

[var]

Hallo miteinander.

In dem Browser-WebGL-Editor den ich gerade schreibe gibt es scrollbare Menülisten sowie natürlich den WebGLRenderingContext. Zur Skalierung und Bewegung der 3D-Objekte im WebGLContext sowie generell zum alternativen Aufruf von Programmfunktionen benutze ich verschiedene Tasten auf der Tastatur. Da liegt das Problem.

Wenn ich per Mausclick aus einer der Menülisten eine Funktion aufrufe, hat das Menü nach dem Click noch solange Fokus, bis ich mit der Maus woanders hinclicke. Wenn ich das dann aber nicht mache, sondern im natürlichen Bedienungsablauf entweder mit den Tasten 'Bild hoch' / 'Bild runter' oder den Tasten 'Pfeil hoch' / 'Pfeil runter' meinen WebGLContext steuere, dann scrollt das zuvor ausgewählte Menü parallel zur eigentlichen Action hoch und runter! ;)

Die Frage daher, gibt es eine Methode, die ich an die Events 'keyup', 'mouseup' und 'mouseout' anknüpfen kann, um den Fokus von einem Element automatisch zu lösen?

Gruß.

var

formerly known as Roadster

[ChrisB]

Hi,

Die Frage daher, gibt es eine Methode, die ich an die Events 'keyup', 'mouseup' und 'mouseout' anknüpfen kann, um den Fokus von einem Element automatisch zu lösen?

http://de.selfhtml.org/javascript/objekte/elements.htm#blur

MfG ChrisB

[Matthias Apsel]

Om nah hoo pez nyeetz, ChrisB!

http://de.selfhtml.org/javascript/objekte/elements.htm#blur

Gibts auch in der neuen Dokumentation: http://wiki.selfhtml.org/wiki/JavaScript/Objekte/DOM/document/forms/elements/blur

Matthias

[var]

Hi,

Hi

http://de.selfhtml.org/javascript/objekte/elements.htm#blur

Jep. Und die Elemente, bei denen das damit funktioniert, sind auch sowohl da als auch in dem von Matthias netterweise erwähnten Eintrag in der DOKU abschließend aufgezählt.

<li>, <ul>, <ol>, <section>, <nav> oder meinetwegen <div> habe ich da nicht gelesen. ;)

Ein scrollbares Menü!

<nav><ul><li></li></ul></nav>

Mit diesen Elemente funktioniert es leider nicht... Schon längst probiert. ;)

Vielleicht bin ich auch einfach zu blöd, dann möge man mich aufklären, aber ansonsten liegt darin doch ein gewisser Trost, dass ich nicht der einzige bin, der Fragepostings nicht immer so aufmerksam durchliest, wie eigentlich geboten. ;)

Trotzdem Danke für die Mühe.

Gruß.

var

[Matthias Apsel]

Om nah hoo pez nyeetz, var!

<nav><ul><li></li></ul></nav>

Mit diesen Elemente funktioniert es leider nicht... Schon längst probiert. ;)

Weil diese Elemente nicht automatisch den Focus bekommen können, du musst mit tabindex nachhelfen.

Ein scrollbares Menü!

Spannend sind für ein Menü aber doch die a-Elemente. Jene wiederum können auch ohne tabindex den Focus bekommen und verlieren ihn auch ganz von selbst wieder.

Matthias

[var]

Om nah hoo pez nyeetz, var!

Hallo Matthias

Weil diese Elemente nicht automatisch den Focus bekommen können, du musst mit tabindex nachhelfen.

Mir ist im Moment nicht ersichtlich, was es mir hinsichtlich _dieses_ spezifischen Problems bringen würde, meine listitems in einen tabindex einzufügen!? Dann könnte ich den Fokus durch Betätigung der Tabulatortaste lösen. Ich meine - lol - dann kann ich auch gleich mit der Maus irgendwo hinclicken! ;)

Spannend sind für ein Menü aber doch die a-Elemente. Jene wiederum können auch ohne tabindex den Focus bekommen und verlieren ihn auch ganz von selbst wieder.

Korrigier mich bitte, wenn ich falsch liege, aber ist für a-Elemente nicht zwingend ein href-Attribut vorgeschrieben? - Zugegeben, dass ich als umschließendes Elternelement <nav> gewählt habe, war wohl nicht 100% passend, denn die listitems verweisen (in der Regel) nicht auf andere Dokumente, sondern lösen zumeist nur in JavaScript Programmfunktionen für den WebGL-Editor aus...

Schien mir halt irgendwie naheliegend das in Form einer unordered list hinzusemmeln, aber wie sinnvoll soll es sein, dafür a-Elemente zweckzuentfremden?

Ich könnte soweit ich das im Moment überblicke höchstens irgendein Input-Feld auf der Seite nehmen und dann nach keyup/mouseup/mouseout beim Menü den Fokus auf dieses Feld setzen.

Das erscheint mir aber auch ziemlich zusammengeschustert...

Man sollte meinen, dass es da eine sauberere und elegantere Lösung gibt. :/

Gruß.

var

[Matthias Apsel]

Om nah hoo pez nyeetz, var!

Korrigier mich bitte, wenn ich falsch liege, aber ist für a-Elemente nicht zwingend ein href-Attribut vorgeschrieben?

Nein. Man kann z.B. bei a-Elementen auf die aktuelle Seite einfach das href-Attribut weglassen.

• Zugegeben, dass ich als umschließendes Elternelement <nav> gewählt habe, war wohl nicht 100% passend, denn die listitems verweisen (in der Regel) nicht auf andere Dokumente, sondern lösen zumeist nur in JavaScript Programmfunktionen für den WebGL-Editor aus...

Schien mir halt irgendwie naheliegend das in Form einer unordered list hinzusemmeln, aber wie sinnvoll soll es sein, dafür a-Elemente zweckzuentfremden?

Ich könnte soweit ich das im Moment überblicke höchstens irgendein Input-Feld auf der Seite nehmen und dann nach keyup/mouseup/mouseout beim Menü den Fokus auf dieses Feld setzen.

Das erscheint mir aber auch ziemlich zusammengeschustert...

Man sollte meinen, dass es da eine sauberere und elegantere Lösung gibt. :/

menu scheint mir dann das passende Element zu sein. Unterstützung ist mau, ich weiß auch nicht, ob bzw. wie html5shiv da hilft.

Matthias

[var]

Om nah hoo pez nyeetz, var!

Hallo Matthias

menu scheint mir dann das passende Element zu sein. Unterstützung ist mau, ich weiß auch nicht, ob bzw. wie html5shiv da hilft.

"Mau" ist noch untertrieben. ;)

Lustig ist dabei, dass bei meinen bisherigen Projekten das menu-Element sogar öfter die formal passendste Lösung gewesen wäre als das nav-Element.

Ich meine gerade in solchen Fällen wie meinem WebGL-Editor, wo es nicht um die (mehr oder weniger) reine Darstellung von Informationen geht, sondern um klassische (nur eben browserbasierende) Anwendungssoftware, wäre das echt eine extrem sinnvolle Sache.

Gruß.

var

[Gunnar Bittersmann]

@@Matthias Apsel:

nuqneH

Korrigier mich bitte, wenn ich falsch liege, aber ist für a-Elemente nicht zwingend ein href-Attribut vorgeschrieben?

Nein. Man kann z.B. bei a-Elementen auf die aktuelle Seite einfach das href-Attribut weglassen.

Dann sind sie (ohne tabindex) aber nicht fokussierbar.

Ein a-Element ohne href (oder mit unsinnigem href="#"), das eine Aktion auslösen soll, möchte liebend gern ein button-Element sein.

Qapla'

[Matthias Apsel]

Om nah hoo pez nyeetz, Gunnar Bittersmann!

Man kann z.B. bei a-Elementen auf die aktuelle Seite einfach das href-Attribut weglassen.

Dann sind sie (ohne tabindex) aber nicht fokussierbar.

Was ja sinnvoll ist, wenn es sich um Links[*] auf die aktuelle Seite handelt

Ein a-Element ohne href (oder mit unsinnigem href="#"), das eine Aktion auslösen soll, möchte liebend gern ein button-Element sein.

[*] Ein a-Element ohne href-Attribut ist kein Link. Mit allen erwünschten Wirkungen. Kein Fokus, kein Mauscursor in Form einer Hand.

Matthias

[Gunnar Bittersmann]

@@Matthias Apsel:

nuqneH

Man kann z.B. bei a-Elementen auf die aktuelle Seite einfach das href-Attribut weglassen.

Dann sind sie (ohne tabindex) aber nicht fokussierbar.

Was ja sinnvoll ist, wenn es sich um Links[*] auf die aktuelle Seite handelt
[*] Ein a-Element ohne href-Attribut ist kein Link. Mit allen erwünschten Wirkungen. Kein Fokus, kein Mauscursor in Form einer Hand.

Ja, natürlich. Aber ging’s hier nicht um sowas wie <a onclick="…"> (Eventhandler gern auch im JavaScript gesetzt)? Also um Elemente (Buttons!), die fokussierbar sein sollen und das ggfs. auch durch Änderung des Cursors visualisieren?

Qapla'

[var]

Hallo Gunnar

Also a hin oder her, hab es damit versucht, aber erfolglos: this.blur( ); oder target.blur( ); haben auch damit null Effekt: Das Menü scrollt bei Tastatureingabe munter weiter hoch und runter. Was interessant ist, ist dass ich den, nennen wir es mal Mausfokus, nicht durch Click auf das canvas lösen kann, sondern nur durch Click auf andere Elemente. Aber helfen tut diese Erkenntnis auch nicht. :/

Gruß.

var

[Matthias Apsel]

Om nah hoo pez nyeetz, var!

Also a hin oder her, hab es damit versucht, aber erfolglos:

Kannst du denn schon was zeigen?

Matthias

[var]

Om nah hoo pez nyeetz, var!

Hallo Matthias.

Kannst du denn schon was zeigen?

Naja, der Editor selbst hat noch zuviele Baustellen, aber um das Problem in Action zu sehen kannst du dir das hier ansehen.

Nur grob zusammengezimmert und ohne Funktionalität, aber zur Demonstration des Problems sollte es langen.

Kannst die Box mit den Pfeiltasten drehen und mit Bild hoch / Bild runter zoomen. Wenn du dann irgendeinen der toten Links im Menü anclickst und dann wieder die Tasten benutzt wirst du sehen, wie das Menü mitscrollt. Um den Focus aufzuheben musst du dann auf das 'Menü' DIV clicken. Dann scrollt nix mehr.

Glaube allerdings kaum, dass das irgendwie weiterhilft. Nutzt wahrscheinlich höchstens als abschreckendes Beispiel, wie unobtrusive JavaScript nicht aussieht. ;)

Gruß.

var

[var]

Ahoi.

Die Lösung des Problems heißt event.preventDefault( ) !!!

Einfach in der Keydown-Funktion vor der Funktionszuweisung notieren und dann scroll da nix mehr, was nicht scrollen soll!

Wusste doch, dass es dafür eine saubere und elegante Lösung geben muss... ;)

Trotzdem Dank an alle für ihre Mühre.

Gruß.

var

[ChrisB]

Hi,

Was interessant ist, ist dass ich den, nennen wir es mal Mausfokus, nicht durch Click auf das canvas lösen kann, sondern nur durch Click auf andere Elemente. Aber helfen tut diese Erkenntnis auch nicht.

Vielleicht kannst du, statt den Fokus mit .blur zu entfernen, ihn ja mit .focus auf eines dieser anderen Elemente setzen …?

MfG ChrisB

[var]

Hi,

Hi ChrisB

Vielleicht kannst du, statt den Fokus mit .blur zu entfernen, ihn ja mit .focus auf eines dieser anderen Elemente setzen …?

Hab ich schon ausprobiert. Solange es sich dabei nicht um Elemente handelt, die auch auf .blur( ) anspringen würden, funkt es nicht.

Dass das Menü überhaupt focus hat, ist wohl auch mal wieder auf gutgemeintes Browserbehavior zurückzuführen. So wie das fabelhafte feature, dass der Browser sich selbst nach einem reload eines documents die jeweiligen scroll-top und scroll-left positions 'merkt'. ;)

Wobei die Sinnhaftigkeit hier schwer zu beurteilen ist. Aus Browsersicht ist das scrollbare Menü nur ein beliebiges document.element mit scrollbarem overflow. Dass der usecase für focus mit dem click auf ein listitem vorerst nicht mehr gegeben ist, kann der Browser ja nicht wissen und in anderen Fällen kann das gleiche Verhalten durchaus sinnvoll sein.

Matthias hat aber recht. Ich werde mal ein kleines Demoprogramm erstellen und später posten. Vielleicht finden wir anhand eines live-Beispiels eine praktikable Lösung - oder verstehen das Problem wenigstens besser. ;)

Gruß.

var

[var]

Hey.

PS:

Was meinst du mit "nicht automatisch den focus bekommen können" ?

Wenn ich mit der Maus einen Menüpunkt anclicke, hat das Menü "focus".

Es erscheint zwar kein Heiligenschein um das Element, aber der Beweis ist leicht zu führen, denn wenn ich nach dem click auf das Menü auf ein anderes Element clicke, reagiert es nichtmehr auf Tastatureingaben.

Gruß.

var

[ChrisB]

Hi,

Vielleicht bin ich auch einfach zu blöd, dann möge man mich aufklären, aber ansonsten liegt darin doch ein gewisser Trost, dass ich nicht der einzige bin, der Fragepostings nicht immer so aufmerksam durchliest, wie eigentlich geboten. ;)

Deine originale Fragestellung kann man lesen so oft man will – konkrete Informationen findet man darin trotzdem nicht.

Bei technischen Problemen muss man oft schon ein bisschen Code oder wenigstens ein Live-Beispiel zeigen – Prosa allein tut’s da nicht immer.

MfG ChrisB