Re: [whatwg] tabindexscope

On Fri, 8 Jun 2012, Silvia Pfeiffer 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?

The spec says that "The user agent should follow platform conventions to 
determine if the element's tabindex focus flag is set and, if so, whether 
the element can be reached using sequential focus navigation, and if so, 
what its relative order should be".


> 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.

If we're working from the assumption that Web browsers aren't matching the 
spec, then it's not clear that changing the spec is in any way helpful.


> > - 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?

Do you have an example of this happening?


> 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.

I'm not saying it's inconceivable that a scoping mechanism for tab index 
would be useful in some cases. However, we can't possibly add everything 
that could have the remotest possibility of being useful. We have to 
implement things that have clear needs shown by real Web sites in volume.


> > - 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?

There are many, e.g. XBL2, sXBL, Web Components, the SVG thing that 
predated sXBL, etc.


On Fri, 8 Jun 2012, Silvia Pfeiffer wrote:
> 
> 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.

But why would you need tabindex="" at all in this situation? If we're 
going to ask browsers to implement something, it seems better to have them 
implement "make tab order match platform conventions (visual order)" than 
something new.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Tuesday, 28 August 2012 21:37:26 UTC