W3C home > Mailing lists > Public > whatwg@whatwg.org > June 2012

Re: [whatwg] tabindexscope

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Fri, 8 Jun 2012 12:28:30 +1000
Message-ID: <CAHp8n2mvrrkZ6LSjNrLXNH2T8MotDs4heCNWnA=YK8XgdQq_Ew@mail.gmail.com>
To: Ian Hickson <ian@hixie.ch>
Cc: whatwg <whatwg@lists.whatwg.org>, "Eric Sh." <shedokan1@gmail.com>, "Tab Atkins Jr." <jackalmage@gmail.com>, Simon Pieters <simonp@opera.com>, Ojan Vafai <ojan@chromium.org>
On Fri, Jun 8, 2012 at 11:49 AM, Silvia Pfeiffer
<silviapfeiffer1@gmail.com> wrote:
> On Fri, Jun 8, 2012 at 6:10 AM, Ian Hickson <ian@hixie.ch> wrote:
>> On Thu, 7 Jun 2012, Silvia Pfeiffer wrote:
>>> >
>>> > 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.
>>>
>>> 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.
>>
>> I don't think this is really a good use case for three reasons:
>>
>> - You describe the intended tab order as being the visual order, which is,
>> per spec, the order the UA should be using in the first place if that's
>> what the platform does, not the DOM order;
>
> I haven't seen a spec that says how browsers should implement the
> default tab order - is there one? Typically it has been implemented to
> be DOM order with the ability given to Web Devs the ability to
> override this using @tabindex. As long as there is no spec requiring
> browsers to implement the default tab order to be the visual order
> (given absolutely placed elements, floating elements etc), I don't
> think we can make any assumptions about it.
>
>
>> - Typically a video player like this would be embedded using an <iframe>,
>> which introduces a new tab order scope anyway;
>
> Yes, that solves this issue oftentimes. But what happens when you want
> to provide developers a HTML fragment without <iframe> for cut and
> paste and it requires tabindex fixes? It's pretty annoying for the Web
> dev to have to go through that snippet and manually adapt it to their
> Website. Assuming it comes from a content mgmt system, you'd need to
> include a parameter for the embedding that adapts the snippet's
> tabindex attribute values when including it with a dependency on the
> Web page on which it renders. It would be pretty fragile.
>
>
>> - Widgets in general will in the future be designed in self-contained
>> components, which should IMHO be defined as a tab order scope -- we don't
>> need an attribute in HTML to support that.
>
> How would that work? Is there a spec somewhere?
>
> Cheers,
> Silvia.

Actually, I'm just thinking it through for the content management use
case (in particular here the YouTube case). I don't think I can solve
this without a @tabindexscope.

Assuming the video player is in a Web page and has a custom tab order
of the elements defined where the first one will start at value n and
the others successively have value n+1, this will still dominate all
other elements on the page that come before it. I can't even change
that n value dynamically for the page, because the player overall
needs to sit as part of the @tabindex=0 order of the page. Otherwise
it will always be addressed first.

The problem is that @tabindex does two things: it changes the relative
order, and it prioritizes elements over those that have an implicit
tab order. It's the need for explicit order combined with the side
effect of prioritization that motivates the use case for
@tabindexscope.

Cheers,
Silvia.
Received on Friday, 8 June 2012 02:29:21 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:43 UTC