- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 30 Jan 2025 20:00:24 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed ``[css-display-4] Initial value of `reading-flow` ``, and agreed to the following: * `RESOLVED: HTML should depend on the *presence* of a reading flow container, but defer to CSS about exactly what causes that.` <details><summary>The full IRC log of that discussion</summary> <TabAtkins> rachelandrew: this bunch of issues... a lot rely on masonry<br> <TabAtkins> rachelandrew: we have an open PR for the html spec<br> <TabAtkins> rachelandrew: we're trying to get to whether these outstanding issues are liekly to change the html changes<br> <rachelandrew> https://github.com/w3c/csswg-drafts/issues/11328<br> <TabAtkins> rachelandrew: we might just resolve that it's probably not going to change the API shape<br> <TabAtkins> rachelandrew: for this first one, the initial value fo reading-flow<br> <TabAtkins> rachelandrew: in general "normal" means behaving as we do now, tab order follows the dom<br> <TabAtkins> rachelandrew: we ahve automatic layout methods, like grid-auto-flow dense that can fill in gaps, masonry can similarly have funky ordering<br> <TabAtkins> rachelandrew: with these, it kinda feels like we'd want to go with the visual ordering instead of source as a default<br> <TabAtkins> rachelandrew: so that's the question here - do we think that's a good idea?<br> <TabAtkins> rachelandrew: probably means with masonry we'd have a masonry-flow value for the property<br> <TabAtkins> rachelandrew: dense grid might cause some compat issue, but you probably already don't care abou thte osurce order since you dont' have much control over it<br> <TabAtkins> rachelandrew: and then we'd need a value to explicitly opt back into source ordering<br> <astearns> ack fantasai<br> <TabAtkins> fantasai: i think one of the key questions for html integration is, do we envision cases wher edefault ordering isn't he source order<br> <TabAtkins> fantasai: html spec is currently written with a binary change - if you do reordering, THIS happens, if not, THAT happens<br> <TabAtkins> fantasai: if the default behavior reorders, we can't go down the reordering path<br> <TabAtkins> fantasai: even if you don't actually change the order of anything, the behavior changes<br> <TabAtkins> rachelandrew: yes, it means if you didn't do any actual reordering you'd be in this slightly changed state<br> <TabAtkins> rachelandrew: but not sure why that makes a huge difference if it's initial or not<br> <TabAtkins> fantasai: there's a scoping of tab navigation that happens if you're in the reordering version<br> <TabAtkins> fantasai: we can't just turn that on for everything all the time<br> <TabAtkins> rachelandrew: it's not all the time, the proposal is it only does visual order *for these intrinsically reordered display modes*<br> <TabAtkins> fantasai: okay, might make sense. right now HTML relies on initial value to know whethe ror not to do the thing; need to isntead rely on a CSS concept of if it *is* reordered.<br> <TabAtkins> (is being reordered, that is, whether the order actually chages or not)<br> <TabAtkins> fantasai: I think dense packing might be the trickiest case...<br> <TabAtkins> fantasai: if you have a collection that's dense packed, most of the time you dont' care about specific order<br> <TabAtkins> fantasai: but if you're doing a combo layout where parts are epxlicitly and the rest are dense packed, you might really care about where the explicit items are in reading order<br> <TabAtkins> fantasai: and want them in source order, but not care about the auto placed ones<br> <TabAtkins> rachelandrew: i think that's bleeding into the next issue<br> <TabAtkins> rachelandrew: whether we change the default behavior is a different issue<br> <TabAtkins> rachelandrew: we could decide dense grid has sailed and can't change the default, but that's still separate<br> <TabAtkins> fantasai: i think it interrelates somewhat. if we ahve a lot of those cases it's a compat issue.<br> <TabAtkins> fantasai: so like if the order matches the standard order, we treat it as not reordered. maybe that's less problematic<br> <TabAtkins> rachelandrew: I think we need to make sure this concept that HTML is relying on is defined in CSS, not just looking at the initial value<br> <TabAtkins> Di: I think that makes sense<br> <TabAtkins> Di: I think in HTML right now we're only caring about whether or not there is a reading-flow container, so this wouldn't change much on the html side<br> <TabAtkins> Di: on elika's question about order being the same between stadnard and reordered, cna't think of a way to do that<br> <TabAtkins> fantasai: i think it would be good to restrict the extra behavior to the parts that are reordered, fi there are any<br> <TabAtkins> fantasai: currently if you *might* be reordering things, you get it on all the places<br> <TabAtkins> (i disagree)<br> <TabAtkins> fantasai: might be better to instead only get the scoping changes on the parts that are reordered<br> <TabAtkins> q+<br> <emilio> TabAtkins: I disagree<br> <emilio> ... I don't think we want to have different behavior on elements in the same reading-flow container<br> <emilio> ... depending on whether has moved<br> <emilio> ... moved is confusing, if you swap #2 and #3, which one of them moved?<br> <emilio> fantasai: both<br> <fantasai> 1 2 3 4 5 vs 1 2 4 3 5 => 3 & 4 moved (don't match their original positions)<br> <emilio> TabAtkins: generally having the scoping be different in the same container, where the container is what controls it, seems off<br> <emilio> ... the specific case where there's a dense grid when some things are placed and others auto-placed<br> <emilio> ... seems like that could be achieved by having a default reading flow value for grid that achieves that<br> <TabAtkins> (3&4 being the moved elements is *not* obvious. It's exactly as possible that 3&5 are the ones that moved, just both moved *after* 4 and happened to maintain their releative order)<br> <TabAtkins> astearns: should we decide on just for masonry?<br> <TabAtkins> fantasai: that's not defined yet<br> <TabAtkins> astearns: we already have values that opt you into visual order.<br> <TabAtkins> astearns: if we dont' have an algo for that, we need that anyway, so we're not adding additional difficulty.<br> <TabAtkins> rachelandrew: there's a lot that falls out of this that needs to be decided on an individual layout basis<br> <TabAtkins> rachelandrew: q is jsut whether this is only a css issue, not an html, or both<br> <TabAtkins> rachelandrew: i think it's just css. html should only be considered with whether there is a reading flow container, regardless of whether that's from an initial value (+ othe rproperties) or an explicitly set reading-flow value<br> <TabAtkins> rachelandrew: so hopefully we can resolve on that part<br> <TabAtkins> TabAtkins: so proposed resolution: HTML should depend on teh *presence* of a reading flow container, regardless of how CSS defines that to come aobut<br> <florian> q+<br> <TabAtkins> q-<br> <florian> q-<br> <TabAtkins> astearns: objections?<br> <TabAtkins> RESOLVED: HTML should depend on the *presence* of a reading flow container, but defer to CSS about exactly what causes that.<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11396#issuecomment-2625453369 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 20:00:25 UTC