Re: [csswg-drafts] [css-display-4] reading-flow and mix of auto-flow and explicit items (#11208)

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.

-- 
GitHub Notification of comment by tabatkins
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11208#issuecomment-2669690396 using your GitHub account


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

Received on Wednesday, 19 February 2025 20:29:10 UTC