[JS] Event.KeyCode vervangen in moderne browsers

[PdeBie]

Heren/dames ontwikkelaars,

binnen onze webapplicatie is de wens om de werking van de <enter> toets te vervangen door de functionaliteit van de <tab> toets. Dit zodat de gebruiker met de <enter> toets door de textboxen kan 'skippen'.

"Vroeger" kon dit door middel van een stukje javascript, waarbij je de keyCode van het event overschreef tijdens het onKeyDown event. Dit ging als volgt:

JavaScript:

function enterToTab() {
    if (event.keyCode == 13) {
        event.keyCode = 9;
    }
}

waarbij je vervolgens deze functie aan een textbox koppelde d.m.v.

C:

TextBox1.Attributes["onkeydown"] = "enterToTab()";

Maar wat merk ik nu. Sinds IE9, FF4 en de laatste Google Chrome versies, werkt dit niet meer.

Ik heb wat google zoekwerk gedaan en daarbij kwam ik het volgende tegen:
http://help.dottoro.com/ljqqripa.php

The keyCode property is read-only in Firefox, Opera, Google Chrome and Safari, and it is read/write in Internet Explorer.

Echter in IE9 werkt het ook niet, tenzij ik deze in Compatibility mode draai. Dan werkt 't wel.

Iemand een idee om dit toch werkend te krijgen in de moderne browsers? De applicatie dient in IE (vanaf versie 7), FF (vanaf versie 3) en Chrome te werken.

[Voor 11% gewijzigd door PdeBie op 25-05-2011 14:55. Reden: note verwijderd]

[Joolee]

Wat je nu doet is:
- Event afvangen
- Eventproperties aanpassen
- Event door laten gaan

Waar je aan moet gaan denken is:
- Event afvangen
- Eigen event starten (tab sturen naar de browser of via een eigen javascriptje naar de volgende textbox)
- Originele event stoppen (return false)

[PdeBie]

Joolee schreef op woensdag 25 mei 2011 @ 13:39:
Waar je aan moet gaan denken is:
- Event afvangen
- Eigen event starten (tab sturen naar de browser of via een eigen javascriptje naar de volgende textbox)
- Originele event stoppen (return false)

Mja, dat had ik ook al bedacht. Maar de vraag 'hoe?' is hier eigenlijk meteen al van toepassing.
Ik kan helaas niet op basis van focus werken, omdat de velden dynamisch opgebouwd worden en daarnaast is mijn kennis van javascript te summier om zelf events te schrijven.

[RobIII]

Waar hoort mijn topic?
PRG >> WEB

[mocean]

pdebie schreef op woensdag 25 mei 2011 @ 15:19:
[...]


Mja, dat had ik ook al bedacht. Maar de vraag 'hoe?' is hier eigenlijk meteen al van toepassing.
Ik kan helaas niet op basis van focus werken, omdat de velden dynamisch opgebouwd worden en daarnaast is mijn kennis van javascript te summier om zelf events te schrijven.

Dan zal je het moeten leren, pseudo-code

code:

function enterToTab() { 
    if (event.keyCode == 13 || event.keyCode == 9) { 
         // Zoek huidige element op in DOM
         var obj = this.whereAmI();

         // Zoek volgende element in DOM
         var nextObj=obj.findNextFormElement();
         nextObj.focus();         
    } 
}

[TJHeuvel]

Volgens mij wil je helemaal niet de enter vervangen in een tab, maar wil je gewoon als er enter gedrukt wordt naar het volgende element.

Ik kan me voorstellen dat op sommige devices (mobiele telefoons?) de tab toets iets anders doet.

[OkkE]

offtopic:
Ik vind het over het algemeen heel onverstandig om standaard functies van de browser te gaan ombouwen. We hebben [TAB] waarom dan [enter] ook?

Het is sowieso goed om tabindex te gebruiken in je formulier. Die kan je in dit geval dan weer mooi gebruiken om de volgende input te selecteren.

[Bosmonster]

Het gebruik van tabindex is sterk af te raden vanuit accessibility-oogpunt, maar dat terzijde

(het is hooguit een lapmiddel om slechte formulieren nog enigszins navigeerbaar te maken)

[Voor 32% gewijzigd door Bosmonster op 25-05-2011 16:04]

[PdeBie]

mocean schreef op woensdag 25 mei 2011 @ 15:24:
[...]

Dan zal je het moeten leren, pseudo-code

code:

function enterToTab() { 
    if (event.keyCode == 13 || event.keyCode == 9) { 
         // Zoek huidige element op in DOM
         var obj = this.whereAmI();

         // Zoek volgende element in DOM
         var nextObj=obj.findNextFormElement();
         nextObj.focus();         
    } 
}

Ik zal inderdaad hier eens mee gaan spelen.

OkkE schreef op woensdag 25 mei 2011 @ 15:49:

offtopic:
Ik vind het over het algemeen heel onverstandig om standaard functies van de browser te gaan ombouwen. We hebben [TAB] waarom dan [enter] ook?

Eens, maar het is nou eenmaal een requirement die ze gesteld hebben.
De huidige applicatie is namelijk een winapplicatie waarin de gebruikers deze functionaliteit ook hebben. En daarom moet het ook in de nieuwe versie (de huidige webapplicatie die ik aan het bouwen ben) komen.

[Voor 10% gewijzigd door PdeBie op 25-05-2011 16:07]

[OkkE]

Bosmonster schreef op woensdag 25 mei 2011 @ 16:02:
Het gebruik van tabindex is sterk af te raden vanuit accessibility-oogpunt, maar dat terzijde

(het is hooguit een lapmiddel om slechte formulieren nog enigszins navigeerbaar te maken)

Hangt er denk ik vanaf hoe je het toepast. Ik geef toe dat tabindex niet nodig is en vaak zelfs weggelaten kan worden. Maar om te zeggen dat ze per definitie slecht zijn, dat zie ik niet direct?

Bosmonster schreef op woensdag 25 mei 2011 @ 16:24:
Dat zal voornamelijk liggen in het feit dat je ze nooit nodig hebt dus

Denk 't. Maar, het klopt inderdaad dat je een hoop kunt verpesten met verkeerde tabindex.

[Voor 22% gewijzigd door OkkE op 25-05-2011 16:32]

[Davio]

Nou ja, je moet met je tabindex niet heel erg gaan rommelen zodat gebruikers van het bovenste naar het onderste veld springen en weer terug etc...

Je kan misschien beter fieldset gebruiken om controls te groeperen, tenzij dat alweer uit is natuurlijk...

[Bosmonster]

Dat zal voornamelijk liggen in het feit dat je ze nooit nodig hebt dus

En als je ze wel toepast het meestal meer standaardfunctionaliteit (of accessibility-functionaliteit) breekt dan goedmaakt.

@Davio fieldsets zijn praktisch verplicht, zal wel even duren voordat dat uit de gratie is Hoort gewoon bij standaard formulier-opmaak, net als legend, labels, etc.

[Voor 12% gewijzigd door Bosmonster op 25-05-2011 16:25]

[_Thanatos_]

Maar wat merk ik nu. Sinds IE9, FF4 en de laatste Google Chrome versies, werkt dit niet meer.

For good reason. Het is standaardgedrag OVERAL in windows en andere OSsen, het is vreselijk slecht om dit te gaan veranderen. De reden dat ze het zo willen is wrs dat de gebruikers bij de klant "gewend" zijn aan een of ander draconisch systeem dat 814 jaar geleden zo gemaakt is. Nieuwe medewerkers hebben dit probleem niet, en daarbij: een nieuw systeem werkt nou eenmaal anders, anders kun je net zo goed een oud systeem behouden.

JavaScript:

function enterToTab() {
  if (event.keyCode == 13 || event.keyCode == 9) {
    //...

Dit is erg slecht, omdat het alléén in IE zal werken. Op andere browsers doet het niets (of zou het niets moeten doen) omdat event een ongedeclareerde variabele is, en daarmee een implied global met undefined als "waarde". In gehoorzame browsers is het event het eerste argument van de event-handler.

MAAR

C:

TextBox1.Attributes["onkeydown"] = "enterToTab()";

Dan doe je dat. Omg. Dit lijkt op backend-code en ik hoop voor de rest van de wereld dat dat zo is. Maar dit levert op:

HTML:

<input type="text" onkeydown="enterToTab()"/>

Javascript in je HTML*, een global function*, en een verkapte eval()* all-in-frakking-one. En geen manier om aan je event-object te komen in de handler.

De goeie manier is:

JavaScript:

document.getElementById("textbox1").keydown = function(e) {
  e = e || window.event;
  //Doe je ding met e.keyCode
  e.keyCode = 32;
  e.returnValue = 32;
  return 32;
};

Je doet er echter goed aan om een framework à la jQuery te gebruiken. Een hoop rariteiten (m.n. in event-spul) worden genormaliseerd en gaan op alle browsers hetzelfde werken:

JavaScript:

$("#textbox1").bind("keydown", function(e) {
  //Doe je ding met e.keyCode
  return 32;
});

_{Niet getest natuurlijk, maar ik verwacht dat het zo makkelijk is.
*) Je hoort te weten waarom deze dingen slecht zijn. Weet je dit niet, dan ga je dat als de wiedeweerga leren}

[Gomez12]

_Thanatos_ schreef op donderdag 26 mei 2011 @ 00:33:
[...]
For good reason. Het is standaardgedrag OVERAL in windows en andere OSsen, het is vreselijk slecht om dit te gaan veranderen. De reden dat ze het zo willen is wrs dat de gebruikers bij de klant "gewend" zijn aan een of ander draconisch systeem dat 814 jaar geleden zo gemaakt is. Nieuwe medewerkers hebben dit probleem niet, en daarbij: een nieuw systeem werkt nou eenmaal anders, anders kun je net zo goed een oud systeem behouden.

Tja, je zal toch eens een concessie doen vanwege de vraag van de klant, dat is uiteraard ondenkbaar. Wat denkt die klant wel? Jij bepaalt de requirements wel even, het enige wat de klant moet doen is de rekening betalen en zijn klep houden... (Op deze manier ongeveer jouw instelling goed weergegeven?)

Je doet er echter goed aan om een framework à la jQuery te gebruiken. Een hoop rariteiten (m.n. in event-spul) worden genormaliseerd en gaan op alle browsers hetzelfde werken:

Zonder verdere achtergrondinfo is dit gewoon pure waanzin. Waarom zou je een hele jQuery library meesjouwen als je enkel maar 1 dingetje wilt hebben.

_{*) Je hoort te weten waarom deze dingen slecht zijn. Weet je dit niet, dan ga je dat als de wiedeweerga leren}

Welkom in de echte wereld waar er geen echt absoluut slechte / goede dingen zijn.

[_Thanatos_]

Tja, je zal toch eens een concessie doen vanwege de vraag van de klant, dat is uiteraard ondenkbaar. Wat denkt die klant wel? Jij bepaalt de requirements wel even, het enige wat de klant moet doen is de rekening betalen en zijn klep houden... (Op deze manier ongeveer jouw instelling goed weergegeven?)

Nee, maar de klant heeft niet altijd gelijk. Het is aan jouw (ons) om de klant uit te leggen dat het echt een slecht idee is. De klant heeft gewoon een bepaald probleem en wil daarvoor een oplossing. Het is aan ons om de oplossing te zoeken, niet aan de klant. Een gouden regel die ik geleerd heb, is om 5x na elkaar een waarom-vraag te stellen (met een goed antwoord erop) om tot de bron te komen waarvoor een oplossing moet komen. Soms kom je dan op iets heel anders uit, waar de klant nog blij mee is ook.

Doen wat de klant opdraagt is niet altijd hetzelfde als de klant blij maken. En dingen maken waar je niet achter staat is ook slecht voor je portfolio.

Zonder verdere achtergrondinfo is dit gewoon pure waanzin. Waarom zou je een hele jQuery library meesjouwen als je enkel maar 1 dingetje wilt hebben.

Is het maar 1 "dingetje" dan? Me dunkt dat het een applicatie is waar veel meer (draconische) code in hangt die de verbeteringen van jQuery (of een ander modern framework) kan gebruiken.

Welkom in de echte wereld waar er geen echt absoluut slechte / goede dingen zijn.

Dankje De meeste dingen zijn inderdaad niet pure evil of pure goodness, maar helaas bestaat er in javascript wel bijzonder veel bad practice.

[Voor 14% gewijzigd door _Thanatos_ op 26-05-2011 18:03]

[PdeBie]

Ik heb mijn werkgever (die hier als klant dient) geprobeerd over te halen de functionaliteit niet in te bouwen, maar hij houdt voet bij stuk en wilt dat de Enter toets als Tab dient, omdat de eindgebruikers dit nu eenmaal gewend zijn. Ze werken nu ruim 10 jaar met een applicatie waar dit zo in werkt en het pc-kennis niveau van de eindgebruikers is vergelijkbaar met de 'beweeg de muis naar rechterbovenhoek'-reclame. Vandaar de keuze

En over je reactie about mijn code. Waarom geen js-functie toekennen in een attribuut van een html item? Wat is er mis mee? (stuur het me desnoods per prive bericht, zodat we die discussie gescheiden kunnen houden van dit topic).

Verders wil ik aangeven dat ik inmiddels al een oplossing heb gevonden/bedacht. (gedeeltelijk thanks to google).

JavaScript:

function pageLoad() {        
        enterToTab();
}

function enterToTab() {
    $("input").not($(":button")).keypress(function (evt) {
        if (evt.keyCode == 13) {
            iname = $(this).val();
            if (iname !== 'Submit') {
                var fields = $(this).parents('form:eq(0),body').find('button, input, textarea, select');
                var index = fields.index(this);
                if (index > -1 && (index + 1) < fields.length) {
                    fields.eq(index + 1).focus();
                }
                return false;
            }
            return false;
        }
    });
}

Keurig opgelost middels JQuery in plaats van mijn vorige methode. Happy?
Ik wel in ieder geval, want 't werkt als een tierelier.

[Voor 0% gewijzigd door PdeBie op 31-05-2011 08:56. Reden: Typo's]

[R4gnax]

pdebie schreef op maandag 30 mei 2011 @ 15:25:
Keurig opgelost middels JQuery in plaats van mijn vorige methode. Happy?
Ik wel in ieder geval, want 't werkt als een tierelier.

Laat 'keurig' maar achterwege. Zo gebruik je niet de correcte manier om het basis gedrag van een event te stoppen, heb je selectors die nodeloos complex zijn (nl. "form:eq(0)" in een parents selectie, terwijl forms niet genest mogen zijn) en zit er een gehackte oplossing in om met submit buttons om te gaan. Deze werkt niet eens correct, want: wat gebeurt er met een tekstvak waar de gebruiker 'Submit' als tekst opgegeven heeft en dan met de enter toets bevestigt?

Een oplossing ongeveer als het volgende is dan al stukken beter.

JavaScript:

$( document ).ready( function() {

    // Bind the event to a useful subset of input elements. 
    $( "input, select" )
        .not( ":button, :submit, :image, :file" )
        .bind( "keypress", function ( event ) {
            var fields, index, scope;
            
            if ( event.keyCode !== 13 ) { return; }
            
            // Go up the DOM scope in steps. Start with any enclosing fieldsets.
            // If this yields no successor, try from an enclosing form tag. If this
            // yields no results either, try from the document body directly.           
            scope = $( this ).parent().closest( "fieldset, form, body" );
            while ( scope.length !== 0 ) {
                
                fields = scope.find( ":input" );        
                index = fields.index( this );
            
                // Check if this is not the last input element in the scope.
                // This check is safe, as index will never be < 0. An element
                // is guaranteed to be present as a descendant of one of its
                // ancestors.
                if ( index < fields.length - 1 ) {

                    // Set the new focus, stop the default behaviour of the
                    // key press and exit the event handler.
                    fields.eq( index + 1 ).focus();
                    event.preventDefault();
                    return;
                }
                
                scope = scope.parent().closest( "fieldset, form, body" )
            }
            
            // Fields will still contain the result for the body level's
            // search for valid input elements. If no successor can be
            // found, select the first input element as a 'wrap around'.
            fields.first().focus();
        }
    });
});

[PdeBie]

R4gnax schreef op maandag 30 mei 2011 @ 17:21:
[...]

Laat 'keurig' maar achterwege. Zo gebruik je niet de correcte manier om het basis gedrag van een event te stoppen, heb je selectors die nodeloos complex zijn (nl. "form:eq(0)" in een parents selectie, terwijl forms niet genest mogen zijn) en zit er een gehackte oplossing in om met submit buttons om te gaan.

Excusez moi for being a newbie in jquery.

Dat submit verhaal van die textbox heb ik er meteen uitgesloopt, want dat was best een domme bug
Wilde checken of het geen 'submit' control was, maar dat moet dus anders middels .not( ":submit") zoals jij aangaf in je voorbeeld.
Echter ben ik met jouw voorbeeld ook al weer ergens tegenaan gelopen wat ik eerst nog moet oplossen. (heeft te maken met velden die niet op enabled staan). Anyway thanks voor je comments. Ik ga m'n code nog eens herzien

(tevens nogmaals aangekaart bij hogerop dat ik de gewenste functionaliteit zinloos vind
maar dat terzijde. )

[Voor 5% gewijzigd door PdeBie op 03-06-2011 10:30]

[R4gnax]

pdebie schreef op vrijdag 03 juni 2011 @ 10:29:
Excusez moi for being a newbie in jquery.

Geen probleem. Je moet tenslotte ergens beginnen.

pdebie schreef op vrijdag 03 juni 2011 @ 10:29:
Echter ben ik met jouw voorbeeld ook al weer ergens tegenaan gelopen wat ik eerst nog moet oplossen. (heeft te maken met velden die niet op enabled staan). Anyway thanks voor je comments. Ik ga m'n code nog eens herzien

Ah. Ik wist niet dat je ook met uitgeschakelde form elementen aan het werk moest. In dat geval kun je het eens proberen met een extra filter op regel 17 v/h voorgaande script.

JavaScript:

fields = scope.find( ":input" ).filter(function(){ return !this.disabled; });

pdebie schreef op vrijdag 03 juni 2011 @ 10:29:
(tevens nogmaals aangekaart bij hogerop dat ik de gewenste functionaliteit zinloos vind
maar dat terzijde. )

Ik ken dat gevoel van vechten tegen de bierkaai. Wat ik aan zou raden is om dit stukje script er gewoon op zo'n manier in te steken dat het later ook weer makkelijk weg te halen is en dan gewoon te wachten op de reacties v/d klant. Je kunt het dan altijd makkelijk er weer uit halen. Zorg trouwens wel dat je jouw reeds uitgesproken advies en de reactie daarop nog ergens traceerbaar hebt, dan kan jou later ook niets verweten worden.