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

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

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


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11208#issuecomment-2669384250 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 18:01:45 UTC