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

[rachelandrew]

I've started work on this here: https://drafts.csswg.org/css-display-4/#reading-order

Questions/thoughts:

1. We might want to add a value of source to reading-flow. As in "do source ordered reading flow, other than the items with a reading-order other than 00". Maybe all those use cases are covered by the flex-flow and grid-order values though. Would be good to have more use cases for this specific functionality.
2. The original was modeled after order. With breaking the tie, if we were in source order other than reading-order, I'm assuming we do the same as order and items are navigated to in source order in their group.
3. Is it obvious enough to developers that return reading-order to 0 resets it back to normal, or should there be another keyword there?

[dizhang168]

The edits so far looks great!

1. Does source mean the source DOM order or is this the visual order within flex/grid container? I think source is unnecessary. We should either encourage users to avoid reading-flow if they want DOM order or to specifically use gird-order/etc for visual order.
2. I think it is clear that 0 is resets back to normal and this property works best by being similar to order. From an algorithmic point of view, we should first sort all reading flow items by the reading-flow property. Then, this list will be sorted again by reading-order value, with each item either having the value set or will be defaulted to 0.

[css-meeting-bot]

The CSS Working Group just discussed [css-display-4] reading-flow and mix of auto-flow and explicit items .

The full IRC log of that discussion

<emilio> TabAtkins: rachelandrew has started speccing reading-order
<emilio> ... which gets you tab-index-y behavior
<emilio> ... while doing so had a few questions that we wanted to run by the wg
<emilio> ... Q1: Do we want reading-flow: <stick-with-source-order>?
<emilio> ... this might be needed because reading-order only works with reading-flow container
<emilio> ... so if people want source order with some reordering
<emilio> ... so reading-order works for the children
<emilio> ... di thinks it might be unnecessary
<emilio> ... I think it'd be useful
<astearns> ack fantasai
<emilio> fantasai: I think it'd be a good idea to distinguish reading-flow: {normal, source}
<emilio> ... but the initial value might not want to be just source order
<emilio> ... if we can avoid a double-opt-in would be nice
<emilio> astearns: so you want reading-order != 0 to have an effect on reading-flow containers
<emilio> fantasai: or cause things to become reading-flow containers
<emilio> TabAtkins: that'd be confusing if you specify on a grandchild or so for example
<emilio> ... don't think we want to make this work by default due to the strict parent->child dependency
<astearns> q+
<emilio> ... I think it's worth the explicit switch
<emilio> q+
<emilio> ... and being a reading flow container has other implications
<emilio> fantasai: main one being how it scopes tab index right?
<emilio> ... it's already surprising that you have a weird side effect
<emilio> ... if that is not sufficiently significant for other aspects of reading-flow let's not worry about it
<emilio> ... the order property doesn't require a double opt in
<emilio> TabAtkins: the display value is the opt-in there
<emilio> fantasai: that's probably true of reading order as well right?
<emilio> TabAtkins: not necessarily
<emilio> fantasai: if we make it work on blocks would be great but I think we should keep order and reading-order working similarly
<emilio> astearns: I don't think we should do this now (source for reading-flow)
<emilio> ... seems more theoretical, want to have a good use case for it
<emilio> ... other than opting into this
<astearns> ack astearns
<emilio> ... fantasai's concern about the double opt-in makes sense to me
<TabAtkins> emilio: i have the feeling this could be potentially useful
<TabAtkins> emilio: but same gut feeling as Alan
<TabAtkins> emilio: if this works for blocks and things that are split, we ahve amuch bigger problem
<TabAtkins> emilio: well, complexity
<TabAtkins> emilio: not necessarily bad
<TabAtkins> emilio: i'd rather avoid adding it for now, if we decide it's useful we can figure it out later
<TabAtkins> emilio: i'd be concernede about not having a switch on the container
<TabAtkins> emilio: becuase checking if you're a reading-flow container isn't constant, you have to check all the children
<TabAtkins> emilio: so i think we'll want *some* opt-in on the container
<TabAtkins> emilio: i'd rather side-step discussion for now by not adding it
<emilio> astearns: let's check the other two questions
<emilio> TabAtkins: null decision was against fantasai's preference, is she ok with it?
<emilio> ... the original q was: do we want to allow reading-order to work on containers that are not opting in?
<emilio> fantasai: yes
<fantasai> s/are not opting in/are not asking for a special reading-flow reordering value/
<emilio> TabAtkins: sounds like people are leaning toward it being useful but needing an opt in in the container
<emilio> ... but that was against your preference
<emilio> fantasai: I misunderstood your original q, I don't think we should ask the author to opt-in
<emilio> TabAtkins: so that's opposite to what emilio was asking for
<emilio> ... we need to decide on that because it has compat implications
<emilio> astearns: and we're out of time
<emilio> ... will leave the agenda tag to get back to it soon

[tabatkins]

Okay, there was confusion in the call about exactly what I was asking about, so here it is in more detail:

1a) Do we want to allow 'reading-order' to work on elements who aren't opting into one of the special re-orderings? That is, "normal source order, + reading-order for some exceptions"?

1b) If the answer to 1a is "yes", do we need to trigger that with an explicit keyword on the container (source is the proposed keyword), to ensure the container is a "reading flow container"? Or do we implicitly opt the container into being a reading flow container when 'reading-order' is used on a child?

1c) If the answer to 1b is "implicitly", then what's the forward-compat implication of this on layout modes that don't currently have the ability to become reading flow containers, like block?

Di prefers that 1a's answer be "no". If people want reading-order, they should be opting into one of the visual-reordering modes for the rest of the children as well. (In particular, grid already has this basic option - grid-order follows source order unless order reorders something. Flexbox's flex-flow value also follows source order + order, unless you're using one of the *-reverse keywords on it.

Emilio prefers that if 1a is "yes", then 1b is "explicit". That way determining whether something is a reading-flow container remains a constant-time operation, rather than having to walk the children to see if any of them have reading-order. I don't think they have an opinion on 1a itself, tho.

Fantasai wants 1a to be "yes" and 1b to be "implicit". We did not have time to bring up 1c.

I lean towards 1a being "no", but if it's "yes", then I strongly agree with Emilio that 1b should be "explicit". I don't think the additional "reading flow container" behavior (tabindex scoping) should turn on/off unexpectedly based on whether everything has reading-order:0 or one element has a non-0 value. I'm especially concerned about 1c, the potential expansion of reading-flow to block contexts (which is part of why we're prefixing the keywords in the first place).

Note that we can decide that 1a's answer is "not yet" and decide later, but doing so fixes 1b as "explicit" (otherwise we'd have a potential back-compat issue in the future if we end up deciding on "yes", due to authors potentially having useless reading-order values sitting around).

---

So, my preference is that we just answer 1a as "no" - it's fine to require authors to ask for a particular reading-flow ordering. If we really want to ensure that source order is an option, we can add flex-order to match grid-order, but that's something we can decide independently if there's a request for it.

[dizhang168]

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.

[fantasai]

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.

[tabatkins]

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.

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

[dizhang168]

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.