[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

[css-meeting-bot]

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

The full IRC log of that discussion

<nicole> Reading flow and the mix of outflow and explicit items
<nicole> asterns: limit to necessary for HTML folks to progress
<nicole> Rachel: Some items you want to choose position and mix of autoplaced items. How does reading flow work with that
<nicole> Rachel: probably by applying it to the container and children. Which we originally discussed and decided not to do
<ydaniv> s/asterns:/astearns:/
<nicole> rachelandrew: a bit like order, but only affects reading flow
<nicole> fantasai: works find for explicit source order
<astearns> s/find/fine/
<nicole> fantasai: simple example of mixed - a masonry layout with a sidebar. Title, nav, etc. Positioned on right aesthetically
<nicole> fantasai: would be 5th rather than 1st
<florian> q+
<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
<nicole> rachelandrew: would reading flow container also encompass this situation?
<astearns> ack florian
<nicole> florian: we want this now. Removed because we started with only explicit ordering, was a bad solution. Overall solution combo of 2
<nicole> florian: general scheme on container
<nicole> florian: override on children
<nicole> florian: design of thing that applies to container should account for being able to override children
<nicole> florian: so both pieces work together
<fantasai> s/so both/design both together so both/
<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
<astearns> ack fantasai
<nicole> rachelandrew: Probably doesn't, since it is just a different way of doing ordering
<Di> q+
<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
<astearns> ack Di
<fantasai> s/___/things like dense packing/
<nicole> di: HTML side is reading flow container, shouldn't override it. Should be fine for the hTML spec
<nicole> asterns: design as a whole rather than piecemeal
<nicole> di: agree
<nicole> astearns: Resolution to restore previous reading order property and use it as a starting point for reading order flow.
<astearns> ack fantasai
<TabAtkins> +1
<nicole> fantasai: as a starting point, define that if the reading order of 2 items is equivalent, reading flow breaks the tie
<nicole> RESOLVED: Resolution to restore previous reading order property and use it as a starting point for reading order flow.
<nicole> RESOLVED: as a starting point, define that if the reading order of 2 items is equivalent, reading flow breaks the tie
<dbaron> is there a new condition that it only works in reading order containers?
<nicole> astearns: David can you raise an issue?
<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
<nicole> rachelanderew: masonry is an exception, but for everything else you'd need to say on the container
<dbaron> (I was just asking that to try to ensure the resolutions capture stuff that was said earlier in the discussion.)
<dbaron> Present-
<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
<nicole> racheandrew: prefers explicit, like flexbox
<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
<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
<nicole> fantasai: not sure. Cases where we do want to double opt in. Other cases where the child can decide on their own
<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)
<nicole> fantasai: for example z index is just the child
<fantasai> we renamed reading-order-items to reading-flow
<fantasai> dbaron: ^

[dizhang168]

I was considering whether we could reuse tabIndex to explicitly set item's focus order, but came to the conclusion that we should avoid that. Adding the reasoning here for prosperity.

1. We want people to move away from positive tabindex as they are not discoverable by the accessibility tree.
2. Since reading-flow is a CSS property, it would be preferable to keep the control on the CSS side. Mixing HTML and CSS to build the rendering-defined sibling reading flow list is not good.
3. By having this new CSS property, we will be able to scope it to only be within an eligible reading flow container.
4. If someone sets the tabIndex with the expectation that it is scoped within the reading flow container, but the code is moved/copied around, the tabIndex will cause jumping around and unexpected focus order.