Re: [whatwg] Maximum value needed for tabindex
2014-07-24 8:34, Boris Zbarsky wrote: On 7/24/14, 1:29 AM, Jukka K. Korpela wrote: However, browsers actually impose an upper limit of 32767 In Chrome and Firefox, values larger than this are interpreted as 0. In the case of Firefox, this was a bug, that was fixed a few months ago. See https://bugzilla.mozilla.org/show_bug.cgi?id=996095 I’m afraid the fix does not work. Testing the jsfiddle code there, http://jsfiddle.net/tatesn/hVv72/ in the newest Firefox (31.0, on Win 7), the “Click here” link, with tabindex=4, and the input element after it, with tabindex=27, are not in the tabbing order at all, and the tabIndex property value is 32767. This is odd because tabindex=32767 as such works OK. My observation on larger values being taken as 0 was based on my initial testing with very large values (outside Int32 range). In Chrome, the elements are in the tabbing order, but if their tabindex attributes are swapped, the order stays the same, i.e. follows the textual order. This is natural since tabIndex property value is 32767 for both. 1) Keep tabindex unlimited and try to make browsers implement this. This is what we should do, in my totally biased opinion. Even in the best case, it would take several years before the usage share of all current browser versions is small enough. Are there any use cases for tabindex values greater than 32767? Presumably not real use now (since such values do not work), but are there reasonably imaginable use cases? Yucca
Re: [whatwg] Maximum value needed for tabindex
On 07/24/2014 09:10 AM, Jukka K. Korpela wrote: 2014-07-24 8:34, Boris Zbarsky wrote: On 7/24/14, 1:29 AM, Jukka K. Korpela wrote: However, browsers actually impose an upper limit of 32767 In Chrome and Firefox, values larger than this are interpreted as 0. In the case of Firefox, this was a bug, that was fixed a few months ago. See https://bugzilla.mozilla.org/show_bug.cgi?id=996095 I’m afraid the fix does not work. Testing the jsfiddle code there, http://jsfiddle.net/tatesn/hVv72/ in the newest Firefox (31.0, on Win 7), The patch landed for FF32. the “Click here” link, with tabindex=4, and the input element after it, with tabindex=27, are not in the tabbing order at all, and the tabIndex property value is 32767. This is odd because tabindex=32767 as such works OK. My observation on larger values being taken as 0 was based on my initial testing with very large values (outside Int32 range). In Chrome, the elements are in the tabbing order, but if their tabindex attributes are swapped, the order stays the same, i.e. follows the textual order. This is natural since tabIndex property value is 32767 for both. 1) Keep tabindex unlimited and try to make browsers implement this. This is what we should do, in my totally biased opinion. Even in the best case, it would take several years before the usage share of all current browser versions is small enough. Are there any use cases for tabindex values greater than 32767? Presumably not real use now (since such values do not work), but are there reasonably imaginable use cases? Yucca
Re: [whatwg] Maximum value needed for tabindex
On 7/24/14, 2:10 AM, Jukka K. Korpela wrote: I’m afraid the fix does not work. Sure it does. Testing the jsfiddle code there, http://jsfiddle.net/tatesn/hVv72/ in the newest Firefox (31.0, on Win 7) The newest Firefox you should be testing in for everything except what do shipping UAs do in this legacy situation? is the one you get from http://nightly.mozilla.org, just like you should be testing WebKit nightlies and Chrome canary (or dev, worst-case) builds. Firefox 31 is based on code that was feature-frozen 3 months ago, so if something is fixed a few months ago chances are it's not in 31. This particular fix is in Firefox 32. Are there any use cases for tabindex values greater than 32767? We've seen use cases for forms with that many form controls (large forms parts of which get conditionally shown/hiden based on values filled in for some of the controls), so I would think so, yes. -Boris
Re: [whatwg] Maximum value needed for tabindex
2014-07-24 17:24, Boris Zbarsky wrote: Are there any use cases for tabindex values greater than 32767? We've seen use cases for forms with that many form controls (large forms parts of which get conditionally shown/hiden based on values filled in for some of the controls), so I would think so, yes. So how have authors handled the issue in the current situation where browsers fail to support tabindex values 32767 and do that inconsistently? Having that many controls is rather exceptional, but there's more: tabindex attributes are needed only when you need to make the order of controls in source different from the tabbing order. Yucca
Re: [whatwg] Maximum value needed for tabindex
On 7/24/14, 3:13 PM, Jukka K. Korpela wrote: So how have authors handled the issue in the current situation where browsers fail to support tabindex values 32767 and do that inconsistently? By not using tabindex on those forms and possibly having sucky keyboard navigation. Having that many controls is rather exceptional, but there's more: tabindex attributes are needed only when you need to make the order of controls in source different from the tabbing order. Sure. -Boris
Re: [whatwg] Maximum value needed for tabindex
On Thu, 24 Jul 2014 08:10:55 +0200, Jukka K. Korpela jkorp...@cs.tut.fi wrote: 2014-07-24 8:34, Boris Zbarsky wrote: On 7/24/14, 1:29 AM, Jukka K. Korpela wrote: 1) Keep tabindex unlimited and try to make browsers implement this. This is what we should do, in my totally biased opinion. Even in the best case, it would take several years before the usage share of all current browser versions is small enough. Yes. Trying to promote a 'best practice' not to use big numbers because they don't work will also take time, and people will go on repeating it long after it isn't true anymore - while others will say it's old hat long before that becomes the case. So the question is which is the path of least harm. Are there any use cases for tabindex values greater than 32767? Presumably not real use now (since such values do not work), but are there reasonably imaginable use cases? I find it hard to come up with one. Having 327 marked active items in a page and using tabindex in increments of 100 is already a pretty bad situation, at the level where you should probably be dynamically controlling the things with tabindex. Which in turn means you can use smaller increments, and dynamically manage them. Having 32k items in a page doesn't seem like the real-world problem would be numbering the tabindex, but the fact that there are 32k active things you're trying to manage in a single ordered list… cheers -- Charles McCathie Nevile - web standards - CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: [whatwg] Maximum value needed for tabindex
On Friday 2014-07-25 00:19 +0200, Charles McCathie Nevile wrote: Having 32k items in a page doesn't seem like the real-world problem would be numbering the tabindex, but the fact that there are 32k active things you're trying to manage in a single ordered list… Having a notion of scoping for tabindex (and 'nav-index') would be great. It's been proposed a number of times, e.g.: http://lists.w3.org/Archives/Public/wai-xtech/2011Nov/thread.html#msg35 http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-November/033775.html http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2006-August/007236.html I'd be happy to see somebody drive a solution to this forward. -David -- 턞 L. David Baron http://dbaron.org/ 턂 턢 Mozilla https://www.mozilla.org/ 턂 Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914)
Re: [whatwg] Maximum value needed for tabindex
On 7/24/14, 1:29 AM, Jukka K. Korpela wrote: However, browsers actually impose an upper limit of 32767 In Chrome and Firefox, values larger than this are interpreted as 0. In the case of Firefox, this was a bug, that was fixed a few months ago. See https://bugzilla.mozilla.org/show_bug.cgi?id=996095 1) Keep tabindex unlimited and try to make browsers implement this. This is what we should do, in my totally biased opinion. -Boris
