Bug 62664 – webkit-box-direction: reverse tab order

• Status: RESOLVED
• Resolution: WORKSFORME
• Component: CSS

[Greg Billock]

Created attachment 97168 [details]
Reduction of -webkit-box-direction: reverse tab order bug

Using a reversed direction style such as:

.class {
  -webkit-box-direction: reverse;
}

the tab order of the elements in the box don't reverse. See attachment HTML for an example.

[Tony Chang]

It looks like it was never implemented, although there's code to parse it.  RenderStyle.h also seems to be aware of it (EBoxDirection), but there's no code that uses it.

[Alice Boxhall]

This appear to work on Chrome 13.0.782.20 dev (WebKit r87771) and WebKit Nightly r88920 -- at least, tabbing through hits the elements in the order suggested by the text.

[Tony Chang]

Oh, sorry, I missed the use of boxDirection() in Render(Deprecated)FlexibleBox.cpp.

Greg, what order do you expect to tab through the buttons?

[Greg Billock]

I'd expect tab order to be reverse in the box-direction: reverse case. That is, for tab order to move from top to bottom and left to right. (Or rtl if that's set.)

That is, instead of going in appearance order, when the box is layout-reversed, tab order within that box would go in reverse appearance order as well.

[Tony Chang]

(In reply to comment #4)
> I'd expect tab order to be reverse in the box-direction: reverse case. That is, for tab order to move from top to bottom and left to right. (Or rtl if that's set.)
> 
> That is, instead of going in appearance order, when the box is layout-reversed, tab order within that box would go in reverse appearance order as well.

In your test case, you expect tabbing to hit the elements in the order suggested by the text?  That's the behavior that Alice and I are seeing.

Can you include your chrome and webkit version (in about:version)?

[Shane Stephens]

Verified working in Chrome 12, Chrome 14 and WebKit nightly on OSX. I'm going to close this bug - Greg if you can still repro, please reopen the bug and include your browser version and operating system.

[Greg Billock]

I think I misunderstood your reply. What I'd expect is that the tab order follows the visual layout, not the appearance in the HTML file. So if the layout is reversed, the tab order would reverse. What I see is that the tab order always follows the HTML appearance order, regardless of box-direction.

Assuming the use case for box-direction is to account for platform default mimicry and RTL type issues, I think tab order reversal is a good expectation here. Are there use cases where it is a poor expectation?

[Tony Chang]

What's the tab order in IE10 platform preview and Firefox?

[Shane Stephens]

To be completely specific: on Chrome 12, Chrome 14 and WebKit nightly on OSX I observe that the tab order traverses all of the buttons in your reduction in number order - i.e. "First", then "Second", then "Third", then "Fourth", etc.

Is that the order you expect to see?  Or do you expect to see "First", then "Fourth", then "Third", then "Second"?

FWIW the specification leaves it up to the platform to define tab order in the absence of a author-provided tabindex value (see http://dev.w3.org/html5/spec/Overview.html#sequential-focus-navigation-and-the-tabindex-attribute), so either behavior could be judged correct :)

If you think that number order is correct but you're seeing the reverse somewhere, please provide your browser version and OS so we can try to repro.

If you think that number order is incorrect, probably the best thing to do is send an email to webkit-dev explaining why the alternative is better, and we'll wait for the outcome of that discussion before changing the current coded behavior. On the other hand, if your specification-fu is better than mine and you've found some indication that number order is incorrect, then reopen this bug and provide a link to the spec.

[Greg Billock]

Yes, I'd expect tab order to be "First" "Fourth" "Third" "Second" "Fifth" "Eighth" "Seventh" "Sixth" "Ninth". (Seen in Chrome 13 and head and I suspect all other webkit-based browsers.)

That is, I'd expect the tab order to reflect the display order rather than HTML order. That said, I agree with you that the spec leaves this open and it isn't immediately obvious what to do. On the other hand, tabindex is fraught and usually better left alone, and my intuition here is informed by the context: the box-direction isn't impacting the tab ordering as it seems it should. Which is to say, my intuition is that if the layout reverses because of this markup, then the browser-picked tab ordering ought to reverse as well (absent any tabindex, which ought to dominate).

I'll email webkit-dev as you suggest. Thanks!

[Evan Stade]

ping on this. It's causing pain in chrome:// pages.

[Tony Chang]

(In reply to comment #11)
> ping on this. It's causing pain in chrome:// pages.

I think this is working as intended.  Other CSS properties that change the visual layout don't change the tab order (e.g., if I use a float or position: absolute).

We could maybe change this for new flexbox, but that feels like a hack since it would only apply to new flexbox.  I.e., we should try to come up with a good CSS solution for tab ordering that applies to all elements instead of just flexbox.

Can you use tabindex or javascript instead?

[Ojan Vafai]

The suggested generic solution to this problem: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-November/033775.html.

[Evan Stade]

when using -webkit-box-direction: reverse, the author's intended tab order would be to match the visual appearance approximately 99.8% of the time. It defeats the purpose of having -webkit-box-direction if it doesn't work properly, indeed for chrome://settings we have used javascript to hack around this and we don't use the property at all. However doing this for every reversible set of widgets on every chrome:// page (or more generically, on every page on the web) is unwieldy and, in practice, just doesn't happen because this problem is likely to go unnoticed.

Ojan's generic solution is nice (also reminiscent of the latest xkcd), but again, it's a lot of extra work when you consider it's something you want every single time. However his suggestion would likely solve the tangential problem that it's impossible to make a hierarchy of divs unfocusable by changing the tabindex of its root.