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

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...

@tabatkins

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

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

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

Yup, agreed.

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.

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.

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

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: ^

Given the summary comment above, I propose we resolve to answer “no” to 1a. For 1b, I propose that the reading flow focus navigation should be opted-in explicitly via a separate CSS property.

Why: we should only encourage using reading flow when the visual order is different from the DOM order, such as in flex and grid containers. This is in line with the CSS order property, which also only works in flex or grid containers. If it is really necessary to allow reading-order to take effect without specifying reading-flow flex-/grid- values, then we should at least make it very explicit by using a new keyword like source. This would help the author be aware that the focus order changed.
Authors often copy/paste code around and if they set reading-order on an item that isn’t even a flex/grid item, then making it opt into reading flow doesn’t make sense and would be unexpected.

@jensimmons

Reviewed the questions with @jensimmons and @cookiecrook today...

1a) Yes, we think reading-order should work even if you don't use reading-flow to reorder everything visually. An author may want to use reading-order to adjust the order of a few items without changing the order of everything else, so this ability should not require switching everything into visual order.
1b) Yes, we think reading-order should work even without a second opt-in from the container. Authors will expect it to Just Work, and forgetting to set reading-flow on the container is likely to be a source of mistakes that don't get caught.
1c) To address this forwards-compat concern, we think we should define reading-order to work on block-level boxes right now; and to work on inlines never. Use cases for block-level reordering include fixup of image-over-headline source order, and also fixup of weird source order choices due to desired float rendering.

1a) Yeah, we're fine with a "no extra reordering" beahvior (just triggers reading-flow-container side effects, and allows reading-order to work on children), so long as it's an explicit separate keyword. We skipped it originally because triggering just the side-effects wasn't worth the specification/implementation effort, but now that reading-order exists, we agree that's changed.

1b) This cuts both ways. Authors turning on reading-order on an item might not (and I think it's reasonable to say, probably won't) expect that to also turn on the reading-flow-container side effects on all siblings of that element. It also seems perfectly plausible for authors to reuse similar markup structures multiple times on a page or across pages, of which only some of them use reading-order on a child, and getting the side-effects on some of those but not all seems unexpected. Similarly, if the reading-order child is toggleable (going between display:none and not-none), it would flicker the side-effects depending on whether the child is displayed or not. All of these seem relatively bad and hard for authors to predict.

On the other hand, it's pretty normal to have features not work on children/descendants when the special container isn't turned on, especially when having the feature work implicitly affects the other elements in the container. For example, using flex on one element doesn't automatically turn the parent into a flexbox.

1c) Block-level reading-order has use-cases, but it's a lot more complex than the flex/grid situations, involving out-of-flows like floats. We don't want to rush the specification of that behavior, and don't want to hook the flex/grid cases on us getting block behavior defined and correct.

Reordering cases like "image over headline" are already widely solved by authors by using flexbox or grid, giving them the ability to set the right source order and get the desired visual order, or use any source order and now invoke reading-flow to make the visual order important. Authors using legacy layout techniques are also not particularly likely to be retrofitting their page. So we don't think this is a particularly urgent case to address right now.

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: Add a source-order value to reading-flow.
RESOLVED: reading-flow: source-order works on block containers. reading-order applies to block-level boxes, and not to inline-level boxes

The full IRC log of that discussion

<kbabbitt> TabAtkins: last time we discussed thre was a question about whether reading order is the one that explicitly sets an element to a particular spot
<kbabbitt> ... rather than relying on visual stuff
<kbabbitt> ... should work without opting into one of the other explicit reading flow values
<kbabbitt> ... whether it should be explicit or implict etc
<kbabbitt> ... authors had opinions in thread
<kbabbitt> ... the idea of having a reading-flow value that does no reordering by default but just gives side effects
<hober> fs
<kbabbitt> ... sounds perfectly reasonable
<kbabbitt> ... we didn't do this before because just tab-index was the side effect
<kbabbitt> ... but with reading order in display now it makes sense to have a reading-flow value that does no implicit reordering
<kbabbitt> ... just reordering that author asked for
<kbabbitt> ... we do however feel strongly that it needs to be a new keyword
<kbabbitt> ... rather than a default behavior that can trigger anytime an eleement has reading order
<kbabbitt> ... fantasai was suggesting that if any element has reading order it automatically makes parent into a reading flow container
<kbabbitt> ... emilio disagreed on perf implications
<kbabbitt> ... can't tell if something is a reading-flow container just from element itself
<kbabbitt> ... grid with a whole bunch of autoflow children can be an expenseive operation
<kbabbitt> ... I think becoming a reading flow container has side effects
<kbabbitt> ... having a child with reading order would implicitly apply side effects to siblings
<kbabbitt> ... this would happen if you have the same markup several times on a page or across multiple pages
<kbabbitt> ... only some have a reading order child or have a reading order child that is hideable
<kbabbitt> ... will change whether side effects apply to everything else
<kbabbitt> ... seems not great, just as hard for authors to predict as stated concern
<kbabbitt> ... that authors would not be able to predict whether reading flow works by default
<kbabbitt> ... so we are pretty strongly against reading flow working by default for these reasons
<kbabbitt> ... should instead opt into reading order
<kbabbitt> ... fantasai's third point in response was forward compatibility
<kbabbitt> ... if reading order automatically turns on reading flow containers, that only works if everything can be a reading order container
<kbabbitt> ... or if we fix the set of block types that can ever be reading order containers
<kbabbitt> ... otherwise others could set reading order on a block which would do nothing today
<kbabbitt> ... we could define it in the future and it would turn on suddenly causing side effects that they don't expect
<kbabbitt> ... fantasai suggested we could go ahead and define block-level reading flow right now in trivial case of no reordering
<kbabbitt> ... we're not super comfortable with that
<kbabbitt> ... display:block order is going to be complicated anyway
<kbabbitt> fantasai: I don't think so, we're not proposing to add new visual order
<kbabbitt> ... just saying you can have normal flow order and also apply reading order different from source order
<kbabbitt> ... you ahve an order that's the source order, you don't have a magic order, just saying reading order shoulda pply to source order like in a flexbox
<kbabbitt> ... don't think floats etc. introduce any more complexity
<kbabbitt> ... just as simple as a flexbox that doesn't have any order properties
<kbabbitt> chrishtr: almost a no-op?
<kbabbitt> fantasai: no because if you set reading order on... eg. I have a section with a heading and a couple of paragraphs
<kbabbitt> ... if I set reading order -1 on the heading it would pull up the heading above the paragraphs
<kbabbitt> ... no magic about floats, because that would require a new value for reading-flow
<kbabbitt> ... which would be magic block reordering something
<kbabbitt> ... we're not suggesting that
<kizu> present-
<emilio> q+
<kbabbitt> TabAtkins: it does sound like a potentially doable behavior for block but our opinion is still towards not triggering by defau;t
<kbabbitt> ... our ideal conclusion would be to add a no-op value that just makes something a reading flow container
<astearns> ack JoshT
<kbabbitt> ... and doesn't do anything else special
<kbabbitt> ... define that it works for everything
<kbabbitt> ... not everything because we still want tables to be handleable in a different way
<kbabbitt> ... so define it for blocks and call it a day
<kbabbitt> fantasai: this gets into another issue about initial value of reading-flow
<kbabbitt> ... next issue
<kbabbitt> ... having initial value being smarter than sort order
<kbabbitt> ... adding new value that is strict source order
<kbabbitt> ... with those two, the strict source order could be the value we use here
<astearns> q+
<kbabbitt> emilio: agree with TabAtkins
<kbabbitt> ... did we decide whether reading order affects a11y tree as well?
<kbabbitt> fantasai: yes
<kbabbitt> emilio: I don't know exact order of abspos and floats right now
<kbabbitt> ... but presumably that would get more tricky
<iank_> I think this property only applies to in-flow elements?
<kbabbitt> ... e.g. does the float get ordered... in source order?
<kbabbitt> fantasai: if we apply to blocks, when floats come out of flow that's a visual effect
<kbabbitt> ... does not affect reading order
<kbabbitt> ... would be there as if not floated
<kbabbitt> emilio: ok that seems fine
<kbabbitt> ... I would expect containing block to ? the order
<astearns> ack emilio
<astearns> ack astearns
<kbabbitt> fantasai: in the future maybe we want to do something fancy with floats
<kbabbitt> astearns: in the proposal where reading order works without reading flow, is it the case that if you set reading order on an element that will make the nearest block-level parent a reading flow container?
<kbabbitt> TabAtkins: yes
<kbabbitt> fantasai: yes
<kbabbitt> astearns: very limited utility with markup I'm used to working with where things can get wrapper elements
<kbabbitt> ... caption goes above picture until someone decides caption needs a wrapper element
<kbabbitt> ... then it stops working as intended
<kbabbitt> fantasai: don't think you can introduce a ? that hoists things out of the tree
<kbabbitt> astearns: yes. I think this is an argument for TabAtkins' position
<kbabbitt> fantasai: don't think that would change situation in your case
<kbabbitt> ... if reading order ?? it's still not going to move
<kbabbitt> ... you still have to set it on child that you're trying to reorder
<kbabbitt> ... if reading order is not set on the elements you want to reorder that are siblings
<kbabbitt> ... nothing is going to happen
<astearns> s/on child/on the direct child/
<kbabbitt> ... question is whether or not you need something on the container, not going to make a difference here
<kbabbitt> ... reason TabAtkins wants it is to make sure author is opted into the side effects
<fantasai> s/the side/the tabindex side/
<kbabbitt> TabAtkins: that's the big part, also if we go with your suggestion we could never introduce a more complex behavior
<kbabbitt> ... might be something we never need but I feel like if we explore block cases more we might want to do something like that
<kbabbitt> ... uncomfortable with shutting off that possibility
<kbabbitt> fantasai: if you were going to reshuffle the tree...
<kbabbitt> ... order property doesn't work like that
<kbabbitt> TabAtkins: but order property only works with flex and grid which are explicit about container child relationship
<kbabbitt> ... uncomfortable shutting off possibility of better block reordering strategy
<kbabbitt> fantasai: how would that work? extract element outside container?
<kbabbitt> TabAtkins: don't know
<kbabbitt> ...there's some meat on that bone though
<kbabbitt> ... because as astearns said, it's common to have wrapper elements
<kbabbitt> fantasai: if you introduce wrapper elements the reading order property will be on outermost wrapper
<kbabbitt> ... a number of properties that you want to set on outermost wrapper, reading order is one of them
<kbabbitt> TabAtkins: discussion got mixed with next issue
<kbabbitt> fantasai: swap issues or stay on this one?
<kbabbitt> TabAtkins: we can get some resolutions on this one
<kbabbitt> ... can resolve on a no-op container ? value, a source order value or something
<kbabbitt> fantasai: need that for both issues
<kbabbitt> chrishtr: not to choose a name, say there is a value
<kbabbitt> TabAtkins: happy to resolve on that
<kbabbitt> astearns: Proposed resolution is to add a source order value to reading-flow property
<fantasai> PROPOSED: Add a source-order value to reading-flow.
<kbabbitt> RESOLVED: Add a source-order value to reading-flow.
<kbabbitt> fantasai: Proposed: reading-order applies to block-level elements, does not apply to inline-level elements
<kbabbitt> TabAtkins: such that source-order value points to it?
<kbabbitt> fantasai: that's the third question
<kbabbitt> TabAtkins: not yet whether it applies by default or not
<fantasai> PROPOSAL: reading-order applies to block-level boxes, and not to inline-level boxes. (Note this will work under source-order, and not e.g. flex-*/grid-*)
<TabAtkins> reading-flow:source-order works on block containers. reading-order works on block children of those block containers that are opted in to reading-flow
<fantasai> PROPOSAL: reading-flow: source-order works on block containers. reading-order applies to block-level boxes, and not to inline-level boxes
<kbabbitt> astearns: objections?
<fantasai> RESOLVED: reading-flow: source-order works on block containers. reading-order applies to block-level boxes, and not to inline-level boxes
<kbabbitt> astearns: anything more we can resolve on?
<kbabbitt> chrishtr: that it has to be explicit?
<kbabbitt> astearns: that is the sticking point
<kbabbitt> TabAtkins: resolution as it stands says implict stuff doesn't work
<kbabbitt> ... right now only explicit works
<kbabbitt> fantasai: we can take that back to the issue
<kbabbitt> chrishtr: come back to this issue next week for 3rd point

[reading-flow] Implement source-order keyword

Bug 1952592 [wpt PR 51214] - [reading-flow] Implement source-order ke…

Please note that reading-order and reading-flow: source-order are now both implemented in Chrome Canary 136. Feel free to test it out and provide feedback.

[css-display-4] Adds source-order value for reading-flow

Hi, I stumbled on chrome blog post and after playing around with it decided to ask for a additional feature regarding explicit items.
I think this thread is closest thing discussing what I want to ask for.

In this example A block container using reading-order reading order starts with 5 and then continues to 1, 2, 3, 4 because 5 have reading-order: -1. When we mess around a bit with it and instead set item 3 to reading-order: -1 then we get 3, 1, 2, 4, 5 which feels unnatural but in accordance with

By setting this item's reading-order to -1, the focus order visits it first before falling back to source order for the rest of the reading flow items.

I would like to ask for ability to say continue onward so when item 3 is starting element we will get order 3, 4, 5, 1, 2.

Interesting use case. Right now, you can accomplish this by setting:

 <div class="wrapper">
  <a href="#">Item 1</a>
  <a href="#">Item 2</a>
  <a href="#" style="reading-order: -3">Item 3</a>
  <a href="#" style="reading-order: -2">Item 4</a>
  <a href="#" style="reading-order: -1">Item 5</a>
</div>

IMO, CSS reading-order is meant for one off overriding of natural focus order to give web developers more flexibility. But overall, we shouldn't add too many features. Users should use CSS reading-flow or depend on the DOM order when appropriate.

Bug 1952592 [wpt PR 51214] - [reading-flow] Implement source-order ke…

Navigation Menu

Repository navigation

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

7 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

Activity

dizhang168 commented on Dec 4, 2024

tabatkins commented on Dec 4, 2024

fantasai commented on Dec 5, 2024

tabatkins commented on Dec 5, 2024

rachelandrew commented on Dec 6, 2024

rachelandrew commented on Dec 31, 2024

SebastianZ commented on Jan 1, 2025

css-meeting-bot commented on Jan 30, 2025

7 remaining items

dizhang168 commented on Feb 26, 2025

fantasai commented on Mar 5, 2025

tabatkins commented on Mar 5, 2025

css-meeting-bot commented on Mar 5, 2025

dizhang168 commented on Mar 19, 2025

kbrilla commented on May 7, 2025

dizhang168 commented on May 20, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions