Bug 62664 - webkit-box-direction: reverse tab order
Summary: webkit-box-direction: reverse tab order
Status: RESOLVED WORKSFORME
Alias: None
Product: WebKit
Classification: Unclassified
Component: CSS (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-06-14 14:45 PDT by Greg Billock
Modified: 2011-11-08 14:49 PST (History)
7 users (show)

See Also:


Attachments
Reduction of -webkit-box-direction: reverse tab order bug (1.32 KB, text/html)
2011-06-14 14:45 PDT, Greg Billock
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Greg Billock 2011-06-14 14:45:37 PDT
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.
Comment 1 Tony Chang 2011-06-14 14:52:39 PDT
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.
Comment 2 Alice Boxhall 2011-06-15 20:46:44 PDT
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.
Comment 3 Tony Chang 2011-06-16 09:45:10 PDT
Oh, sorry, I missed the use of boxDirection() in Render(Deprecated)FlexibleBox.cpp.

Greg, what order do you expect to tab through the buttons?
Comment 4 Greg Billock 2011-06-16 11:04:39 PDT
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.
Comment 5 Tony Chang 2011-06-16 11:09:29 PDT
(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)?
Comment 6 Shane Stephens 2011-06-22 21:52:21 PDT
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.
Comment 7 Greg Billock 2011-06-23 09:43:47 PDT
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?
Comment 8 Tony Chang 2011-06-23 10:16:20 PDT
What's the tab order in IE10 platform preview and Firefox?
Comment 9 Shane Stephens 2011-06-23 16:26:28 PDT
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.
Comment 10 Greg Billock 2011-06-27 15:44:17 PDT
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!
Comment 11 Evan Stade 2011-11-07 21:19:58 PST
ping on this. It's causing pain in chrome:// pages.
Comment 12 Tony Chang 2011-11-08 09:22:21 PST
(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?
Comment 13 Ojan Vafai 2011-11-08 11:08:32 PST
The suggested generic solution to this problem: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-November/033775.html.
Comment 14 Evan Stade 2011-11-08 14:49:33 PST
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.