[css-display-4] Initial value of reading-flow

[fantasai]

We had in the past discussed the possibility of the initial value of reading-flow handling some things automatically, e.g. dense packing in Grid or maybe some aspects of Masonry layout. (In that case we'd add an additional keyword to represent strict source ordering.) Opening this issue to track that question.

[rachelandrew]

By automatically, I'm assuming that the default behavior of grid-auto-flow: dense and masonry layout or using would be to follow the 'visual' order, rather than source order.

Given that masonry is new, there wouldn't be an issue there as we could define the behavior from the outset. I outlined some thoughts for the masonry/reading-flow interactions in this issue. Having automatic behavior would I think mean we needed to have the behavior more like flex, and have a masonry-flow value as the behavior of normal in masonry layouts.

Changing the defaults for dense packing might cause a compat issue. My gut feeling tells me that where people have used dense packing they aren't too worried about the ordering, given that you essentially lose control of it anyway, but we probably need to look into it. The default would likely need to follow the grid-auto-flow direction (so reading-flow: grid-rows for grid-auto-flow: row dense).

I think in both cases adding a keyword to reading-flow (perhaps source) to reset it would be needed.

[css-meeting-bot]

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.

The full IRC log of that discussion

<TabAtkins> rachelandrew: this bunch of issues... a lot rely on masonry
<TabAtkins> rachelandrew: we have an open PR for the html spec
<TabAtkins> rachelandrew: we're trying to get to whether these outstanding issues are liekly to change the html changes
<rachelandrew> https://github.com//issues/11328
<TabAtkins> rachelandrew: we might just resolve that it's probably not going to change the API shape
<TabAtkins> rachelandrew: for this first one, the initial value fo reading-flow
<TabAtkins> rachelandrew: in general "normal" means behaving as we do now, tab order follows the dom
<TabAtkins> rachelandrew: we ahve automatic layout methods, like grid-auto-flow dense that can fill in gaps, masonry can similarly have funky ordering
<TabAtkins> rachelandrew: with these, it kinda feels like we'd want to go with the visual ordering instead of source as a default
<TabAtkins> rachelandrew: so that's the question here - do we think that's a good idea?
<TabAtkins> rachelandrew: probably means with masonry we'd have a masonry-flow value for the property
<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
<TabAtkins> rachelandrew: and then we'd need a value to explicitly opt back into source ordering
<astearns> ack fantasai
<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
<TabAtkins> fantasai: html spec is currently written with a binary change - if you do reordering, THIS happens, if not, THAT happens
<TabAtkins> fantasai: if the default behavior reorders, we can't go down the reordering path
<TabAtkins> fantasai: even if you don't actually change the order of anything, the behavior changes
<TabAtkins> rachelandrew: yes, it means if you didn't do any actual reordering you'd be in this slightly changed state
<TabAtkins> rachelandrew: but not sure why that makes a huge difference if it's initial or not
<TabAtkins> fantasai: there's a scoping of tab navigation that happens if you're in the reordering version
<TabAtkins> fantasai: we can't just turn that on for everything all the time
<TabAtkins> rachelandrew: it's not all the time, the proposal is it only does visual order *for these intrinsically reordered display modes*
<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.
<TabAtkins> (is being reordered, that is, whether the order actually chages or not)
<TabAtkins> fantasai: I think dense packing might be the trickiest case...
<TabAtkins> fantasai: if you have a collection that's dense packed, most of the time you dont' care about specific order
<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
<TabAtkins> fantasai: and want them in source order, but not care about the auto placed ones
<TabAtkins> rachelandrew: i think that's bleeding into the next issue
<TabAtkins> rachelandrew: whether we change the default behavior is a different issue
<TabAtkins> rachelandrew: we could decide dense grid has sailed and can't change the default, but that's still separate
<TabAtkins> fantasai: i think it interrelates somewhat. if we ahve a lot of those cases it's a compat issue.
<TabAtkins> fantasai: so like if the order matches the standard order, we treat it as not reordered. maybe that's less problematic
<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
<TabAtkins> Di: I think that makes sense
<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
<TabAtkins> Di: on elika's question about order being the same between stadnard and reordered, cna't think of a way to do that
<TabAtkins> fantasai: i think it would be good to restrict the extra behavior to the parts that are reordered, fi there are any
<TabAtkins> fantasai: currently if you *might* be reordering things, you get it on all the places
<TabAtkins> (i disagree)
<TabAtkins> fantasai: might be better to instead only get the scoping changes on the parts that are reordered
<TabAtkins> q+
<emilio> TabAtkins: I disagree
<emilio> ... I don't think we want to have different behavior on elements in the same reading-flow container
<emilio> ... depending on whether has moved
<emilio> ... moved is confusing, if you swap #2 and #3, which one of them moved?
<emilio> fantasai: both
<fantasai> 1 2 3 4 5 vs 1 2 4 3 5 => 3 & 4 moved (don't match their original positions)
<emilio> TabAtkins: generally having the scoping be different in the same container, where the container is what controls it, seems off
<emilio> ... the specific case where there's a dense grid when some things are placed and others auto-placed
<emilio> ... seems like that could be achieved by having a default reading flow value for grid that achieves that
<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)
<TabAtkins> astearns: should we decide on just for masonry?
<TabAtkins> fantasai: that's not defined yet
<TabAtkins> astearns: we already have values that opt you into visual order.
<TabAtkins> astearns: if we dont' have an algo for that, we need that anyway, so we're not adding additional difficulty.
<TabAtkins> rachelandrew: there's a lot that falls out of this that needs to be decided on an individual layout basis
<TabAtkins> rachelandrew: q is jsut whether this is only a css issue, not an html, or both
<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
<TabAtkins> rachelandrew: so hopefully we can resolve on that part
<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
<florian> q+
<TabAtkins> q-
<florian> q-
<TabAtkins> astearns: objections?
<TabAtkins> RESOLVED: HTML should depend on the *presence* of a reading flow container, but defer to CSS about exactly what causes that.

[dizhang168]

Given resolution at #11208 (comment), maybe we need to consider how property reading-order affect reading-flow's initial value.

What do we think of supporting the following values for reading-flow:

• flex-visual, flex-flow, grid-order, grid-rows, grid-columns: As described in spec.
• none: Follow the order of elements in the DOM order, with no reading-flow container and does not affect the focus order at all.
• normal: default

Then, normal will be interpreted as follow:

1. If it is a grid container and any of its items has reading-order; then use grid-order.
2. Else if it is a flex container and any of its items has reading-order; then use flex-flow.
3. Else if it has grid-auto-flow: dense or grid-auto-flow: dense row; use grid-rows.
4. Else if it has grid-auto-flow: dense column; use grid-columns.
5. Else; use none.

1-2 would help to handle reading-oder while 3-4 are to solve the current issue.

On a side note, maybe normal should be renamed to auto?

[dizhang168]

I added a use counter for GridAutoFlowRowDense and GridAutoFlowColumnDense. Given the Chrome Canary data, it looks like:
6.5% of sites have grid-auto-flow set
1.2% of sites have grid-auto-flow: dense or grid-auto-flow: dense row
0.018% of sites have grid-auto-flow: dense column

Given this, I think it might be a good idea to have dense (and masonry) be opted in to grid-rows or grid-columns. But since this would introduce a behavioral change (and potentially a performance issue) and we should be careful about such changes, maybe this can be specced first, but we don't include it with the first rollout of CSS reading-flow. It could be rolled out around or ahead of releasing Masonry.

[dizhang168]

I think that this issue should only be handling the masonry/dense packing cases. Proposed resolution:

First, update the existing keywords by:

• Adding none: follow the order of elements in the DOM order, with no reading-flow container.
• Change normal to auto.

Second, update how the auto value gets interpreted. If the reading-flow value is auto, it must be interpreted as follow:

• If it has grid-auto-flow: dense or grid-auto-flow: dense row, use grid-rows.
• Else if it has grid-auto-flow: dense column, use grid-columns.
• Else use none.

[fantasai]

• We agree with adding a source-order value to reading-flow to contrast with the initial value. reading-flow: none seems a bit odd, though. (Personally I think something like source-order vs normal would be pretty clear, but open to suggestions.)
• We don't think dense packing should cause reordering of everything in a grid container. This would be unexpected, and likely break existing pages. If it's to have an effect by default, it should limit itself only to changing the position of the backfilled items wrt other items, not shuffling everything. This is a particularly important consideration for pages that mix auto-placed items with more specifically placed items, and are relying on the source order to make sense for at least some of those items. See e.g. [css-display-4] Initial value of reading-flow #11396 (comment)
• In general, this discussion would benefit from more complex real-world and creative examples. A lot of the discussion of reading-flow etc. has focused on very simple teaching examples, which don't do enough to inform our decisions. For example, the proposal in [css-display-4] Initial value of reading-flow #11396 (comment) is perfectly reasonable in a grid container that has only auto-placed items; but breaks down when the grid's content is more complex.

[tabatkins]

• We're not particularly attached to the current names; happy to accept other suggestions. However, our suggestion of none is to emphasize that no special behavior occurs - you explicitly get none of the side effects and nothing works, explicitly opting out of the default behavior. We just want to make sure that remains clear with whatever name we choose.

• It sounds like you're suggesting a new, currently unspecified reading-flow behavior? If we want that, we should work on it more explicitly; we shouldn't bodge it in too quickly as the new default behavior without working out details.

  Of course, the way to avoid any issues with unexpected reorderings (particularly if authors are currently doing exactly what the spec tells them to, and making sure the source order is meaningful) is to... do nothing by default, aka the current state of things. We're okay with doing nothing (we definitely agree there can be web-compat issues, which is why we've done some use counters and aren't comfortable with doing non-dense grids), we've just been trying to address y'all's feedback that we should have some default behavior.

  So, if "don't have default behavior" is acceptable, that avoids a lot of issues, and we think that would be preferable.

• We have gathered a lot of examples, many/most of which are described in the original issue. More examples are always good, of course.

[SebastianZ]

• We agree with adding a source-order value to reading-flow to contrast with the initial value. reading-flow: none seems a bit odd, though. (Personally I think something like source-order vs normal would be pretty clear, but open to suggestions.)

+1 on using a different keyword for this than none. There is always a reading order for the elements. So none seems wrong to me as it indicates that there is no order whatsoever. source-order sounds fine, or maybe element-order.

Sebastian

[tabatkins]

To hopefully close the loop on this issue:

• We (Chrome) are cool with keeping the initial value as normal (instead of none).

• We're cool with adding a source-order value, and making it work for Flex, Grid, and Block (it's the only value that works for Block, currently).

• We're also okay with not opting dense grids into reading-flow by default. (As I said in my previous comment, this was added in an attempt to address feedback from Apple, but if Apple impls don't want it either, we're happy to go back to not doing it. ^_^)

• We're not okay with reading-order on a child automatically opting a reading-flow: normal parent into reading-flow: source-order. As I explained last week when discussing #11208 (see minutes), this has both perf and author-surprise implications (due to the side-effects of reading-flow), and can trigger side-effects unpredictably due to a single child being present/absent across different instances of the same markup or due to the single child being hidden/shown dynamically. It also has forward-compat issues for any layout types that don't currently respect the source-order value, like Table.

  It's not a big request for authors using reading-order to set the container to reading-flow: source-order, as that's the property they'll be using to do anything else related to the reading order. This ensures the side-effects of reading-flow occur stably and predictably, and avoid any possible perf implications.

So, if the WG approves, we'd like the following resolutions:

• Leave the the initial value of reading-flow named normal (rather than changing it to none).
• Add the value source-order to reading-flow, which solely triggers "reading flow container" side-effects (including allowing reading-order on the element's children), and works on Flex/Grid/Block containers.
• Do not add any default reading-flow behavior for dense grids. (Authors have to manually set reading-flow to the non-initial value they want.)
• Do not add any default reading-flow behavior for elements that have reading-order children. (Authors have to manually set reading-flow to a non-initial value for reading-order to work on children.)

[emilio]

Fwiw the above sounds good to me :)