Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #12510 > unrolled thread

Removing a Control from the taborder

Back to article view | Back to comp.lang.javascript

Contents

  Removing a Control from the taborder Gene Wirchenko <genew@ocis.net> - 2012-03-08 13:56 -0800
    Re: Removing a Control from the taborder "Evertjan." <exjxw.hannivoort@interxnl.net> - 2012-03-09 00:07 +0000
      Re: Removing a Control from the taborder Gene Wirchenko <genew@ocis.net> - 2012-03-08 19:37 -0800
        Re: Removing a Control from the taborder Norman Peelman <npeelmandog@cfl.rr.com> - 2012-03-09 18:56 -0500
          Re: Removing a Control from the taborder Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-03-10 01:42 +0100
            Re: Removing a Control from the taborder Norman Peelman <npeelmandog@cfl.rr.com> - 2012-03-09 22:59 -0500
              Re: Removing a Control from the taborder "Jukka K. Korpela" <jkorpela@cs.tut.fi> - 2012-03-10 08:40 +0200
                Re: Removing a Control from the taborder Norman Peelman <npeelmandog@cfl.rr.com> - 2012-03-10 06:18 -0500
                  Re: Removing a Control from the taborder Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-03-10 13:33 +0100
              Re: Removing a Control from the taborder Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-03-10 12:33 +0100
            Re: Removing a Control from the taborder Norman Peelman <npeelmandog@cfl.rr.com> - 2012-03-09 23:22 -0500
        Re: Removing a Control from the taborder Dr J R Stockton <reply1210@merlyn.demon.co.uk> - 2012-03-10 20:51 +0000
          Re: Removing a Control from the taborder Gene Wirchenko <genew@ocis.net> - 2012-03-10 23:55 -0800
            Re: Removing a Control from the taborder Dr J R Stockton <reply1211@merlyn.demon.co.uk.invalid> - 2012-03-12 19:46 +0000
            Re: Removing a Control from the taborder David Mark <dmark.cinsoft@gmail.com> - 2012-03-12 18:24 -0700

#12510 — Removing a Control from the taborder

Dear JavaScripters:

     Is there a standard-compliant way in JavaScript to remove a
control from the taborder?

     There is a non-standard-compliant way of doing it in HTML with
          ...taborder=-1...
I prefer not to use this.

     On the bad side, I just found that my form handler does not work
quite right in Firefox, but this is not an excuse for not being as
standard-compliant as I can.

Sincerely,

Gene Wirchenko

[toc] | [next] | [standalone]

#12514

Gene Wirchenko wrote on 08 mrt 2012 in comp.lang.javascript:
>      Is there a standard-compliant way in JavaScript to remove a
> control from the taborder?
> 
>      There is a non-standard-compliant way of doing it in HTML with
>           ...taborder=-1...
> I prefer not to use this.

It surely is tabindex='1', not taborder='1'.

Meseems tabindex='-1' is standard, 
but then I do not care much for standard-compliance 
but do care for cross-browser compatibility.

<http://reference.sitepoint.com/html/a/tabindex>

However this surely is off-topic on this NG.
Shall we go back to Javascript?

-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]

#12520

On 09 Mar 2012 00:07:13 GMT, "Evertjan."
<exjxw.hannivoort@interxnl.net> wrote:

>Gene Wirchenko wrote on 08 mrt 2012 in comp.lang.javascript:
>>      Is there a standard-compliant way in JavaScript to remove a
>> control from the taborder?
>> 
>>      There is a non-standard-compliant way of doing it in HTML with
>>           ...taborder=-1...
>> I prefer not to use this.
>
>It surely is tabindex='1', not taborder='1'.

     It is.  Somehow, I had a thinko at one point.

>Meseems tabindex='-1' is standard, 

     It is not standard.  Per the HTML 4.01 Specification:

"17.11.1 Tabbing navigation
  
   Attribute definitions
   
   tabindex = number [CN]
          This attribute specifies the position of the current element
in
          the tabbing order for the current document. This value must
be
          a number between 0 and 32767. User agents should ignore
leading
          zeros."
  
>but then I do not care much for standard-compliance 
>but do care for cross-browser compatibility.
>
><http://reference.sitepoint.com/html/a/tabindex>

     I like both.

>However this surely is off-topic on this NG.
>Shall we go back to Javascript?

     If there is a JavaScript answer to my question, I would quite
happily take it.

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#12559

On 03/08/2012 10:37 PM, Gene Wirchenko wrote:
> On 09 Mar 2012 00:07:13 GMT, "Evertjan."
> <exjxw.hannivoort@interxnl.net>  wrote:
>
>> Gene Wirchenko wrote on 08 mrt 2012 in comp.lang.javascript:
>>>       Is there a standard-compliant way in JavaScript to remove a
>>> control from the taborder?
>>>
>>>       There is a non-standard-compliant way of doing it in HTML with
>>>            ...taborder=-1...
>>> I prefer not to use this.
>>
>> It surely is tabindex='1', not taborder='1'.
>
>       It is.  Somehow, I had a thinko at one point.
>
>> Meseems tabindex='-1' is standard,
>
>       It is not standard.  Per the HTML 4.01 Specification:
>
> "17.11.1 Tabbing navigation
>
>     Attribute definitions
>
>     tabindex = number [CN]
>            This attribute specifies the position of the current element
> in
>            the tabbing order for the current document. This value must
> be
>            a number between 0 and 32767. User agents should ignore
> leading
>            zeros."
>
>> but then I do not care much for standard-compliance
>> but do care for cross-browser compatibility.
>>
>> <http://reference.sitepoint.com/html/a/tabindex>
>
>       I like both.
>
>> However this surely is off-topic on this NG.
>> Shall we go back to Javascript?
>
>       If there is a JavaScript answer to my question, I would quite
> happily take it.
>
> Sincerely,
>
> Gene Wirchenko

   Consider this, the tabindex controls the tab order of the form 
elements with a range of 0 - 32767. That means to remove a form element 
from the tabindex it must not be in that range. "-1" is not in that 
range, nor is "-32767" or anything in between for that matter. You could 
simply throw (insert) a minus sign in front of a form element to disable 
it, even via scripting (simply multiply the tabindex by -1 to toggle).

http://fluidproject.org/blog/2008/01/09/getting-setting-and-removing-tabindex-values-with-javascript/


-- 
Norman
Registered Linux user #461062
AMD64X2 6400+ Ubuntu 10.04 64bit

[toc] | [prev] | [next] | [standalone]

#12562

Norman Peelman wrote:

>    Consider this, the tabindex controls the tab order of the form
> elements with a range of 0 - 32767. That means to remove a form element
> from the tabindex it must not be in that range. "-1" is not in that
> range, nor is "-32767" or anything in between for that matter. You could
> simply throw (insert) a minus sign in front of a form element to disable
> it, even via scripting (simply multiply the tabindex by -1 to toggle).

Your logic is flawed.  The HTML 4.01 Specification is definitive about this: 
values for the `tabindex' attribute outside the specified range are 
*invalid*.  It is specified accordingly in W3C DOM Level 2 HTML:

<http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-40676705>

However:
 
> http://fluidproject.org/blog/2008/01/09/getting-setting-and-removing-
tabindex-values-with-javascript/

It is disturbing to see that HTML5 would allow authors to create focusable 
elements that could not be reached with basic keyboard navigation, making 
those documents not accessible:

<http://www.w3.org/TR/html5/editing.html#sequential-focus-navigation-and-
the-tabindex-attribute>

There is also an inconsistency here: HTML5 must not allow values for 
attributes already specified in HTML 4 that cannot be set using a conforming 
implementation of W3C DOM Level 2 HTML.  Either HTML5 renounces its 
backwards compatibility with HTML 4, or it must specify the attribute value 
differently.

Bottom line: There is no public standard to back up your approach as of yet. 
It is likely to be not interoperable, and it is certain to be not accessible 
if supported.  The range of your research is far too narrow to make a case 
for the adoption of this approach.


PointedEars
-- 
Danny Goodman's books are out of date and teach practices that are
positively harmful for cross-browser scripting.
  -- Richard Cornford, cljs, <cife6q$253$1$8300dec7@news.demon.co.uk> (2004)

[toc] | [prev] | [next] | [standalone]

#12564

On 03/09/2012 07:42 PM, Thomas 'PointedEars' Lahn wrote:
> Norman Peelman wrote:
>
>>     Consider this, the tabindex controls the tab order of the form
>> elements with a range of 0 - 32767. That means to remove a form element
>> from the tabindex it must not be in that range. "-1" is not in that
>> range, nor is "-32767" or anything in between for that matter. You could
>> simply throw (insert) a minus sign in front of a form element to disable
>> it, even via scripting (simply multiply the tabindex by -1 to toggle).
>
> Your logic is flawed.  The HTML 4.01 Specification is definitive about this:
> values for the `tabindex' attribute outside the specified range are
> *invalid*.  It is specified accordingly in W3C DOM Level 2 HTML:
>

   Invalid, thereby causing the tabindex to be ignored.

> <http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-40676705>
>
> However:
>
>> http://fluidproject.org/blog/2008/01/09/getting-setting-and-removing-
> tabindex-values-with-javascript/
>
> It is disturbing to see that HTML5 would allow authors to create focusable
> elements that could not be reached with basic keyboard navigation, making
> those documents not accessible:
>
> <http://www.w3.org/TR/html5/editing.html#sequential-focus-navigation-and-
> the-tabindex-attribute>
>
> There is also an inconsistency here: HTML5 must not allow values for
> attributes already specified in HTML 4 that cannot be set using a conforming
> implementation of W3C DOM Level 2 HTML.  Either HTML5 renounces its
> backwards compatibility with HTML 4, or it must specify the attribute value
> differently.
>
> Bottom line: There is no public standard to back up your approach as of yet.
> It is likely to be not interoperable, and it is certain to be not accessible
> if supported.  The range of your research is far too narrow to make a case
> for the adoption of this approach.
>
>
> PointedEars

-- 
Norman
Registered Linux user #461062
AMD64X2 6400+ Ubuntu 10.04 64bit

[toc] | [prev] | [next] | [standalone]

#12567

2012-03-10 5:59, Norman Peelman wrote:

> On 03/09/2012 07:42 PM, Thomas 'PointedEars' Lahn wrote:

Please don't feed the troll.

>> Your logic is flawed. The HTML 4.01 Specification is definitive about
>> this:
>> values for the `tabindex' attribute outside the specified range are
>> *invalid*. It is specified accordingly in W3C DOM Level 2 HTML:
>
> Invalid,

Validity, as HTML 4.01 concept, is off-topic here, and it is defined in 
the HTML 4.01 specification, not in DOM specifications. As it happens, 
tabindex=-1 is invalid as per HTML 4.01, but not because of any 
out-of-range issue. It is invalid because the tabindex attribute is 
declared as NUMBER, which means a character-level restriction (only 
digits are allowed).

 > thereby causing the tabindex to be ignored.

No, the HTML 4.01 specification imposes no such requirement on error 
processing. And browsers do not ignore tabindex=-1.

If it is relevant, for some reason, that the markup in an HTML file 
conforms to an HTML 4.01 DTD, then you can still set tabindex to a 
negative value via JavaScript. Just note that in JavaScript, the 
corresponding property is spelled tabIndex.

-- 
Yucca, http://www.cs.tut.fi/~jkorpela/

[toc] | [prev] | [next] | [standalone]

#12571

On 03/10/2012 01:40 AM, Jukka K. Korpela wrote:
> 2012-03-10 5:59, Norman Peelman wrote:
>
>> On 03/09/2012 07:42 PM, Thomas 'PointedEars' Lahn wrote:
>
> Please don't feed the troll.
>
>>> Your logic is flawed. The HTML 4.01 Specification is definitive about
>>> this:
>>> values for the `tabindex' attribute outside the specified range are
>>> *invalid*. It is specified accordingly in W3C DOM Level 2 HTML:
>>
>> Invalid,
>
> Validity, as HTML 4.01 concept, is off-topic here, and it is defined in
> the HTML 4.01 specification, not in DOM specifications. As it happens,
> tabindex=-1 is invalid as per HTML 4.01, but not because of any
> out-of-range issue. It is invalid because the tabindex attribute is
> declared as NUMBER, which means a character-level restriction (only
> digits are allowed).
>
>  > thereby causing the tabindex to be ignored.
>
> No, the HTML 4.01 specification imposes no such requirement on error
> processing. And browsers do not ignore tabindex=-1.
>

   I meant the form element would be ignored (skipped) while tabbing. 
Poor wording on my part.

> If it is relevant, for some reason, that the markup in an HTML file
> conforms to an HTML 4.01 DTD, then you can still set tabindex to a
> negative value via JavaScript. Just note that in JavaScript, the
> corresponding property is spelled tabIndex.
>

   As I indicated in another post. Somewhere...

-- 
Norman
Registered Linux user #461062
AMD64X2 6400+ Ubuntu 10.04 64bit

[toc] | [prev] | [next] | [standalone]

#12573

Norman Peelman wrote:

> On 03/10/2012 01:40 AM, Jukka K. Korpela wrote:
>> If it is relevant, for some reason, that the markup in an HTML file
>> conforms to an HTML 4.01 DTD, then you can still set tabindex to a
>> negative value via JavaScript. Just note that in JavaScript, the
>> corresponding property is spelled tabIndex.
> 
>    As I indicated in another post. Somewhere...

There is no public standard to support that approach either, as detailed in 
my other answer.  Attribute properties, and DOM/AOM properties in general, 
have setters to prevent them from being assigned unsupported values.  Some 
DOM implementations like MSHTML (in IE) even throw exceptions in that case.


PointedEars
-- 
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee

[toc] | [prev] | [next] | [standalone]

#12572

Norman Peelman wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Norman Peelman wrote:
>>>     Consider this, the tabindex controls the tab order of the form
>>> elements with a range of 0 - 32767. That means to remove a form element
>>> from the tabindex it must not be in that range. "-1" is not in that
>>> range, nor is "-32767" or anything in between for that matter. You could
>>> simply throw (insert) a minus sign in front of a form element to disable
>>> it, even via scripting (simply multiply the tabindex by -1 to toggle).
>>
>> Your logic is flawed.  The HTML 4.01 Specification is definitive about
>> this: values for the `tabindex' attribute outside the specified range are
>> *invalid*.  It is specified accordingly in W3C DOM Level 2 HTML:
> 
>    Invalid, thereby causing the tabindex to be ignored.

No, not necessarily.  That is the fallacy.  The type of the `tabindex' 
attribute in HTML 4.01 is the SGML type NUMBER [1a], and that type does not 
include values containing the `-' (U+002D HYPHEN-MINUS) character [2].  
There is no standard on handling invalid documents (only a non-normative 
recommendation for HTML 4.01 documents [1b]; HTML5 would become the first 
version of HTML to fix that [3]).  A conforming HTML 4.01 parser is free to 
interpret invalid markup as it sees fit (which is done, as evident by 
comparing results of other invalid markup in MSHTML-based and Gecko-based 
browsers alone).  For example, one parser, but not another (i.e., one 
browser, but not another), could reasonably normalize a value out of range 
to one in range – 0 – which would include the element in the tab order after 
all other elements that have a proper `tabindex' attribute set [1c].  

On top of inconsistent results with HTML user agents, the W3C Markup 
Validator and other properly working markup validators will report such an 
attribute value as a *syntax error* [4a].  While validation is not a mark of 
quality in itself [4b], failure of a document to validate, for dubious 
reasons such as this, certainly raises doubt about the competence of the 
document's author, which usually also is to the disadvantage of enterprises 
making and publishing the corresponding website.

Deliberately using invalid markup will make it harder for the 
author/programmer to find other, potentially more serious, accidental syntax 
errors in the document by using markup validation.  For example, think about 
a document where several such invalid elements as you propose are generated 
by a server-side application in a loop. 

There is also no guarantee that, in order to avoid an invalid document, 
assigning afterwards a negative Number value to the `tabIndex' attribute 
property of the corresponding DOM object would work; but there is strong 
indication that it would not work.  W3C DOM Level 2 HTML, which applies to 
HTML 4.01 and XHTML 1.0 documents [5a], specifies that property to be an 
implementation of the `tabIndex' IDL attribute of the HTMLInputElement 
interface (a.o.) whose values must correspond to the HTML 4.01 specification 
of the markup attribute [5b, 5c].

Your approach is positively harmful to all involved (enterprise, document 
author, script developer, and visitor).  IOW, it is a Really Bad Idea.


HTH

PointedEars
___________
[1a] <http://www.w3.org/TR/1999/REC-html401-19991224/interact/forms.html
      #h-17.4>,
     <http://www.w3.org/TR/1999/REC-html401-19991224/sgml/dtd.html>,
     <http://www.w3.org/TR/1999/REC-html401-19991224/strict.dtd>
[1b] <http://www.w3.org/TR/1999/REC-html401-19991224/appendix/notes.html
      #h-B.1>
[1c] <http://www.w3.org/TR/1999/REC-html401-19991224/interact/forms.html
      #adef-tabindex>
[2]  <http://www.w3.org/MarkUp/SGML/productions.html#prod56>
[3]  <http://www.w3.org/TR/html5/editing.html#sequential-focus-navigation-
      and-the-tabindex-attribute>
[4a] <http://validator.w3.org/#validate_by_input+with_options>,
     type `<input tabindex="-1">', select "Validate HTML fragment" (which
     by default selects "Use Doctype: HTML 4.01", select "Check".
[4b] <http://validator.w3.org/docs/help.html#validandquality>
[5a] <http://www.w3.org/TR/2003/REC-DOM-Level-2-HTML-20030109/>
[5b] <http://www.w3.org/TR/2003/REC-DOM-Level-2-HTML-20030109/ecma-script
      binding.html>
[5c] <http://www.w3.org/TR/2003/REC-DOM-Level-2-
      HTML-20030109/html.html#ID-62176355>
-- 
Use any version of Microsoft Frontpage to create your site.
(This won't prevent people from viewing your source, but no one
will want to steal it.)
  -- from <http://www.vortex-webdesign.com/help/hidesource.htm> (404-comp.)

[toc] | [prev] | [next] | [standalone]

#12565

On 03/09/2012 07:42 PM, Thomas 'PointedEars' Lahn wrote:
> Norman Peelman wrote:
>
>>     Consider this, the tabindex controls the tab order of the form
>> elements with a range of 0 - 32767. That means to remove a form element
>> from the tabindex it must not be in that range. "-1" is not in that
>> range, nor is "-32767" or anything in between for that matter. You could
>> simply throw (insert) a minus sign in front of a form element to disable
>> it, even via scripting (simply multiply the tabindex by -1 to toggle).
>
> Your logic is flawed.  The HTML 4.01 Specification is definitive about this:
> values for the `tabindex' attribute outside the specified range are
> *invalid*.  It is specified accordingly in W3C DOM Level 2 HTML:
>
> <http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-40676705>
>

   Seems firefox follows the 1-32767 range but Google Chrome does not... 
Chrome allows values greater than 32767 (did not try to find the MAX) 
but still skips on negative values. Epiphany, Konqueror, and Opera seem 
to follow suit (tabs on + , skips on -). The one issue I did notice was 
that Opera was the only browser to leave its GUI buttons out of the 
equation.


-- 
Norman
Registered Linux user #461062
AMD64X2 6400+ Ubuntu 10.04 64bit

[toc] | [prev] | [next] | [standalone]

#12586

In comp.lang.javascript message <1fuil7tf54q4gu2h40ous7k58q3766aaa9@4ax.
com>, Thu, 8 Mar 2012 19:37:23, Gene Wirchenko <genew@ocis.net> posted:

>     If there is a JavaScript answer to my question, I would quite
>happily take it.

Give the offending input an onFocus method which focuses the next input?
Untested.  You probably do NOT want to do it to all of them.

-- 
 (c) John Stockton, nr London, UK. ?@merlyn.demon.co.uk  Turnpike v6.05  MIME.
  Web  <http://www.merlyn.demon.co.uk/> - FAQqish topics, acronyms and links;
  Astro stuff via astron-1.htm, gravity0.htm ; quotings.htm, pascal.htm, etc.
 No Encoding. Quotes before replies. Snip well. Write clearly. Don't Mail News.

[toc] | [prev] | [next] | [standalone]

#12594

On Sat, 10 Mar 2012 20:51:14 +0000, Dr J R Stockton
<reply1210@merlyn.demon.co.uk> wrote:

>In comp.lang.javascript message <1fuil7tf54q4gu2h40ous7k58q3766aaa9@4ax.
>com>, Thu, 8 Mar 2012 19:37:23, Gene Wirchenko <genew@ocis.net> posted:
>
>>     If there is a JavaScript answer to my question, I would quite
>>happily take it.
>
>Give the offending input an onFocus method which focuses the next input?
>Untested.  You probably do NOT want to do it to all of them.

     No.  I want the control to be able to get the focus, just not by
tabbing.

     This is so the form reset button cannot be inadvertently tabbed
to.  Clicking on it directly is entirely acceptable.

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#12621

In comp.lang.javascript message <phmol7h3cf5mtlc1os2qfen4nkdpablg5p@4ax.
com>, Sat, 10 Mar 2012 23:55:40, Gene Wirchenko <genew@ocis.net> posted:

>On Sat, 10 Mar 2012 20:51:14 +0000, Dr J R Stockton
><reply1210@merlyn.demon.co.uk> wrote:
>
>>In comp.lang.javascript message <1fuil7tf54q4gu2h40ous7k58q3766aaa9@4ax.
>>com>, Thu, 8 Mar 2012 19:37:23, Gene Wirchenko <genew@ocis.net> posted:
>>
>>>     If there is a JavaScript answer to my question, I would quite
>>>happily take it.
>>
>>Give the offending input an onFocus method which focuses the next input?
>>Untested.  You probably do NOT want to do it to all of them.
>
>     No.  I want the control to be able to get the focus, just not by
>tabbing.
>
>     This is so the form reset button cannot be inadvertently tabbed
>to.  Clicking on it directly is entirely acceptable.

Then conceal, by subtle artistry, four more controls in the display.
Give the reset button a tab order of N, probably high; give two of the
new controls tab order of N-1 & N+1, and onfocus code respectively
focusing the other two controls, tab order N+2 & N-2.

<http://www.w3.org/TR/REC-html40/interact/forms.html#adef-tabindex> is,
I see, incorrect, as it says "This value must be a number between 0 and
32767", clearly intends to allow 0 and probably intends to allow 32767.
"This value must be a number from 0 to 32767" - which is shorter, too.

Unless by [CN], that section does not appear to say that tabindex must
be unique or constant.  A Google search implies that it can be changed.

So one asks - when tabbing, it must be the index that a tab has before
arrival that controls arrival.  But, on departure, is it the value that
it had on arrival or the value that it has on departure which is used to
select the next tab?  If the latter, one could swap the tabindex of two
adjacent tabs onfocus, which should prevent ever tabbing away from them.

But preventing operation by tabbing will handicap those whose mice,
touchpads, etc. are sick, dead, or absent.  Perhaps allow a hotkey to
select Reset - or forget about barring tabbing to Reset and inserting a
Conform before Reset action?

-- 
 (c) John Stockton, nr London, UK. ?@merlyn.demon.co.uk  Turnpike 6.05  WinXP.
 Web  <http://www.merlyn.demon.co.uk/> - FAQ-type topics, acronyms, and links.
 Command-prompt MiniTrue is useful for viewing/searching/altering files. Free,
 DOS/Win/UNIX now 2.0.6; see <URL:http://www.merlyn.demon.co.uk/pc-links.htm>.

[toc] | [prev] | [next] | [standalone]

#12628

On Mar 11, 3:55 am, Gene Wirchenko <ge...@ocis.net> wrote:
> On Sat, 10 Mar 2012 20:51:14 +0000, Dr J R Stockton
>
> <reply1...@merlyn.demon.co.uk> wrote:
> >In comp.lang.javascript message <1fuil7tf54q4gu2h40ous7k58q3766aaa9@4ax.
> >com>, Thu, 8 Mar 2012 19:37:23, Gene Wirchenko <ge...@ocis.net> posted:
>
> >>     If there is a JavaScript answer to my question, I would quite
> >>happily take it.
>
> >Give the offending input an onFocus method which focuses the next input?
> >Untested.  You probably do NOT want to do it to all of them.
>
>      No.  I want the control to be able to get the focus, just not by
> tabbing.

Though I've never tried it in markup:

el.tabIndex = -1;

Does the trick in most (if not all) browsers. So the question is: what
happens to your app if this fails? Somebody mentioned that the host
object could throw an exception, which is certainly true. Only way to
ensure a silent failure (which shouldn't hurt anything in this case)
is to wrap it in a try-catch.

Have to admit I've been doing the above for many years without
incident. It's very useful for tabs and such (one tab stop per
widget), provided you have appropriate keyboard handling in place (so
the arrow keys can change the focus). Clearly you should never do this
in static markup. If HTML5 allows this, it's a mistake (wouldn't be
the first one).

>
>      This is so the form reset button cannot be inadvertently tabbed
> to.  Clicking on it directly is entirely acceptable.

Honestly, that's crazy.  Put it *after* the submit button (assuming
you really need a reset button at all).

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.javascript

csiph-web