Dear all,
I think this can be interesting for others too. For a while I tried to
solve that problem - how to tabulate with ENTER/RETURN key too and not
only with TAB.
You know the problem - you are entering a lot of numbers from numeric
keypad but you need to go far left to press TAB. This prevents one-hand
data entry and prohibits web apps to be used by accountants, for instance.
Here is a solution I managed to do so far:
<input type="text" id="id1" name="field1"
value="">
<script type="text/javascript">
Event.observe(''id1'', ''keypress'',
function(event) {
if (event.keyCode == Event.KEY_RETURN) {
Event.stop(event); $(''id2'').focus();
$(''id2'').select(); }});
</script>
<input type="text" id="id2" name="field2"
value="">
On first input field an event observer catches RETURN keypress, stops
event and focuses on a second input field.
As you can see, this is obviously not yet an ideal solution, because we
must know on which element tabulate next. It would be much nicer to just
replace KEY_RETURN with KEY_TAB event. Anyone knows, how to do that? I
tried with event.keyCode = Event.KEY_TAB, but unsuccessfully:
<input type="text" id="id1" name="field1"
value="">
<script type="text/javascript">
Event.observe(''id1'', ''keypress'',
function(event) {
if (event.keyCode == Event.KEY_RETURN) {
event.keyCode = Event.KEY_TAB }});
</script>
Any idea appreciable!
Best regards
Janko
--
Janko Mivek
AIDA/Web
Smalltalk Web Application Server
http://www.aidaweb.si
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---
Hey Janko,
If you''re fully in control of your HTML, you can leverage the tabindex
attribute, and create a generic handler, something like:
<form id="inputForm"...>
...
<input type="text"... tabindex="1" />
...
<input type="text"... tabindex="2" />
...
</form>
And then in your JS (untested, but should work):
function grabEnterAndTabOver(e) {
var elt = Event.element(e);
if (elt.tagName != ''INPUT'' || elt.type !=
''text'')
return;
var ti = elt.tabIndex;
var elts = $$(''#inputForm input[tabindex='' + (ti + 1) +
'']'');
if (elts.length > 0) {
Event.stop(e);
elts.first().activate();
}
} // grabEnterAndTabOver
Event.observe(''inputForm'', ''keypress'',
grabEnterAndTabOver);
This reacts to Return to tab to the next (tabindex-wise) element in the
form, then goes to it. If you can''t find the tabindex you''re
looking
for, you leave the Return key to its default processing.
You can make it generic by using $(elt).up(''form'').id to grab
the parent
form''s ID, or even by not using $$ but using this on the so-obtained
form reference:
getInputs(''text'').find(function(elt) {
return elt.tabIndex == ti + 1; });
There are many ways... The point is: tabindex is there to define
specific tab navigation rules, so leverage it!
--
Christophe Porteneuve a.k.a. TDD
"[They] did not know it was impossible, so they did it." --Mark Twain
Email: tdd-x+CfDp/qHev2eFz/2MeuCQ@public.gmane.org
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Janko Mivek wrote:> It would be much nicer to just replace KEY_RETURN with KEY_TAB event. > Anyone knows, how to do that? I tried with event.keyCode = Event.KEY_TABYeah, in an ideal world this would be sweet ;-) As you may already know, according to W3C DOM2, there is no standard regarding Keyboard Events [1]. Still, we have the 1999 working draft [2] which at least provided some kind of specs which - at various levels - are implemented in current browsers. But then again, nobody says those attributes (like "keyCode") are "read-only" or not. Confusing, isn''t it? ;-) Until then... follow TDD''s solution, sounds like a good workaround (portable) even if I anticipate a nightmare when you''ll want to apply this to dynamically generated forms :)) If you feel like experimenting, you could try implementing a Gecko only solution, as they already implemented [3] the DOM3 Keyboard Events module "specs" [4] (yes, quotes are significant as in fact "[4]" is merely a "working group note") :( Anyway, I''ve been there some years ago and AFAIR I wasn''t able to do much with that, because of various security issues (IIRC it worked only when in "chrome"). If you''re luckier, please come back with your results, I''d be interested to hear about your findings, even if they were Gecko-only. On a side note, IIRC there were various issues regarding "keyboard events stealing" with every browser around.... maybe they could come handy too in your introspection ;-) [1] http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-eventgroupings-keyevents [2] http://www.w3.org/TR/1999/WD-DOM-Level-2-19990304/events.html#Level-2-Events-interfaces [3] http://lxr.mozilla.org/mozilla/source/dom/public/idl/events/nsIDOMKeyEvent.idl [4] http://www.w3.org/TR/2003/NOTE-DOM-Level-3-Events-20031107/events.html#Events-KeyboardEvent - -- Marius Feraru -----BEGIN PGP SIGNATURE----- iD8DBQFF2KpNtZHp/AYZiNkRAoHDAJ9MrSfAxtqNd5rx99E4D5JY4zSzwACbBz2N kDa1FwkZ8t9Fi53BBd4UrSY=MfPG -----END PGP SIGNATURE----- --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
Hi Cristophe, Thank you for that trick! As beginner in JavaScript didn''t know that I can use tabIndex from JS to find a next element to tab into. Anyway, because I have control on tabulation order on server I decided to let the server write a script to tab into a right next element. This is still better because I think have more control on tabulation than from JS. Best regards Janko Christophe Porteneuve wrote:> Hey Janko, > > If you''re fully in control of your HTML, you can leverage the tabindex > attribute, and create a generic handler, something like: > > <form id="inputForm"...> > ... > <input type="text"... tabindex="1" /> > ... > <input type="text"... tabindex="2" /> > ... > </form> > > And then in your JS (untested, but should work): > > function grabEnterAndTabOver(e) { > var elt = Event.element(e); > if (elt.tagName != ''INPUT'' || elt.type != ''text'') > return; > var ti = elt.tabIndex; > var elts = $$(''#inputForm input[tabindex='' + (ti + 1) + '']''); > if (elts.length > 0) { > Event.stop(e); > elts.first().activate(); > } > } // grabEnterAndTabOver > > Event.observe(''inputForm'', ''keypress'', grabEnterAndTabOver); > > This reacts to Return to tab to the next (tabindex-wise) element in the > form, then goes to it. If you can''t find the tabindex you''re looking > for, you leave the Return key to its default processing. > > You can make it generic by using $(elt).up(''form'').id to grab the parent > form''s ID, or even by not using $$ but using this on the so-obtained > form reference: > > getInputs(''text'').find(function(elt) { > return elt.tabIndex == ti + 1; }); > > There are many ways... The point is: tabindex is there to define > specific tab navigation rules, so leverage it! >-- Janko Mivek AIDA/Web Smalltalk Web Application Server http://www.aidaweb.si --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
Hi Marius, So I was a bit too naive to expect a simple solution for that problem! Anyway, because of my limited JS knowledge I decided not to go deeper and rather let the server to compose a JS for tabulation. So far it works well and for me a problem is solved. But still .. :) Thanks and best regards Janko Marius Feraru wrote:> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Janko Miv�ek wrote: >> It would be much nicer to just replace KEY_RETURN with KEY_TAB event. >> Anyone knows, how to do that? I tried with event.keyCode = Event.KEY_TAB > Yeah, in an ideal world this would be sweet ;-) > > As you may already know, according to W3C DOM2, there is no standard > regarding Keyboard Events [1]. > Still, we have the 1999 working draft [2] which at least provided some kind > of specs which - at various levels - are implemented in current browsers. > But then again, nobody says those attributes (like "keyCode") are > "read-only" or not. Confusing, isn''t it? ;-) > > Until then... follow TDD''s solution, sounds like a good workaround > (portable) even if I anticipate a nightmare when you''ll want to apply this > to dynamically generated forms :)) > > If you feel like experimenting, you could try implementing a Gecko only > solution, as they already implemented [3] the DOM3 Keyboard Events module > "specs" [4] (yes, quotes are significant as in fact "[4]" is merely a > "working group note") :( > Anyway, I''ve been there some years ago and AFAIR I wasn''t able to do much > with that, because of various security issues (IIRC it worked only when in > "chrome"). > If you''re luckier, please come back with your results, I''d be interested to > hear about your findings, even if they were Gecko-only. > > On a side note, IIRC there were various issues regarding "keyboard events > stealing" with every browser around.... maybe they could come handy too in > your introspection ;-) > > [1] > http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-eventgroupings-keyevents > [2] > http://www.w3.org/TR/1999/WD-DOM-Level-2-19990304/events.html#Level-2-Events-interfaces > [3] > http://lxr.mozilla.org/mozilla/source/dom/public/idl/events/nsIDOMKeyEvent.idl > [4] > http://www.w3.org/TR/2003/NOTE-DOM-Level-3-Events-20031107/events.html#Events-KeyboardEvent > > - -- > Marius Feraru > -----BEGIN PGP SIGNATURE----- > > iD8DBQFF2KpNtZHp/AYZiNkRAoHDAJ9MrSfAxtqNd5rx99E4D5JY4zSzwACbBz2N > kDa1FwkZ8t9Fi53BBd4UrSY> =MfPG > -----END PGP SIGNATURE----- > > > >-- Janko Miv�ek Svetovalec za informatiko Eranova d.o.o. Ljubljana, Slovenija www.eranova.si tel: 01 514 22 55 faks: 01 514 22 56 gsm: 031 674 565 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
Hey Janko, Janko Mivek a écrit :> Anyway, because I have control on tabulation order on server I decided > to let the server write a script to tab into a right next element. This > is still better because I think have more control on tabulation than > from JS.I have *no idea* what you mean. Tabulation is obviously a UI issue, hence client-side. What the server side could do for you, I can''t begin to guess. I only suggested the server side makes sure tab-accessible form elements are provided with appropriate tabindex= attributes, so that the client-side script could use them to tab on Return keys. -- Christophe Porteneuve aka TDD tdd-x+CfDp/qHev2eFz/2MeuCQ@public.gmane.org --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
This is only set up to work in FF, and only tested in FF2, but it will
auto-tab to the next input field. It may need some more work if you''re
doing
more deeply nested elements(ie, you may want to use some root element
instead of element.parentNode), but it should be a decent starting point.
-Jerod
<html>
<head>
<script type="text/javascript">
function enter(e, element) {
if(e && e.keyCode == 13) {
var inputs = element.parentNode.getElementsByTagName("input");
var next = null;
for(var i=0;i<inputs.length-1;i++){ //-1 is so we don''t
focus past
the end of the list
if(inputs[i] == element){
next = inputs[i+1];
}
}
next.select();
next.focus();
return false;
}
else
{
return true;
}
}
</script>
</head>
<body>
<form action="http://www.cs.tut.fi/cgi-bin/run/~jkorpela/echo.cgi"
name="demo">
<input type="hidden" name="hiddenfield"
value="42">
Field 1: <input type="text" name="field1"
id="_field1" onkeydown="return
enter(event,this)"><br>
Field 2: <input type="text" name="field2"
id="_field2" onkeydown="return
enter(event,this)"><br>
<input type="submit" name="send">
</form>
</body>
</html>
On 2/19/07, Christophe Porteneuve
<tdd-x+CfDp/qHev2eFz/2MeuCQ@public.gmane.org>
wrote:>
>
> Hey Janko,
>
> Janko Mivek a écrit :
> > Anyway, because I have control on tabulation order on server I decided
> > to let the server write a script to tab into a right next element.
This
> > is still better because I think have more control on tabulation than
> > from JS.
>
> I have *no idea* what you mean. Tabulation is obviously a UI issue,
> hence client-side. What the server side could do for you, I can''t
begin
> to guess.
>
> I only suggested the server side makes sure tab-accessible form elements
> are provided with appropriate tabindex= attributes, so that the
> client-side script could use them to tab on Return keys.
>
> --
> Christophe Porteneuve aka TDD
> tdd-x+CfDp/qHev2eFz/2MeuCQ@public.gmane.org
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---
Hey Jerod, Jerod Venema a écrit :> This is only set up to work in FF, and only tested in FF2, but it will > auto-tab to the next input field. It may need some more work if you''reActually it won''t in a valid strict HTML document: form fields are not usable directly in the <form> element, they must be in a regular sort of container (e.g. <p>). So relying on parentNode won''t work. It also superbly ignores tabindex attributes, if defined. More generally, it ignores everything Prototype, so it''s not cross-browser (your using inline DOM-Level-0 event attributes will not work in IE, since the event object won''t be passed), and it''s still a lot of code. I appreciate your effort in trying to help, but since this is a Spinoffs group, and there was a valid Spinoffs solution posted, you may want to provide a Spinoffs-based, if possible cross-browser, solution :-) -- Christophe Porteneuve aka TDD tdd-x+CfDp/qHev2eFz/2MeuCQ@public.gmane.org --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
Uh...sorry? I wasn''t trying to post a complete solution here, just a thought as to how you could go about auto-tabbing via the enter key without relying on tab indexes. I never said it would validate, I suggested that the parentNode would probably need to go, and said it was only FF compatible. It was an idea, not a working solution. And ideas should ALWAYS be welcome in a developers forum. -Jerod On 2/19/07, Christophe Porteneuve <tdd-x+CfDp/qHev2eFz/2MeuCQ@public.gmane.org> wrote:> > > Hey Jerod, > > Jerod Venema a écrit : > > This is only set up to work in FF, and only tested in FF2, but it will > > auto-tab to the next input field. It may need some more work if you''re > > Actually it won''t in a valid strict HTML document: form fields are not > usable directly in the <form> element, they must be in a regular sort of > container (e.g. <p>). So relying on parentNode won''t work. > > It also superbly ignores tabindex attributes, if defined. More > generally, it ignores everything Prototype, so it''s not cross-browser > (your using inline DOM-Level-0 event attributes will not work in IE, > since the event object won''t be passed), and it''s still a lot of code. > > I appreciate your effort in trying to help, but since this is a Spinoffs > group, and there was a valid Spinoffs solution posted, you may want to > provide a Spinoffs-based, if possible cross-browser, solution :-) > > -- > Christophe Porteneuve aka TDD > tdd-x+CfDp/qHev2eFz/2MeuCQ@public.gmane.org > > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
Hey Jerod, I''m sorry if you felt bruised by my reply, I may have needed to word it more carefully. Ideas are indeed welcome (if you look at the archives, you''ll probably acknowledge this), but when they do not provide enough of a solution, or when it is improvable, it should be pointed out. On your side, you may have wanted to finetune your solution for better practices before posting a reply; there was no rush; other solutions were already there, and the OP mentioned he was going to go with tabindexes (which is good from an accessibility standpoint, BTW). Also, I believe my Spinoffs-related remark stands: considering this group is about Prototype and script.aculo.us, you should try to provide a solution that leverages what''s useful in these (case in point, Prototype). In another context, I would have provided a patched version of your solution, but since other solutions were already posted, I didn''t feel the need. I''m sorry, again, that you felt chastised. It certainly wasn''t my intention. Any good will is welcome here, but we should all strive to post code that leverages as much best practice and Prototypishness as possible. Sincerely, -- Christophe Porteneuve aka TDD tdd-x+CfDp/qHev2eFz/2MeuCQ@public.gmane.org --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
Bon jour Cristophe, Christophe Porteneuve wrote:> Hey Janko, > > Janko Mivek a écrit : >> Anyway, because I have control on tabulation order on server I decided >> to let the server write a script to tab into a right next element. This >> is still better because I think have more control on tabulation than >> from JS. > > I have *no idea* what you mean. Tabulation is obviously a UI issue, > hence client-side. What the server side could do for you, I can''t begin > to guess.Tabulation can be simulated by adding scripts like one in my first post. That''s what I meant with a server tabulation. Other possibility is to find a next element to tab into, from a DOM tree directly as Marius and Jerod suggested. For now, I''m satisfied using server tabulation but I can switch to DOM assisted one in the future. Cordialement Janko> I only suggested the server side makes sure tab-accessible form elements > are provided with appropriate tabindex= attributes, so that the > client-side script could use them to tab on Return keys. >-- Janko Mivek AIDA/Web Smalltalk Web Application Server http://www.aidaweb.si --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
On 2/19/07, Christophe Porteneuve <tdd-x+CfDp/qHev2eFz/2MeuCQ@public.gmane.org> wrote:> > > Hey Jerod, > > I''m sorry if you felt bruised by my reply, I may have needed to word it > more carefully. > > Ideas are indeed welcome (if you look at the archives, you''ll probably > acknowledge this), but when they do not provide enough of a solution, or > when it is improvable, it should be pointed out. > > On your side, you may have wanted to finetune your solution for better > practices before posting a reply; there was no rush; other solutions > were already there, and the OP mentioned he was going to go with > tabindexes (which is good from an accessibility standpoint, BTW). > > Also, I believe my Spinoffs-related remark stands: considering this > group is about Prototype and script.aculo.us, you should try to provide > a solution that leverages what''s useful in these (case in point, > Prototype). > > In another context, I would have provided a patched version of your > solution, but since other solutions were already posted, I didn''t feel > the need. > > I''m sorry, again, that you felt chastised. It certainly wasn''t my > intention. Any good will is welcome here, but we should all strive to > post code that leverages as much best practice and Prototypishness as > possible.:) Understood and agreed. No hard feelings. Sincerely,> > -- > Christophe Porteneuve aka TDD > tdd-x+CfDp/qHev2eFz/2MeuCQ@public.gmane.org > > > > -Jerod--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---