W3C home > Mailing lists > Public > whatwg@whatwg.org > July 2014

[whatwg] Maximum value needed for tabindex

From: Jukka K. Korpela <jkorpela@cs.tut.fi>
Date: Thu, 24 Jul 2014 08:29:43 +0300
Message-ID: <53D099C7.6060402@cs.tut.fi>
To: whatwg <whatwg@lists.whatwg.org>
The tabindex attribute is defined so that its value must be a valid 
integer. No other restrictions are currently imposed.

However, browsers actually impose an upper limit of 32767 (which is in 
accordance with HTML 4.01:
http://www.w3.org/TR/html401/interact/forms.html#adef-tabindex ).

In Chrome and Firefox, values larger than this are interpreted as 0. 
This can be seen by setting an attribute with larger value and 
displaying the value of the tabIndex property of the element node.

This means that if you try to use tabindex=50000, it seems to work 
(since elements with tabindex=0 are placed after elements with tabindex 
in the accepted range), but if you then add tabindex=40000, its position 
relative to the element with tabindex=50000 is determined by source code 
order, not by the value you've written.

IE is worse. It maps a tabindex attribute value of 32768 to 0 and larger 
values apparently all to negative values (so that they do not appear in 
tabbing order at all).

There are two ways to deal with this:
1) Keep tabindex unlimited and try to make browsers implement this.
2) Specify an upper limit of 32767.

Option 1 sounds unrealistic, and it would take a long time. Moreover, it 
is difficult to imagine a situation where tabindex values larger than 
32767 would be needed. Authors may be using values like 100, 200 etc. to 
allow insertion of elements with in-between values, i.e. adding elements 
to the tabbing order without changing the numbering. But even then, 
32767 should suffice for all practical needs.

If option 2 is taken, there is the question whether error processing 
rules should be defined, i.e. whether browsers would be required to 
handle values larger than 32767 in a specific way. Perhaps not, because 
that could carry a wrong message; any defined error handling can be 
taken to that authors can rely on it.

-- 
Yucca, http://www.cs.tut.fi/~jkorpela/
Received on Thursday, 24 July 2014 05:30:08 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:21 UTC