[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)

rachelandrew has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-display-4] Do we need `reading-order: <integer>` or should `reading-order: auto` be allowable in all grid or flex layouts? ==
This issue relates to the [edits to CSS Display 4](https://drafts.csswg.org/css-display-4/#reading-order) based on [this dicussion](https://github.com/w3c/csswg-drafts/issues/7387), and the as-yet unmerged PR at https://github.com/w3c/csswg-drafts/pull/8257.

TL:DR is that we are wondering if we only need `reading-order:auto` (on the children) and if there are reasons to do `reading-order: <integer> `at all, or initially. Do compelling enough use cases exist to have that level of control or do people really just want to follow the layout?

Longer notes below:

My [original suggestion](https://github.com/w3c/csswg-drafts/issues/7387) was a switch on the grid/flex container. In that scenario all of the following would follow the grid or flex modified order:

- flex layout with order
- flex layout with *-reverse
- grid layout doing placement with lines/template areas
- grid layout with order
- "randomized grid layouts" with dense packing or masonry

In the existing edits plus this PR, the reading-order: auto value is applied to the children, and only covers:

"randomized grid layouts" with dense packing (and I'm assuming masonry)

To do the following you would need `reading-order: <integer>` on the children:

- flex layout with order
- flex layout with *-reverse
- grid layout doing placement with lines/template areas
- grid layout with order

There are definitely use cases for people wanting to follow the layout created by placement (usually because they want different layouts at different responsive breakpoints), so if we only do auto as specced, we don't have a method to achieve those use cases, and if we go for the switch on the container that likely stops us doing this version later.

An alternative, however, would be if the only value for `reading-order` was `auto` (applied to the children) and auto applied in all layout types, not just the randomized ones. As that shouldn't roadblock us from adding the integer value in the future.

Reading order and layout order being separated, is a use case. For example, [this](https://twitter.com/hovhaDovah/status/1531681075562520579?s=20&t=IW1Qq-7k-daMcKb4LkYU6Q), but I think in that case, if we went with auto applied everywhere that doesn't need to affect layout-order with no reading-order.

I feel that having the property on the children is better than my idea of a switch on the parent (though I guess we could then add a switch on the parent that sets them all as a group, as with align-items), because it allows for more flexibility, but I think we could get away with that initially being auto only.

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8589 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 15 March 2023 13:18:37 UTC