- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 30 Jan 2025 23:14:06 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-display-4] reading-flow and mix of auto-flow and explicit items `, and agreed to the following: * `RESOLVED: Resolution to restore previous reading order property and use it as a starting point for reading order flow.` * `RESOLVED: as a starting point, define that if the reading order of 2 items is equivalent, reading flow breaks the tie` <details><summary>The full IRC log of that discussion</summary> <nicole> Reading flow and the mix of outflow and explicit items<br> <nicole> asterns: limit to necessary for HTML folks to progress<br> <nicole> Rachel: Some items you want to choose position and mix of autoplaced items. How does reading flow work with that<br> <nicole> Rachel: probably by applying it to the container and children. Which we originally discussed and decided not to do<br> <ydaniv> s/asterns:/astearns:/<br> <nicole> rachelandrew: a bit like order, but only affects reading flow<br> <nicole> fantasai: works find for explicit source order<br> <astearns> s/find/fine/<br> <nicole> fantasai: simple example of mixed - a masonry layout with a sidebar. Title, nav, etc. Positioned on right aesthetically<br> <nicole> fantasai: would be 5th rather than 1st<br> <florian> q+<br> <nicole> rachelanderew: do we fix it now or in the future. Are we leaving the door open to other solutions. How does it impact the HTML spec? Otherwise not urgent, but necessary<br> <nicole> rachelandrew: would reading flow container also encompass this situation?<br> <astearns> ack florian<br> <nicole> florian: we want this now. Removed because we started with only explicit ordering, was a bad solution. Overall solution combo of 2<br> <nicole> florian: general scheme on container<br> <nicole> florian: override on children<br> <nicole> florian: design of thing that applies to container should account for being able to override children<br> <nicole> florian: so both pieces work together<br> <fantasai> s/so both/design both together so both/<br> <nicole> rachelandrew: reasonable, can bring this back. Identified use cases they hadn't considered before. Good to bring it back to spec. Also bike shed name. Does it affect HTML implementation<br> <astearns> ack fantasai<br> <nicole> rachelandrew: Probably doesn't, since it is just a different way of doing ordering<br> <Di> q+<br> <nicole> fantasai: set of items, here is order, tells HTML to do the rest. HTML spec shouldn't change. Reading flow, reading order, and ____ will provide input to HTML<br> <astearns> ack Di<br> <fantasai> s/___/things like dense packing/<br> <nicole> di: HTML side is reading flow container, shouldn't override it. Should be fine for the hTML spec<br> <nicole> asterns: design as a whole rather than piecemeal<br> <nicole> di: agree<br> <nicole> astearns: Resolution to restore previous reading order property and use it as a starting point for reading order flow.<br> <astearns> ack fantasai<br> <TabAtkins> +1<br> <nicole> fantasai: as a starting point, define that if the reading order of 2 items is equivalent, reading flow breaks the tie<br> <nicole> RESOLVED: Resolution to restore previous reading order property and use it as a starting point for reading order flow.<br> <nicole> RESOLVED: as a starting point, define that if the reading order of 2 items is equivalent, reading flow breaks the tie<br> <dbaron> is there a new condition that it only works in reading order containers?<br> <nicole> astearns: David can you raise an issue?<br> <nicole> fantasai: does the reading order prop only impact reading order containers or does attempting to use reading flow or order cause it to become a reading order container<br> <nicole> rachelanderew: masonry is an exception, but for everything else you'd need to say on the container<br> <dbaron> (I was just asking that to try to ensure the resolutions capture stuff that was said earlier in the discussion.)<br> <dbaron> Present-<br> <nicole> fantasai: default order is source order. HTML needs a concept of is it a reading order container, must be yes to do reordering. If it has a non initial value on any child than the container needs to be a reading flow container. From css user perspective, either do it auto or make them change something else<br> <nicole> racheandrew: prefers explicit, like flexbox<br> <nicole> rachelandrew: always positive, this is a reading flow container, so they know they are reordering. Doing it by accident without thinking would be bad<br> <astearns> notes that the explicit container may not only be due to reading-flow being set explicitly, if the default value creates reading flow containers for some layout modes<br> <nicole> fantasai: not sure. Cases where we do want to double opt in. Other cases where the child can decide on their own<br> <dbaron> (from my own perspective I might ask whether we want a more complicated name so it doesn't look like reading-order is a simpler thing than reading-order-items)<br> <nicole> fantasai: for example z index is just the child<br> <fantasai> we renamed reading-order-items to reading-flow<br> <fantasai> dbaron: ^<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11208#issuecomment-2625850559 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 30 January 2025 23:14:07 UTC