Re: [csswg-drafts] [css-display-4] Do we need `reading-order: <integer>` or should `reading-order: auto` be allowable in all grid or flex layouts? (#8589)

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>
&lt;TabAtkins> rachelandrew: WE're trying to solve a problem with flex and grid<br>
&lt;TabAtkins> rachelandrew: Devs can easily jumble up the order of things, reading and visual order different from the DOM<br>
&lt;TabAtkins> rachelandrew: But DOM order is used by tabbing/etc<br>
&lt;TabAtkins> rachelandrew: It's usually correct to tell authors to make the DOM order match the visual order<br>
&lt;TabAtkins> rachelandrew: There are some cases where it doesn't tho<br>
&lt;TabAtkins> rachelandrew: Like, responsive design - optimal reading order in one presentation is different from optimal order in another<br>
&lt;TabAtkins> rachelandrew: So people want to shuffle things by MQ<br>
&lt;TabAtkins> rachelandrew: We're tyring to solve this by letting authors specify the reading order, when it's differetn from the DOM<br>
&lt;TabAtkins> rachelandrew: This particular issue, elika proposed a `reading-order: &lt;integer>`<br>
&lt;TabAtkins> rachelandrew: This would specifically set the reading order to match<br>
&lt;TabAtkins> rachelandrew: As we worked thru the use-cases we realized devs probably didn't need it<br>
&lt;TabAtkins> rachelandrew: Instsead they just want "follow the flex layout" or "follow the grid layout"<br>
&lt;TabAtkins> rachelandrew: But there are still some switches on that<br>
&lt;TabAtkins> rachelandrew: So here Tab proposed to remove the integer and instead have `reading-order-items: normal | flex [ visual | flow ] | grid [ rows | columns ]`<br>
&lt;TabAtkins> rachelandrew: I think this covers all the use-cases<br>
&lt;TabAtkins> rachelandrew: I think it also wouldn't stop us from doing the integer in the future<br>
&lt;TabAtkins> rachelandrew: If we realize we need it<br>
&lt;TabAtkins> rachelandrew: So issue is, can we resolve to drop the integer and just use reading-order-items?<br>
&lt;TabAtkins> q+<br>
&lt;TabAtkins> Janina: Interesting! Sounds like we might get our cake and eat it too.<br>
&lt;TabAtkins> Janina: previous discussions entangled benefits of various ways to handle it, without solving things<br>
&lt;TabAtkins> rachelandrew: I think so, it keeps things in CSS<br>
&lt;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>
&lt;matatk> q?<br>
&lt;TabAtkins> matatk: Did you say default is DOM order, that's what normal does?<br>
&lt;TabAtkins> rachelandrew: yes<br>
&lt;TabAtkins> matatk: There's usually an auto value, why not here?<br>
&lt;TabAtkins> astearns: One reason for normal vs auto is normal often has a single default behavior, while auto responds to various things<br>
&lt;TabAtkins> astearns: So someone might interpret auto to mean "if I have a grid, do grid order"<br>
&lt;astearns> ack TabAtkins<br>
&lt;emeyer> TabAtkins: I think this is fine but there’s a necessary followup issue<br>
&lt;emeyer> …We resolved that if you display: contents an A, the things inside A should still be tabbable<br>
&lt;emeyer> …That interacts badly with the non-normal values here<br>
&lt;emeyer> …We need to define something to fix that<br>
&lt;emeyer> …I suggest the right answer is it should be put after either first or last in DOM order<br>
&lt;emeyer> …If we need something more later, we could add integer back in<br>
&lt;ydaniv> q+<br>
&lt;TabAtkins> matatk: I think with any of these technical things, Paul is our css expert. Paul hasn't commented on this issue.<br>
&lt;TabAtkins> matatk: I'd feel better getting his opinion on it<br>
&lt;TabAtkins> matatk: But the general principle feels good - the author can choose a sensible layout<br>
&lt;astearns> ack ydaniv<br>
&lt;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>
&lt;TabAtkins> ydaniv: I'm a bit confused about the syntax<br>
&lt;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>
&lt;TabAtkins> rachelandrew: I think it just wouldn't apply?<br>
&lt;TabAtkins> TabAtkins: Yeah I think it would just act like normal<br>
&lt;TabAtkins> astearns: So all the non-normal values would just not apply if they're not in the right layout context<br>
&lt;TabAtkins> rachelandrew: Similar to alignment, yeah<br>
&lt;TabAtkins> ydaniv: But doesn't the element already know the context?<br>
&lt;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>
&lt;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>
&lt;TabAtkins> astearns: So there are cases where grid layout should not be the reading order<br>
&lt;emilio> q+<br>
&lt;TabAtkins> rachelandrew: I think the intentionality is really specific to this, you<br>
&lt;emeyer> TabAtkins: The m ore targeted answer is that we don’t have one correct behavior for flex, or for grid<br>
&lt;emeyer> …I don’t think we can generally assume what the values imply<br>
&lt;astearns> ack emeyer<br>
&lt;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>
&lt;astearns> ack emilio<br>
&lt;TabAtkins> emilio: The idea is that this modifies taborder<br>
&lt;TabAtkins> emeyer: Do we ahve use-cases for a11y reorder, but not taborder?<br>
&lt;emeyer> s/emeyer/emilio/<br>
&lt;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>
&lt;TabAtkins> rachelandrew: i haven't been able to come up with any use-cases either<br>
&lt;astearns> ack fantasai<br>
&lt;TabAtkins> fantasai: I think there's a little bit more going on here.<br>
&lt;TabAtkins> fantasai: Multiple ways to cause reordering to happen in grid<br>
&lt;TabAtkins> fantasai: grid-auto-flow which controls how auto-placed items get palced (row or column, and probably reversible in the future)<br>
&lt;TabAtkins> fantasai: Also the 'order' property<br>
&lt;TabAtkins> fantasai: And lastly there's the visual/coordinate order with explicit placement<br>
&lt;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>
&lt;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>
&lt;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>
&lt;TabAtkins> fantasai: Might want to follow auto-flow but also 'order' is purely a visual effect<br>
&lt;TabAtkins> rachelandrew: I feel like if we came across those cases where author needs to be able to specify all of them<br>
&lt;TabAtkins> rachelandrew: I don't know if integer would solve those cases anyway<br>
&lt;TabAtkins> rachelandrew: And generally I only see people doing that when they've made a mistake<br>
&lt;florian> q+<br>
&lt;TabAtkins> rachelandrew: So I think we might bea ble to find edge cases where it doesn't support<br>
&lt;TabAtkins> rachelandrew: But if we find them and decide we need to fix them, we're not blocked from fixing them<br>
&lt;TabAtkins> rachelandrew: But the stuff I'm being asked about by devs is very simple<br>
&lt;TabAtkins> rachelandrew: They just want reading order "correct" so they can swap placement between mobile and desktop<br>
&lt;TabAtkins> rachelandrew: And what we have here will enable those. We can address more cases as we realize we need it.<br>
&lt;astearns> ack florian<br>
&lt;TabAtkins> I think th ecurrent grammar is plenty extnesible, too<br>
&lt;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>
&lt;TabAtkins> florian: For typical patterns<br>
&lt;TabAtkins> florian: If we find more atypical patterns we can do an escape, but we're not there yet<br>
&lt;TabAtkins> florian: Speculating on the atypical patterns today won't be too instructive<br>
&lt;TabAtkins> Janina: I find this encouragin, we've been wrestling with it for a while<br>
&lt;TabAtkins> astearns: So proposed resolution is we drop reading-order:&lt;integer> and go with reading-order-items with the values proposed in TAb's comment (for now)<br>
&lt;TabAtkins> fantasai: I think it's fine to draft it up<br>
&lt;TabAtkins> fantasai: I don't know I'm confident this is definitely the way to go<br>
&lt;TabAtkins> fantasai: So let's draft it into the ED, I'm just not 100% it's how we want to finish<br>
&lt;TabAtkins> fantasai: I don't like it to imply that this is what we're going for definitely<br>
&lt;TabAtkins> rachelandrew: I think we do need something firm to start moving forward on<br>
&lt;fantasai> proposal: Draft reading-order-items into the ED for css-display-5<br>
&lt;TabAtkins> rachelandrew: We're not blocking the integer method<br>
&lt;TabAtkins> astearns: and drop reading-order:&lt;integer> for now?<br>
&lt;TabAtkins> fantasai: I guess so<br>
&lt;TabAtkins> astearns: So proposed resolution is to add reading-order-items into the ED and remove reading-order:&lt;integer><br>
&lt;TabAtkins> astearns: Objections?<br>
&lt;TabAtkins> RESOLVED: add reading-order-items into the ED and remove reading-order:&lt;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