- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 26 Mar 2025 16:58:12 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed ``[css-display-4] Initial value of `reading-flow` ``, and agreed to the following: * `RESOLVED: Initial value of reading-flow is "normal".` * `RESOLVED: Add 'source-order' value applying also to block containers.` * `RESOLVED: No change to the default behavior for reading-flow and dense grid for now, because there's no proposal` <details><summary>The full IRC log of that discussion</summary> <fantasai> TabAtkins: https://github.com/w3c/csswg-drafts/issues/11396#issuecomment-2715874704<br> <fantasai> TabAtkins: reading-flow changes the order that elements will show up in a11y tools to better match visual layout<br> <fantasai> TabAtkins: reading-order applies to children, and explicitly reorders<br> <fantasai> TabAtkins: This can help opt things out of visual reordering<br> <fantasai> TabAtkins: After some discussions about what needs to be done here, we have 4 points<br> <fantasai> TabAtkins: 1. Initial value should stay as normal.<br> <fantasai> TabAtkins: 2. Adding a 'source-order' value, which has no effect on reading-flow normally, but creates reading-flow container side-effects: allows reading-order, and applies tabindex scoping<br> <fantasai> TabAtkins: 3. 'source-order' applies to block containers as well as flex/grid<br> <fantasai> astearns: let's pause there<br> <fantasai> astearns: Any concerns about resolving on initial value of reading-flow as normal?<br> <fantasai> RESOLVED: Initial value of reading-flow is "normal".<br> <fantasai> astearns: proposed to add 'source-order' value that will also apply to block containers<br> <fantasai> RESOLVED: Add 'source-order' value applying also to block containers.<br> <fantasai> TabAtkins: Next batch of questions was about defaults.<br> <fantasai> TabAtkins: 1. Suggestion that perhaps dense grids could automatically opt into an appropriate reading-flow value by default<br> <fantasai> TabAtkins: But suggestion to not do that<br> <fantasai> TabAtkins: so suggested to resolve not to have an effect on dense grids<br> <astearns> ack fantasai<br> <TabAtkins> fantasai: we raised this issue because dense grids are ac ase we might want to ahve autoamtic behavior<br> <TabAtkins> fantasai: but also some concerns with that<br> <TabAtkins> fantasai: it would apply the tab-index scoping bheavior by default, which might not be expected<br> <TabAtkins> fantasai: tho that's a bit more of an edge case, since positive tabindexes are strongly discouraged (due to bad effects)<br> <TabAtkins> fantasai: the other aspect is , Tab when you suggested we shoudl apply one fo the visual reordering modes to dense-packed grids by default, th epushback wasn'ta bout not doing anything, it was that it would reorder everything in the grid, not just the auto-placed items<br> <TabAtkins> fantasai: so if an author was placing key items and auto-placing around those, it woudl be harmful to switch the entire grid into a naive visual scan of the grid<br> <TabAtkins> fantasai: so if we're goign to do something by default it needs to have a lesser effectd<br> <TabAtkins> fantasai: something that wouldn't break layouts that are using explicit placement with auto placement<br> <TabAtkins> fantasai: so i dont' think we necessarily shouldn't do anything for dense packing, but we shoudln't use one fo the existing values by default<br> <fantasai> TabAtkins: You're suggesting a new value not discussed as a default. That's concerning, would like default value to be well-thought-out<br> <fantasai> TabAtkins: I suspect problem space, while potentially useful, is complex.<br> <fantasai> TabAtkins: naive visual scan is simple to talk about and understand<br> <fantasai> TabAtkins: More complicated behavior, would want to be much more deliberate in designing<br> <fantasai> TabAtkins: So prefer to go with no special behavior<br> <fantasai> fantasai: That is what this issue was for discussing.<br> <fantasai> TabAtkins: We want to be shipping this soon, and issue was open since December (SO MANY MONTHS AGO)<br> <fantasai> TabAtkins: so we want to close the issue with no change.<br> <TabAtkins> (I did not say "so many months ago", that's scribe editorializing)<br> <TabAtkins> TabAtkins: So, Elika, are you objecting to the default behavior for dense grids being nothing special?<br> <TabAtkins> fantasai: I think we should still think about it, but it shoudln't block shipping<br> <fantasai> TabAtkins: Unsure about changing later, but if we're sticking with no special behavior for now it's fine with me<br> <fantasai> fantasai: sounds like we should just move on then, and leave the issue open<br> <fantasai> TabAtkins: We want a resolution for no change.<br> <TabAtkins> But without prejudice<br> <dholbert> TabAtkins: this isn't leaving the issue open; I'd like to resolve it, but without prejudice<br> <dholbert> astearns: so no change to the spec, are you ok with that fantasai?<br> <dholbert> fantasai: I think this is an open issue, we shouldn't close it. we should keep thinking about this<br> <dholbert> TabAtkins: I'm proposing we resolve on no-change-for-now<br> <dholbert> fantasai: a resolution of no-change means the wg has decided they don't want to make a change<br> <dholbert> TabAtkins: that's not the proposed resolution. I'm suggesting we close the question, not closing the issue<br> <dholbert> TabAtkins: maybe we resolve no-change-for-now- because there's no proposal. I'm fine with that<br> <dholbert> PROPOSED: No change for now, because there's no proposal<br> <dholbert> RESOLVED: No change to the default behavior for reading-flow and dense grid for now, because there's no proposal<br> <dholbert> TabAtkins: last point on this issue:<br> <dholbert> TabAtkins: whether or not reading-order works by default.<br> <dholbert> TabAtkins: per spec right now, reading-order only works on children of reading-flow containers (those with non-default initial value)<br> <dholbert> TabAtkins: now that we have source-order (which just makes something a r-f container), you can take any flex/grid/block and turn on reading-flow for it, and the only effects are tab-index scoping & allowing reading-order to work on its children<br> <dholbert> TabAtkins: apple proposes that we let r-o work by default *and* opt the element's parent into being a r-f container<br> <dholbert> TabAtkins: (presumably w/ source-order value)<br> <dholbert> TabAtkins: we prefer not doing that<br> <dholbert> TabAtkins: objections: 1st from emilio: because you need to know whether things are a r-f container for various purposes, it's annoying to have that depend on the children<br> <dholbert> TabAtkins: 2. more important from me personally: because there are side-effects, and they might be unwanted, I don't like being a parent being implicitly opted in for something that might be variable across a page or between pages (if you have multiple similar containers and only some of them have a reading-order child)<br> <dholbert> TabAtkins: or if the child's reading-order gets toggled on/off (and has side effects on parents)<br> <dholbert> TabAtkins: I don't think it makes sense for a11y order to be toggled by this implicit behavior<br> <dholbert> TabAtkins: Also, the dependence on a parent/child relationship here is relatively rare in css<br> <dholbert> TabAtkins: where that happens in CSS, it's extremely tied together - grid parent/grid-child, etc<br> <dholbert> TabAtkins: that doesn't feel like the case for reading-order<br> <dholbert> TabAtkins: I'd prefer having r-f be opted in before r-o turns on<br> <Rossen5> q?<br> <dholbert> TabAtkins: It's possible that an author sets one and then never tests it. The failure case is that the page works the same as it does today<br> <dholbert> TabAtkins: the perf and the unpredictability of container creation make me lean towards no-to-implicit-creation<br> <emilio> +q<br> <dholbert> emilio: that was meant to be a +1<br> <emilio> ack emilio<br> <Rossen5> ack fantasai<br> <dholbert> fantasai: we discussed this with our a11y folks and they raised various questions that we haven't finished digging into<br> <dholbert> fantasai: and those might invalidate some parts of Tab's argument<br> <dholbert> fantasai: so I'd object to taking a resolution either way for now<br> <dholbert> TabAtkins: any details? This feels analogous to other parent/child relationships across aria where opting in is important<br> <dholbert> fantasai: one of the qs is should we even have these [...] Is this tab-index scoping behavior, on-the-whole, better or worse than not having that automatic tab-index scoping behavior<br> <dholbert> fantasai: if it's worse, then some of the premises of Tab's arguments are invalid<br> <dholbert> TabAtkins: I think we adopted the tabindex scoping behavior on the recommendation of w3c a11y folks, so that part feels like it should be fine<br> <dholbert> TabAtkins: I'm ok leaving this open to wait for your feedback<br> <PaulG> I'll make sure APA knows about it<br> <dholbert> Rossen5: no resolution on this one for now then. we'll await feedback from fantasai and team<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11396#issuecomment-2755105190 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 26 March 2025 16:58:13 UTC