[whatwg] tabindexscope

[Silvia Pfeiffer]

On Thu, Jun 7, 2012 at 9:57 AM, Ian Hickson <ian at hixie.ch> wrote:
> On Mon, 30 Jan 2012, Tab Atkins Jr. wrote:
>> On Mon, Jan 30, 2012 at 1:54 PM, Ian Hickson <ian at hixie.ch> wrote:
>> > On Tue, 8 Nov 2011, Ojan Vafai wrote:
>> >> We keep running into the use case where the physical position matters
>> >> for the tab order. The problem with just setting tabIndex (or CSS3
>> >> tab-index) is that it takes the thing out of the natural order.
>> >>
>> >> This problem comes up in a lot of places (e.g. absolute positioning).
>> >> It's recently come up for CSS flexboxes, e.g. if you set flex-order or a
>> >> reverse flow, then the tabindex still being in document order is often
>> >> not what the author wants
>> >> (https://bugs.webkit.org/show_bug.cgi?id=62664).
>> >>
>> >> <button tabindex=0>A</button>
>> >> <div tabindex=2 tabindexscope>
>> >> <button tabindex=2>C</button>
>> >> <button tabindex=1>B</button>
>> >> </div>
>> >> <button tabindex=1>D</button>
>> >>
>> >> The order for the tabbing would be A-D-B-C.
>> >
>> > The spec says that the order when you omit tabindex (or set it to 0)
>> > should follow platform conventions. If the platform convention is to make
>> > the tab order follow the visual position, then that's what the browser
>> > should do.
>> >
>> > Surely that would be better than having authors manage local regions for
>> > tabindex, especially since the positioning depends on the CSS level, not
>> > the HTML level, and thus trying to manage the tabindex in the HTML would
>> > be a layering violation anyway.
>>
>> If you are attempting to match the tab order to the position of an
>> element, you are correct.  In this situation, the tab order of the
>> group itself should be controlled by the 'nav-index' property
>> alongside the positioning code.
>>
>> However, *within* a group of controls, the relative order can want to
>> be scoped without reference to CSS.  This can happen because the group
>> is being positioned with CSS (and thus the appropriate tab-index is
>> unpredictable), because the group may be generated into multiple pages
>> with different tab-index'd items elsewhere in the page, or just
>> because the dev would like to write their tab-indexes without having
>> to renumber everything every time they move the HTML around in the
>> page.
>>
>> Scoping a tab-index is thus a property that can appropriately belong
>> to the HTML level, just as much as tab-index itself does.
>
> Can you give some examples of real-world pages where the tabindex
> attribute has been used (with difficulty due to the lack of scoping),
> where nav-index is not the right solution, and where the UA following
> platform conventions for tab order doesn't or wouldn't end up in a good
> UI, that show that this feature would be useful? I'm having trouble
> picturing it, and the frequent references above to positioning and other
> CSS layout features is confusing me.

I think I have an example.

Imagine a video player with special functionality and a special tab
order defined (e.g. the current YouTube HTML5 player has that because
the logical visual layout of the control element is different from the
DOM order). On the video's home page you can pre-define the tab order
and make sure it fits with the page. But when it's embedded in another
Web page, and that special tab order potentially conflicts with the
page's tab order, since the embed code can't really know what index
number to start with, since you don't know anything about the page
into which it is embedded. I believe nav-index would have the same
problem, but a tabindexscope would solve the issue.

The same should actually be true for any other web widget with a
custom tab order.

Cheers,
Silvia.