62664 2011-06-14 14:45:37 -0700 webkit-box-direction: reverse tab order 2011-11-08 14:49:33 -0800 1 1 1 Unclassified WebKit CSS 528+ (Nightly build) Unspecified Unspecified RESOLVED WORKSFORME P2 Normal --- 0 gbillock webkit-unassigned aboxhall dglazkov estade hyatt ojan shanestephens tony oldest_to_newest 420739 0 97168 gbillock 2011-06-14 14:45:37 -0700 Created attachment 97168 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. 420743 1 tony 2011-06-14 14:52:39 -0700 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. 421741 2 aboxhall 2011-06-15 20:46:44 -0700 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. 422001 3 tony 2011-06-16 09:45:10 -0700 Oh, sorry, I missed the use of boxDirection() in Render(Deprecated)FlexibleBox.cpp. Greg, what order do you expect to tab through the buttons? 422077 4 gbillock 2011-06-16 11:04:39 -0700 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. 422081 5 tony 2011-06-16 11:09:29 -0700 (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)? 425948 6 shanestephens 2011-06-22 21:52:21 -0700 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. 426233 7 gbillock 2011-06-23 09:43:47 -0700 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? 426261 8 tony 2011-06-23 10:16:20 -0700 What's the tab order in IE10 platform preview and Firefox? 426601 9 shanestephens 2011-06-23 16:26:28 -0700 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. 428395 10 gbillock 2011-06-27 15:44:17 -0700 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! 497715 11 estade 2011-11-07 21:19:58 -0800 ping on this. It's causing pain in chrome:// pages. 498135 12 tony 2011-11-08 09:22:21 -0800 (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? 498269 13 ojan 2011-11-08 11:08:32 -0800 The suggested generic solution to this problem: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-November/033775.html. 498447 14 estade 2011-11-08 14:49:33 -0800 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. 97168 2011-06-14 14:45:37 -0700 2011-06-14 14:45:37 -0700 Reduction of -webkit-box-direction: reverse tab order bug wkbd.html text/html 1351 gbillock PGh0bWw+CiAgPGhlYWQ+CiAgICA8dGl0bGU+d2Via2l0LWJveC1kaXJlY3Rpb24gcmV2ZXJzZSB0 YWIgb3JkZXI8L3RpdGxlPgogICAgPHN0eWxlPgogICAgICBkaXYgewogICAgICAgIGRpc3BsYXk6 IC13ZWJraXQtYm94OwogICAgICAgIHBhZGRpbmc6IDJweDsKICAgICAgICBib3JkZXI6IDFweCBz b2xpZCBncmF5OwogICAgICAgIG1hcmdpbjogMXB4OwogICAgICAgIHdpZHRoOiA1MCU7CiAgICAg ICAgYmFja2dyb3VuZC1jb2xvcjogI2VlZWVlZTsKICAgICAgfQogICAgICAub3V0ZXIgewogICAg ICAgIC13ZWJraXQtYm94LW9yaWVudDogdmVydGljYWw7CiAgICAgIH0KICAgICAgLnR3byB7CiAg ICAgICAgLXdlYmtpdC1ib3gtZGlyZWN0aW9uOiByZXZlcnNlOwogICAgICAgIC13ZWJraXQtYm94 LW9yaWVudDogdmVydGljYWw7CiAgICAgICAgYmFja2dyb3VuZC1jb2xvcjogeWVsbG93OwogICAg ICB9CiAgICAgIC5mb3VyIHsKICAgICAgICAtd2Via2l0LWJveC1kaXJlY3Rpb246IHJldmVyc2U7 CiAgICAgICAgLXdlYmtpdC1ib3gtb3JpZW50OiBob3Jpem9udGFsOwogICAgICAgIGJhY2tncm91 bmQtY29sb3I6IHllbGxvdzsKICAgICAgfQogICAgICBidXR0b24gewogICAgICAgIGRpc3BsYXk6 IGJsb2NrOwogICAgICB9CiAgICA8L3N0eWxlPgogICAgPGJvZHk+CiAgICAgIDxoMT53ZWJraXQt Ym94LWRpcmVjdGlvbjogcmV2ZXJzZSB0YWIgb3JkZXIgdGVzdDwvaDE+CiAgICAgIDxkaXYgY2xh c3M9Im91dGVyIj4KICAgICAgICA8ZGl2IGNsYXNzPSJvbmUiPjxidXR0b24gaWQ9Im9uZSI+Rmly c3Q8L2J1dHRvbj48L2Rpdj4KICAgICAgICA8ZGl2IGNsYXNzPSJ0d28iPgogICAgICAgICAgPGJ1 dHRvbiBpZD0idHdvIj5TZWNvbmQ8L2J1dHRvbj4KICAgICAgICAgIDxidXR0b24gaWQ9InRocmVl Ij5UaGlyZDwvYnV0dG9uPgogICAgICAgICAgPGJ1dHRvbiBpZD0iZm91ciI+Rm91cnRoPC9idXR0 b24+CiAgICAgICAgPC9kaXY+CiAgICAgICAgPGRpdiBjbGFzcz0idGhyZWUiPjxidXR0b24gaWQ9 ImZpdmUiPkZpZnRoPC9idXR0b24+PC9kaXY+CiAgICAgICAgPGRpdiBjbGFzcz0iZm91ciI+CiAg ICAgICAgICA8YnV0dG9uIGlkPSJ0d28iPlNpeHRoPC9idXR0b24+CiAgICAgICAgICA8YnV0dG9u IGlkPSJ0aHJlZSI+U2V2ZW50aDwvYnV0dG9uPgogICAgICAgICAgPGJ1dHRvbiBpZD0iZm91ciI+ RWlndGg8L2J1dHRvbj4KICAgICAgICA8L2Rpdj4KICAgICAgICA8ZGl2IGNsYXNzPSJmaXZlIj4K ICAgICAgICAgIDxidXR0b24gaWQ9Im5pbmUiPk5pbnRoPC9idXR0b24+PC9kaXY+CiAgICAgICAg PC9kaXY+CiAgICAgIDwvZGl2PgogICAgPC9ib2R5Pgo8L2h0bWw+Cg==