On Fri, Jun 8, 2012 at 6:10 AM, Ian Hickson <i...@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.
