[css-display-4] reading-flow and mix of auto-flow and explicit items

[fantasai]

https://webkit.org/demos/grid3/museum/ shows an example of auto-flowed items, with one item in the righthand corner. Similar layouts could be done with mixed-span grid items and dense packing, which would need reading-flow to order the items, but needs one special item to be first or last or whatever. AFAICT, the reading-flow property can't handle this case...

[dizhang168]

That seems correct. If we use grid-rows in a left to right direction, the focus visit will go to the righthand corner menu last. A potential hack could be to set a positive tabindex value on it so it gets visited first, but the design we agreed on at TPAC was to avoid using positive tabindex to overwrite the reading-flow.

@tabatkins

[tabatkins]

I think this is just an example of the (eventual?) need for the ability to explicitly order children; we've steered away from that design so far because it's mostly way more specific than authors need (to the point of being harmful), but the design is open to that being added in the future.

(The obvious design will be matching how 'order' works - order by explicit index first, tie-break by reading-flow order.)

[fantasai]

It's fine if reading-flow can't handle this case, but something needs to.

[tabatkins]

Yup, agreed.

[rachelandrew]

Would the grid-order value not handle that, assuming all others are auto-flow? That special case would have order which should be followed then the others just autoflow as normal.

[rachelandrew]

A very simple example is as I described previously, and you can see in this demo. This uses reading-flow: grid-order, with order: -1 on one item. The ordered item is then visited first and the others then in DOM order.

In something like https://webkit.org/demos/grid3/museum/ however you might want to visit that side item first (or last) but also perform grid-row type ordering on the masonry items. The two options I can think of are as follows.

To add back the property on items (which we didn't do initially but the door is open to do that), which would allow for an explicit reading-flow order to be set on some items, with any items that don't have an order set using the value as set on the parent with reading-flow. I think if we want to do that it could be deferred to the next level of the spec as it's an addition and it would be good to see what real use cases there are.

The other thing is, the examples like this I can think of only really apply to automatic layout methods in grid (masonry and dense packing). If that's the case, could this be part of the decision we make about automatically applying reading-flow in those layout methods? So, with masonry for example. We make it so by default we follow the masonry-flow (as I describe in #5675 (comment)) AND also take the order property into account, for reading flow purposes. That feels like what you are trying to achieve in that demo, though it might be that just pushes the problem down the road and there are more cases better solved by adding in a property for the children.

[SebastianZ]

It looks like everyone agrees that the use case of providing more granular control over the reading flow is valid.

So I guess, the main question here is whether this can be handled via the existing order property and the given reading-flow values or a new value if required or a new property for the items. If we introduce a new property, I suggest to call it reading-order as it aligns with both reading-flow and order.

Sebastian