- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Fri, 15 Sep 2023 15:53:19 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed ``[css-display-4] Do we need `reading-order: <integer>` or should `reading-order: auto` be allowable in all grid or flex layouts?``, and agreed to the following: * `RESOLVED: add reading-order-items into the ED and remove reading-order:<integer>` <details><summary>The full IRC log of that discussion</summary> <TabAtkins> rachelandrew: WE're trying to solve a problem with flex and grid<br> <TabAtkins> rachelandrew: Devs can easily jumble up the order of things, reading and visual order different from the DOM<br> <TabAtkins> rachelandrew: But DOM order is used by tabbing/etc<br> <TabAtkins> rachelandrew: It's usually correct to tell authors to make the DOM order match the visual order<br> <TabAtkins> rachelandrew: There are some cases where it doesn't tho<br> <TabAtkins> rachelandrew: Like, responsive design - optimal reading order in one presentation is different from optimal order in another<br> <TabAtkins> rachelandrew: So people want to shuffle things by MQ<br> <TabAtkins> rachelandrew: We're tyring to solve this by letting authors specify the reading order, when it's differetn from the DOM<br> <TabAtkins> rachelandrew: This particular issue, elika proposed a `reading-order: <integer>`<br> <TabAtkins> rachelandrew: This would specifically set the reading order to match<br> <TabAtkins> rachelandrew: As we worked thru the use-cases we realized devs probably didn't need it<br> <TabAtkins> rachelandrew: Instsead they just want "follow the flex layout" or "follow the grid layout"<br> <TabAtkins> rachelandrew: But there are still some switches on that<br> <TabAtkins> rachelandrew: So here Tab proposed to remove the integer and instead have `reading-order-items: normal | flex [ visual | flow ] | grid [ rows | columns ]`<br> <TabAtkins> rachelandrew: I think this covers all the use-cases<br> <TabAtkins> rachelandrew: I think it also wouldn't stop us from doing the integer in the future<br> <TabAtkins> rachelandrew: If we realize we need it<br> <TabAtkins> rachelandrew: So issue is, can we resolve to drop the integer and just use reading-order-items?<br> <TabAtkins> q+<br> <TabAtkins> Janina: Interesting! Sounds like we might get our cake and eat it too.<br> <TabAtkins> Janina: previous discussions entangled benefits of various ways to handle it, without solving things<br> <TabAtkins> rachelandrew: I think so, it keeps things in CSS<br> <TabAtkins> rachelandrew: With flex and grid layout you *know* you're changing the order. Layout itself can change it. So you know you're doing it, and can trigger reading-order-items<br> <matatk> q?<br> <TabAtkins> matatk: Did you say default is DOM order, that's what normal does?<br> <TabAtkins> rachelandrew: yes<br> <TabAtkins> matatk: There's usually an auto value, why not here?<br> <TabAtkins> astearns: One reason for normal vs auto is normal often has a single default behavior, while auto responds to various things<br> <TabAtkins> astearns: So someone might interpret auto to mean "if I have a grid, do grid order"<br> <astearns> ack TabAtkins<br> <emeyer> TabAtkins: I think this is fine but there’s a necessary followup issue<br> <emeyer> …We resolved that if you display: contents an A, the things inside A should still be tabbable<br> <emeyer> …That interacts badly with the non-normal values here<br> <emeyer> …We need to define something to fix that<br> <emeyer> …I suggest the right answer is it should be put after either first or last in DOM order<br> <emeyer> …If we need something more later, we could add integer back in<br> <ydaniv> q+<br> <TabAtkins> matatk: I think with any of these technical things, Paul is our css expert. Paul hasn't commented on this issue.<br> <TabAtkins> matatk: I'd feel better getting his opinion on it<br> <TabAtkins> matatk: But the general principle feels good - the author can choose a sensible layout<br> <astearns> ack ydaniv<br> <TabAtkins> matatk: And we definitely don't encourage people to use positive tabindex values - we all know why - so this sounds good in general<br> <TabAtkins> ydaniv: I'm a bit confused about the syntax<br> <TabAtkins> ydaniv: If you end up with a grid layout, and the dev specifies flex, what would that do? would we want 'auto' instead?<br> <TabAtkins> rachelandrew: I think it just wouldn't apply?<br> <TabAtkins> TabAtkins: Yeah I think it would just act like normal<br> <TabAtkins> astearns: So all the non-normal values would just not apply if they're not in the right layout context<br> <TabAtkins> rachelandrew: Similar to alignment, yeah<br> <TabAtkins> ydaniv: But doesn't the element already know the context?<br> <jensimmons> There's a good question there, though. Why do `grid`, `flex`, etc, instead of having values like `layout` — where the browser knows whether it should be grid layout or flex layout.<br> <TabAtkins> astearns: Rachel can elaborate, but I think the idea is that normal's the default, but it's not always the case that the visual reordering in a grid layout is appropraite for the a11y tree<br> <TabAtkins> astearns: So there are cases where grid layout should not be the reading order<br> <emilio> q+<br> <TabAtkins> rachelandrew: I think the intentionality is really specific to this, you<br> <emeyer> TabAtkins: The m ore targeted answer is that we don’t have one correct behavior for flex, or for grid<br> <emeyer> …I don’t think we can generally assume what the values imply<br> <astearns> ack emeyer<br> <emeyer> …Either of the cases for grid are common enough, and the results of getting it wrong bad enough, should require authors to say what they want<br> <astearns> ack emilio<br> <TabAtkins> emilio: The idea is that this modifies taborder<br> <TabAtkins> emeyer: Do we ahve use-cases for a11y reorder, but not taborder?<br> <emeyer> s/emeyer/emilio/<br> <TabAtkins> fantasai: I don't think so, I think we resolve a while ago that reading order and tab order should be in sync<br> <TabAtkins> rachelandrew: i haven't been able to come up with any use-cases either<br> <astearns> ack fantasai<br> <TabAtkins> fantasai: I think there's a little bit more going on here.<br> <TabAtkins> fantasai: Multiple ways to cause reordering to happen in grid<br> <TabAtkins> fantasai: grid-auto-flow which controls how auto-placed items get palced (row or column, and probably reversible in the future)<br> <TabAtkins> fantasai: Also the 'order' property<br> <TabAtkins> fantasai: And lastly there's the visual/coordinate order with explicit placement<br> <TabAtkins> fantasai: I think it's quite reasonable you'll have a grid where you are mixing some of these mechanism, some auto-placed items and some explicitly placed<br> <TabAtkins> fantasai: And depending on how you're performing these, you may or may not want to follow the "visual order" - the writing-mode order I'll say, ltr, ttb for english<br> <TabAtkins> fantasai: So there can be a mix of things that can happen and i think we're maybe not addressing what happens in these complex bits<br> <TabAtkins> fantasai: Might want to follow auto-flow but also 'order' is purely a visual effect<br> <TabAtkins> rachelandrew: I feel like if we came across those cases where author needs to be able to specify all of them<br> <TabAtkins> rachelandrew: I don't know if integer would solve those cases anyway<br> <TabAtkins> rachelandrew: And generally I only see people doing that when they've made a mistake<br> <florian> q+<br> <TabAtkins> rachelandrew: So I think we might bea ble to find edge cases where it doesn't support<br> <TabAtkins> rachelandrew: But if we find them and decide we need to fix them, we're not blocked from fixing them<br> <TabAtkins> rachelandrew: But the stuff I'm being asked about by devs is very simple<br> <TabAtkins> rachelandrew: They just want reading order "correct" so they can swap placement between mobile and desktop<br> <TabAtkins> rachelandrew: And what we have here will enable those. We can address more cases as we realize we need it.<br> <astearns> ack florian<br> <TabAtkins> I think th ecurrent grammar is plenty extnesible, too<br> <TabAtkins> florian: I think the high level takeaway is we're giving a switch telling the browser what mode it's in to traverse<br> <TabAtkins> florian: For typical patterns<br> <TabAtkins> florian: If we find more atypical patterns we can do an escape, but we're not there yet<br> <TabAtkins> florian: Speculating on the atypical patterns today won't be too instructive<br> <TabAtkins> Janina: I find this encouragin, we've been wrestling with it for a while<br> <TabAtkins> astearns: So proposed resolution is we drop reading-order:<integer> and go with reading-order-items with the values proposed in TAb's comment (for now)<br> <TabAtkins> fantasai: I think it's fine to draft it up<br> <TabAtkins> fantasai: I don't know I'm confident this is definitely the way to go<br> <TabAtkins> fantasai: So let's draft it into the ED, I'm just not 100% it's how we want to finish<br> <TabAtkins> fantasai: I don't like it to imply that this is what we're going for definitely<br> <TabAtkins> rachelandrew: I think we do need something firm to start moving forward on<br> <fantasai> proposal: Draft reading-order-items into the ED for css-display-5<br> <TabAtkins> rachelandrew: We're not blocking the integer method<br> <TabAtkins> astearns: and drop reading-order:<integer> for now?<br> <TabAtkins> fantasai: I guess so<br> <TabAtkins> astearns: So proposed resolution is to add reading-order-items into the ED and remove reading-order:<integer><br> <TabAtkins> astearns: Objections?<br> <TabAtkins> RESOLVED: add reading-order-items into the ED and remove reading-order:<integer><br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8589#issuecomment-1721504153 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 15 September 2023 15:53:21 UTC