Re: [csswg-drafts] [css-display-4] Define how reading-flow interacts with focusable display: contents elements. (#9230)

The CSS Working Group just discussed `[css-display-4] Define how reading-flow interacts with focusable display: contents elements.`.

<details><summary>The full IRC log of that discussion</summary>
&lt;fantasai> s/Topic: [css-display-4] Define how reading-flow interacts with focusable display: contents elements.//<br>
&lt;fantasai> TabAtkins: [summarizing] Current spec proposes any 'display: contents' element doesn't participate in reading flow, appended to the end<br>
&lt;fantasai> ... and they also scope the children, which then end up at the end<br>
&lt;fantasai> ... but that's not great behavior<br>
&lt;fantasai> ... especially since no-op where DOM order and visual order match, now we have everything at the end<br>
&lt;matatk> q+ to ack the definition of display:contents<br>
&lt;fantasai> TabAtkins: new proposal is that 'display: contents' doesn't get moved to the end. Instead, children get ordered according to visual order<br>
&lt;fantasai> ... and 'display: contents' element itself gets placed immediately before its first child in visual order<br>
&lt;fantasai> TabAtkins: further question, which we wanted to ask you are, does it still need to scope its children?<br>
&lt;fantasai> ... when you hit 'display: contents' item, do you recurse and do all of its children first, or do you follow an interleaved order (if that is what visual order is)?<br>
&lt;Zakim> matatk, you wanted to ack the definition of display:contents<br>
&lt;fantasai> TabAtkins: argument for scoping is that a11y tree will match<br>
&lt;fantasai> ... all of the children will be contiguous<br>
&lt;fantasai> ... Argument for not scoping is that it matches visual order<br>
&lt;fantasai> ... and tabindex already jumps in and out of a given eleent, if that's how you wrote your HTML<br>
&lt;PaulG> q+<br>
&lt;fantasai> TabAtkins: so the question to you is, is the tabindex behavior horrible and not good to duplicate<br>
&lt;fantasai> ... or is it more important to match visual order, even if you jump in and out of tree<br>
&lt;fantasai> matatk: Thanks for explanation.<br>
&lt;zcorpan> (I found 0 pages with `&lt;div role="table">` in httparchive sample_data (10k pages). So at least not common enough to show up in a 10k random subset of 12m pages.)<br>
&lt;TabAtkins> fantasai: To make i tmore concrete, say I have a tree with siblings A, B, C<br>
&lt;TabAtkins> fantasai: B has children B1 and B2<br>
&lt;TabAtkins> fantasai: in tree order I get A B B1 B2 C<br>
&lt;TabAtkins> fantasai: if I set display:contents on B<br>
&lt;TabAtkins> fantasai: I get the items as A B1 B2 C<br>
&lt;TabAtkins> fantasai: If I reorder them, I could visually reorder them as A B1 C B2<br>
&lt;TabAtkins> fantasai: Which interleaves them<br>
&lt;TabAtkins> fantasai: So, because B1 and B2 are under the B parent, in the a11y tree structure<br>
&lt;TabAtkins> fantasai: Should the reading order A B1 B2 C (keeping them contiguous)<br>
&lt;TabAtkins> fantasai: Or should it be A B1 C B2 (matching visual order)<br>
&lt;TabAtkins> fantasai: If B was display:contents but focusable, it would be A B B1 C B2<br>
&lt;TabAtkins> (in strict visual)<br>
&lt;TabAtkins> fantasai: Or we could cause the display:contents to strictly scope, giving A B B1 B2 C<br>
&lt;TabAtkins> fantasai: So do we force the containment, or match the visual order, when things are interleaved<br>
&lt;fantasai> matatk: You described previous change, and new change, what's happening now?<br>
&lt;fantasai> TabAtkins: All under discussion<br>
&lt;matatk> q?<br>
&lt;matatk> ack PaulG<br>
&lt;fantasai> PaulG: my instinct is that visual order should be strict<br>
&lt;fantasai> ... we tell devs not to use tabindex above zero<br>
&lt;fantasai> ... [too quiet]<br>
&lt;matatk> q?<br>
&lt;fantasai> ... if I had the choice between strict visual order or using tabindex to enforce the order, I woudl want strict visual order<br>
&lt;fantasai> ... don't want to use tabindex, since we coach devs not to use it<br>
&lt;matatk> q?<br>
&lt;fantasai> TabAtkins: dilemma wans't use tabindex or not. There's an existing behavior where tabindex jumps across tree boundaries.<br>
&lt;fantasai> ... question is, is that behavior acceptable here to match strict visual ordering?<br>
&lt;fantasai> PaulG: Not a disservice to enforce strict visual order<br>
&lt;fantasai> ... avoid people using tabindex for that purpose<br>
&lt;matatk> q?<br>
&lt;fantasai> matatk: My thought is, what would be really helpful is if you could flag APA with the result of that PR<br>
&lt;fantasai> ... that would be helpful<br>
&lt;fantasai> matatk: Some of the examples were relating to custom controls using templates and shadow DOM.<br>
&lt;fantasai> ... does it work no matter what the context?<br>
&lt;fantasai> TabAtkins: slightly different if using components, because &lt;slot> is strict scoping container for tabindexing<br>
&lt;fantasai> ... all things in a &lt;slot> are grouped<br>
&lt;fantasai> matatk: I think we lean towards an accessibility view on it; but would be helpful to track 'display: contents'<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9230#issuecomment-2369872039 using your GitHub account


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

Received on Tuesday, 24 September 2024 00:43:08 UTC