- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Mon, 13 Mar 2023 15:04:59 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-display-4] Define 'reading-order: auto' #7387`, and agreed to the following:
* `RESOLVED: Land the PR, after addressing pending feedback.`
<details><summary>The full IRC log of that discussion</summary>
<TabAtkins> rachelandrew: reading order for grid and flex<br>
<TabAtkins> rachelandrew: elika wrote in the spec edits for reading-order:<integer><br>
<TabAtkins> rachelandrew: Lets you change the order relative tot he dom<br>
<TabAtkins> rachelandrew: and "auto" which only works for things that are "randomized" layout, like dense-order packing<br>
<TabAtkins> rachelandrew: Where the author can't predict ahead of time what the order is<br>
<TabAtkins> rachelandrew: As I was writing an article for dev feedback, it was very obvious that for most things we just need reading-order:auto on the children<br>
<TabAtkins> rachelandrew: And make it apply to all layout methods<br>
<TabAtkins> rachelandrew: If they wanted order to follow layout order, if children have "auto" this happens<br>
<TabAtkins> rachelandrew: Elika doesn't want this bc she doesn't want to make it too easy for devs to do this (setting layout order rather than changing dom order)<br>
<TabAtkins> rachelandrew: But it seems v obvious that we'll be making things ergonomically difficult<br>
<TabAtkins> rachelandrew: Seems a bit odd, want to make sure we really do intend that.<br>
<TabAtkins> fantasai: I haven't seen your examples, so less context, but<br>
<TabAtkins> fantasai: The thing I'm concerned with is devs won't think about speec order, just set `* { reading-order:auto }` and think they've solved the problem<br>
<TabAtkins> fantasai: But this doesn't actually use the right behaviors in many cases<br>
<TabAtkins> fantasai: Many cases where people reorder source in order to get the speech order and layout order to be different on purpose, bc the two perceive the document differently<br>
<TabAtkins> fantasai: For example, an image and a heading, you want the image above the heading in layout, you want th eheading first in source<br>
<TabAtkins> fantasai: So the reason we added 'order' was to enable that case specifically, not to enable "can sort anything with the 'order' property"<br>
<TabAtkins> rachelandrew: Those cases are handled by "order" already, as long as you don't set r-o:auto<br>
<TabAtkins> fantasai: Yeah, my concern is just that people will set it on "*" in their stylesheet<br>
<fremy> q+<br>
<TabAtkins> rachelandrew: Are those people already failing to do this stuff correctly?<br>
<TabAtkins> fantasai: I think there are people who care about a11y but not deeply, and will learn a best practice is to set it everywhere<br>
<TabAtkins> rachelandrew: We can publish agaisnt that.<br>
<TabAtkins> rachelandrew: My concern is that we're adding complexity just to prevent things<br>
<TabAtkins> rachelandrew: Another concern is that if we say "auto" is only for random layouts we can't change that in the future; while we were just integers it was still open.<br>
<TabAtkins> fantasai: I'm fine with adding a different keyword for randomized layout and using "auto" for this purpose.<br>
<iank_> q+<br>
<astearns> ack fremy<br>
<TabAtkins> fremy: I think I agree it doesn't make sense for "auto" to not use layout info when you can. I think it'll be what people want most of the time.<br>
<TabAtkins> fremy: I disagree it can be used for everything. For grid there's no obvious reading order, mentioned in the issue<br>
<TabAtkins> fremy: "auto" makes it seem like there's always an obvious choice<br>
<TabAtkins> fremy: We can't ask authors to add 1, 2, 3, etc; can't do that with an unknown number of elements.<br>
<TabAtkins> fremy: I think this needs a more specific proposal for layout-by-layout.<br>
<TabAtkins> fremy: So I don't think it makes a lot of sense for grid, don't buy that "you just need auto" is true<br>
<TabAtkins> rachelandrew: I think more work is needed, but - what I'd like is more feedback from devs.<br>
<TabAtkins> rachelandrew: Atm we'll be asking for feedback with a suggested spec that is making things difficult, that might affect the feedback.<br>
<TabAtkins> rachelandrew: There were def issues around flex-direction, for example<br>
<astearns> ack iank_<br>
<TabAtkins> rachelandrew: But we couldn't think of use-cases where using "auto" didn't work, when discussing it with Chrishtr and others.<br>
<TabAtkins> iank_: as-is, with integer value, it's not really adding value to webdevs<br>
<TabAtkins> iank_: Don't think people will actively use it<br>
<TabAtkins> astearns: next steps?<br>
<TabAtkins> fantasai: I'd like to pull rachel's discussion out of the PR and into an issue<br>
<TabAtkins> fantasai: The PR was about following up what was already resolved, just needed Oriol's review on technical aspects.<br>
<TabAtkins> fantasai: So I'd like to land Oriol's feedback, and discuss additional changes in an issue.<br>
<TabAtkins> fantasai: Havne't looked at Rachel's article so don't have the same context<br>
<florian> q?<br>
<TabAtkins> fantasai: But I am def concerned that there will be articles saying "just use 'auto' to handle speech"<br>
<TabAtkins> florian: Seems fremy's direction wouldn't take us there - if we have several autoish values there's no single answer to rely on.<br>
<TabAtkins> iank_: And in flexbox you sometimes want opposite order for reading. For grid, could want column-major and row-major.<br>
<TabAtkins> iank_: So there are some high-level directionalities for particular layouts.<br>
<TabAtkins> florian: Also the overlapping capabilities of grid pose possibilities.<br>
<TabAtkins> florian: Dunno if we need to expose all of them with keywords, but shoudl think thru it<br>
<TabAtkins> astearns: Rachel would you be okay landing this PR and opening an issue?<br>
<TabAtkins> astearns: So resolution today is accept this PR once Oriol's concerns are handled?<br>
<TabAtkins> fantasai: Yeah, wanna address Oriol's concerns.<br>
<TabAtkins> florian: Want to inline an issue into the PR saying "auto" name can change?<br>
<TabAtkins> fantasai: Yeah, can do, pointing at RAchel's issue. Might be redesigning the feature, rathe rthan just renaming<br>
<TabAtkins> astearns: So resolution is we land this PR after addressing feedback<br>
<TabAtkins> RESOLVED: Land the PR, after addressing pending feedback.<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/pull/8257#issuecomment-1466323645 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 13 March 2023 15:05:01 UTC