- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Mon, 23 Sep 2024 23:36:19 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-display-4] Define how reading-flow interacts with focusable display: contents elements.`, and agreed to the following: * `RESOLVED: display:contents focusable element occurs immediately before its first child in visual order` <details><summary>The full IRC log of that discussion</summary> <TabAtkins> Di: so i'm gonna focus on the proposal of how to implement css reading-flow<br> <TabAtkins> Di: I'm the Blink engineer working on this new property<br> <TabAtkins> Di: quick summary, the reading-flow property is in Display 4 draft<br> <TabAtkins> Di: This redefines the navigation order when the user presses Tab, and similar for a11y tree<br> <TabAtkins> Di: currently only works on display:grid and flex elements<br> <TabAtkins> Di: but with other proposals that touch on display orderring, like Masonry, it'll get bigger<br> <TabAtkins> Di: This is valuable because it helps authors choose the right reading order for their users, when it doesn't match the dom order<br> <Di> https://rachelandrew.github.io/reading-order-items-examples/<br> <TabAtkins> Di: rachel has a video showing how unintuitive the current dom-based order can be and how this property can fix<br> <TabAtkins> Di: I want to talk about the impl of the feature, and some of the edge cases, like display:content or abspos/fixpos<br> <TabAtkins> Di: the goal here is to get more feedback on the HTML PR<br> <Di> https://github.com/whatwg/html/pull/10613<br> <TabAtkins> Di: any questions to start? otherwise i'll go into details<br> <masonf> q?<br> <TabAtkins> ack zcorpan<br> <TabAtkins> Di: the current impl defines reading-flow relative ot eh "reading flow scope owner"<br> <TabAtkins> Di: it's either a container with a 'reading-flow' value, or a display:contents whose parent is a reading-flow container<br> <zcorpan> s/ot eh/to the/<br> <rachelandrew> we moved examples to https://chrome.dev/reading-flow-examples/ where there are a couple more, and there's a short video on the TPAC site https://www.w3.org/2024/09/TPAC/demo-css.html<br> <TabAtkins> Di: Within this, the order isn't normal dom order, it shoudl use the container's layout to sort the elements according to the reading-flow value<br> <TabAtkins> Di: Like it could be grid-rows or grid-columns<br> <TabAtkins> Di: some items are not sorted by the layout, like elements that are abspos<br> <TabAtkins> Di: in that case, they're visited after the ones that are sorted, in normal dom tree order<br> <TabAtkins> domfarolino: the ones that aren't aprticipating in reading flow, are they traversed in dom order, or still based on normal tab index from outside reading flow?<br> <TabAtkins> Di: tabindex takes priority over reading flow<br> <TabAtkins> Di: so we'll sort the elements and get a "next" element, so within a tabindex value we can cycle between elements with the correct sorting<br> <kizu> q+<br> <zcorpan> q+<br> <astearns> ack kizu<br> <TabAtkins> kizu: so when we deffine inheritancce for scope, when you focus an element inside the scope, can you escape? do you always first go thru all elements in the scope before moving outwards, or can you mix and match?<br> <TabAtkins> Di: no mixing, within a scope you visit all the elements first<br> <TabAtkins> kizu: I think that's okay, but we might need an extra value like reading-flow:contain, otherwise people will establish scopes just for the scoping behavior<br> <TabAtkins> TabAtkins: I think there's some confusion, you always visit all the focusable elements in a given element anyway.<br> <astearns> some discussion of scopes, tab index and other things not minutes<br> <TabAtkins> [will fill in later]<br> <TabAtkins> zcorpan: question on the general need for this property<br> <past> ack zcorpan<br> <TabAtkins> zcorpan: the preivous sense of the csswg is people should use the dom order for correct reaading order<br> <TabAtkins> zcorpan: what changed? do we have more layout mechanism now, different layouts on different devices, etc? just inconvenient to reorder the dom<br> <TabAtkins> rachelandrew: we've got tons of dev feedback on the preivous issues<br> <TabAtkins> rachelandrew: loads of usecases where devs ask for this<br> <TabAtkins> rachelandrew: simple is you have a layout with grid where the ideal layout in mobile vs layout presents things in a differnet visual order<br> <TabAtkins> rachelandrew: we give people the ability to rearrang ethings with grid, then basically say don't do it because it causes this problem<br> <TabAtkins> rachelandrew: I'll link in threads later<br> <lea> +1 to rachelandrew, this is a very common pain point<br> <TabAtkins> rachelandrew: But pretty mcuh every workshop i've done someone has said "i want to do this, but you said I can't"<br> <astearns> resolution to work on this: https://github.com/w3c/csswg-drafts/issues/7387#issuecomment-1690281298<br> <TabAtkins> Di: So the author issues is talking more about display:contents, it's all related tho for focus scope navigation<br> <zcorpan> q+<br> <TabAtkins> annevk: wonder why you decided tab index should win in the end?<br> <TabAtkins> TabAtkins: is that asked with the understanding about focus groups, which scope the tabindex behavior?<br> <TabAtkins> annevk: there's a scoping aspect, but there's also an element-by-element feature<br> <TabAtkins> annevk: we invented the css feature to win out, but then HTML wins<br> <rachelandrew> lots of cases in this issue https://github.com/w3c/csswg-drafts/issues/7387<br> <TabAtkins> masonf: our general feeling is using this feature in conjunction with tabindex would be a mistake, but we still have to define what happens<br> <TabAtkins> annevk: one thing you could imagine is tabindex just delegates to the css feature<br> <rachelandrew> also dense packing causes reordering, and the author can't control it, as will masonry.<br> <TabAtkins> annevk: then you could use CSS to further override it<br> <TabAtkins> annevk: so if you reorder the visual vs Dom, you can use CSS to fix that<br> <TabAtkins> annevk: it makes sense to me that CSS would win, so we could explain the HTML in terms of that<br> <masonf> tabatkins: An earlier draft of this feature had a feature to specify an integer to give an ordering, but we removed it because it's not a great idea anyway.<br> <masonf> tabatkins: also the tabindex already exists, even though it's bad, it works for this use case. This feature (reading-flow) does what you can't do - match layout predictably.<br> <bkardell_> q+<br> <masonf> tabatkins: Otherwise, you'd have to use JS. We don't like explicit tabindex so we didn't want to copy it into CSS. So we're left with defining how tabindex interacts with this feature.<br> <astearns> removing the index resolution and discussion: https://github.com/w3c/csswg-drafts/issues/8589#issuecomment-1721504153<br> <TabAtkins> annevk: I thought the CSS feature has a scoping mechanism, and the ability to say focus next<br> <masonf> tabatkins: you can choose a few options, but not arbitrarily.<br> <masonf> tabatkins: several examples where that happens.<br> <zcorpan> q?<br> <TabAtkins> annevk: I don't have an answer as to why tabindex shouldn't just be ignored<br> <TabAtkins> annevk: Once you start using this, shouldn't we just ignore tabindex?<br> <TabAtkins> TabAtkins: We just needed to give an answer to how they work together. If you feel strongly otherwise, we can have an issue<br> <TabAtkins> annevk: Yeah, makes the most sense to me to have it be ignored<br> <TabAtkins> domfarolino: what do you think is better - making tabindex secondary, or ignoring completely?<br> <TabAtkins> annevk: I think ignoring completely, based on what I've heard.<br> <masonf> q+<br> <TabAtkins> annevk: probably woudln't want things moving around based on tabindex<br> <jarhar> q?<br> <astearns> ack fantasai<br> <Zakim> fantasai, you wanted to react to zcorpan<br> <TabAtkins> fantasai: so tabindex is set on the individual items, while reading-flow is set on the container. tabindex has a higher specificity, in a way<br> <TabAtkins> fantasai: we might want equivalent functionality in CSS that operates on the individual items - there might be cases where reading-flow can't work automatically<br> <TabAtkins> fantasai: I'm guessing that's the logic behind the current behavior<br> <TabAtkins> fantasai: but I do think it needs a little more thought to how things work together, when it's not just simple content being reordered<br> <TabAtkins> fantasai: for example, a right-hand sidebar, versus an item around that sidebar, might want the sidebar read first<br> <TabAtkins> fantasai: so we have some mixed cases. I think tabindex is somewhat addressing that<br> <fantasai> s/an item/a collection of auto-positioned items/<br> <dbaron> q+<br> <astearns> ack bkardell_<br> <TabAtkins> bkardell_: I think Anne suggested that if we had a property in CSS equivalent to tabindex, then we could explain tabindex in HTML with the CSS mechanism. Is that right?<br> <tantek> wow bkardell_ brings up nav-index<br> <TabAtkins> annevk: It was a thought, yes. Not a complete proposal.<br> <TabAtkins> annevk: but Tab made a convincing point that tabindex is a bad API, not sure we should just copy it<br> <tantek> pretty sure we implemented nav-index in Tasman back in the day<br> <TabAtkins> bkardell_: I liked your idea about ignoring it, would you ignore all of it?<br> <TabAtkins> annevk: No, focus ability would be preserved, we'd just ignore the ordering. At some point we could introduce a property that more specifically lets you do that targeting.<br> <masonf> q?<br> <TabAtkins> annevk: But the mix of the two doesn't make a lot of sense to me right now.<br> <bkardell_> +1 , agree with what annevk just said<br> <TabAtkins> annevk: If you are using tabindex for one view, but then rearrange for another view and use reading-order, we'd still have a messed up order<br> <lea> q?<br> <TabAtkins> domfarolino: so then you'd have to stop using tabindex entirely if you wanted to use reading-flow<br> <kizu> +1 to ignoring tabindex inside a reading-flow scope<br> <TabAtkins> annevk: Yeah, seems reasonable<br> <TabAtkins> zcorpan: Wanted to ask about the a11y mapping<br> <past> ack zcorpan<br> <TabAtkins> Di: we have asked for feedback<br> <TabAtkins> Di: the reading-flow items that are sorted, we use that to present the items in the a11y tree<br> <TabAtkins> Di: normally the a11y tree follows by Dom order, so the unsorted items we keep in dom order<br> <lea> Inclined to also +1 to ignoring tabindex within reading-flow, the opposite seems very confusing, and also this provides a way to fix the issues with tabindex with a smooth upgrade path<br> <TabAtkins> zcorpan: So the plan is to spec that the a11y tree is reordered, good<br> <past> ack fantasai<br> <masonf> q-<br> <TabAtkins> dbaron: about the tabindex thing<br> <TabAtkins> dbaron: my understanding of this is - and maybe it's wrong way to think about it - is that when you're trying to find the next thing to focus, there's a process that's a tree traversal<br> <TabAtkins> dbaron: what reading-flow is doing, in my head, is it's changing the order you visit a set of siblings within that tree traversal<br> <TabAtkins> dbaron: but not really changing the whole tree traversal, just the visitation order of those siblings<br> <TabAtkins> (and their concepts)<br> <TabAtkins> s/cepts/tents/<br> <astearns> (was also going to say subgrid might be an exception)<br> <TabAtkins> dbaron: maybe subgrid has an exception<br> <TabAtkins> dbaron: maybe that impinges on your point about tabindex working, this changes just the visitation order of the siblings<br> <past> q?<br> <past> ack dbaron<br> <TabAtkins> annevk: I see what you're saying, if you use tabindex to change the visitation order and there's tabindexes inside of a part, it stays useful<br> <TabAtkins> annevk: so does the scoping happen at the parent level, or for each sibling?<br> <TabAtkins> masonf: the parent<br> <TabAtkins> annevk: so that does run into the problem. if two grid items each have a tabindex value, then they'll be followed numerically, rather than according to the reordered values<br> <TabAtkins> masonf: I see your point there, we might need more thought<br> <TabAtkins> TabAtkins: agreed<br> <TabAtkins> I propose we ignore tabindex ordering *on the reordered children*, and then scope the childrne's subtrees<br> <TabAtkins> domfarolino: If we don't honor tabindex for the siblings, would we honor it inside the subtree?<br> <TabAtkins> annevk: I guess so, it makes sense with what David was saying<br> <TabAtkins> Di: So are there any questions about making display:contents a focus scope owner<br> <TabAtkins> masonf: in CSS if you have a flex or grid item that's display:contents, and that display:contents has tabindex, that item should be focusable and still be in the focus order. so the question is where in the sequential focus does it come up?<br> <TabAtkins> masonf: two current proposals<br> <TabAtkins> masonf: one is put all the display:contents children last<br> <TabAtkins> masonf: Other that feels cleaner and we think has fewer a11y issue, is you make display:contents children of these reading-flow containers focus groups themselves<br> <TabAtkins> rachelandrew: We asked devs if anyone is doing this, and couldn't find an example yet<br> <astearns> discussion and resolution about reading order and display:contents interaction: https://github.com/w3c/csswg-drafts/issues/9230#issuecomment-2261469723<br> <TabAtkins> rachelandrew: I think it's an unusual case to solve, not something we're seeing everywhere<br> <TabAtkins> masonf: we also prefer option 2, because eit's better for a11y and easier to implement<br> <masonf> tabatkins: because display:contents, they don't have a layout, but it's also safe to hold the layout, that makes sense.<br> <rachelandrew> https://developer.chrome.com/blog/reading-flow-display-contents the request for feedback I've been sharing, which explains the issue<br> <TabAtkins> s/hold the layout/pull the layout from the parent, and apply it to the children/<br> <ntim> Making flex items is not terribly uncommon fwiw<br> <ntim> Making flex items display: contents*<br> <TabAtkins> TabAtkins: As if the display:contents element become a display:flex (or whatever) holding its children<br> <TabAtkins> panos: Di, are you unblocked?<br> <TabAtkins> Di: Yes. We ask for everyone to look at the HTML spec PR<br> <ntim> I use it to conditionally hide a set of flex items sometimes<br> <emilio> q+<br> <TabAtkins> masonf: Everything should be in the Html PR, modulo the new tabindex question<br> <TabAtkins> annevk: So the display:contents thing is being resolved in this new property? Or only comes up in the context of this property?<br> <TabAtkins> masonf: Only comes up in this context.<br> <TabAtkins> annevk: Okay, it does sound like of your two options, putting the display:contents at the end was weird<br> <TabAtkins> Di: And <slot> is display:contents, which is why we spend so much time thinking about this<br> <past> ack emilio<br> <TabAtkins> emilio: This is only an issue if the display:contents is focusable, yeah?<br> <TabAtkins> masonf: current proposal is display:contents children of these containers *always* makes them into reading order containers<br> <TabAtkins> emilio: Okay, and that prevents reordering across siblings<br> <TabAtkins> emilio: So for the purpose of focus, this sis only an issue if the display:contents element was focusable as well<br> <TabAtkins> masonf: Yes, the traversal algo would be a little more complicated, but that's it<br> <ntim> example of what i use `display: contents` flex children for: https://jsfiddle.net/dk1Lryhj/<br> <zcorpan> s/this sis/this is/<br> <TabAtkins> emilio: I think ideally, if you don't have a focusable display:contents element, you'd want the behavior of visiting children in the visual order<br> <TabAtkins> masonf: I think yes, except the a11y tree becomes harder in that case.<br> <TabAtkins> masonf: And I think the tab order should match the a11y order<br> <TabAtkins> TabAtkins: Okay, so display:contents scopes the ordering, even if their items are visually interwoven<br> <TabAtkins> emilio: that seems a little confusing to me as an author, you're saying use the visual order, but you don't get that<br> <TabAtkins> masonf: Yeah, all the possible solutions aren't obvious<br> <TabAtkins> emilio: display:contents that's focusable is indeed rare, but display:contents that isn't focusable seems a lot more common.<br> <TabAtkins> emilio: that's the main use-case of display:contents, to let the parent take up the children<br> <TabAtkins> masonf: If focus order was all we had to deal with, I'd agree<br> <TabAtkins> emilio: Yeah, I understand the a11y tree makes it hard.<br> <TabAtkins> rachelandrew: It seems that people are generally using display:contents in mostly simplistic ways at the moment<br> <TabAtkins> rachelandrew: whenever I ask for example they're just removing a wrapper from an element<br> <TabAtkins> emilio: right, but I think it would break even simple cases. A control with a label, in a display:contents container. If I visually lay them out so multiple labels are together...<br> <TabAtkins> masonf: slots are *already* focus scoped, actually, so that "breaks" today already<br> <TabAtkins> emilio: Hm, the way I'd want to use this feature might override that behavior...<br> <TabAtkins> masonf: Yeah, we're proposing to make display:contents act like how slots work today<br> <TabAtkins> [discussion of the grid use-case]<br> <TabAtkins> rachelandrew: We have tried to design some friction into this property anyway, so people don't just apply it willy-nilly.<br> <TabAtkins> emilio: so the main issue I guess is there's just no way to get the reordering use-case to work. maybe we're fine with that.<br> <TabAtkins> q?<br> <TabAtkins> emilio: So I think there are some realistic use-cases that would break under this behavior.<br> <fantasai> I think it would be useful to collect actual design use cases; the Google examples are quite simplistic and good for teaching but I think don't represent the complexity of what authors may need to do<br> <TabAtkins> emilio: two non-slots, forget the slot behavior<br> <TabAtkins> emilio: both display:contents, and use 'order' to put some elements of each at the top, you'd still get the weird order<br> <TabAtkins> masonf: It doesn't work in that it gives the wrong order, but at least it is focusable<br> <TabAtkins> annevk: So you couldn't find much cases where display:contents is focusable, but we thought it was important for display:contents to be focusable, how do those square<br> <TabAtkins> TabAtkins: Rachel has a lot of examples of *simple* display:contents use, just not complex ones that would run into this discussed issue<br> <TabAtkins> dbaron: I think there was a big discussion of whether display:contents should be in the a11y tree.<br> <TabAtkins> dbaron: there was a strong agreement that there should be, we all shipped it, *then* we had the trouble that the focus order didn't match the a11y order, and things were broken<br> <TabAtkins> lea: If authors need slots to be focusable, they'd also override display:contents, right?<br> <TabAtkins> annevk: I'm still confused that display:contents isn't more like display:none<br> <TabAtkins> TabAtkins: If you display:contents an <a>, the contents are still clickable. They need to be focusable too<br> <TabAtkins> annevk: Becuase links are done via Dom structure...<br> <TabAtkins> [more discussion about links being display:contents]<br> <TabAtkins> masonf: So this has been a good discussion. Dont' think anyone's come up with a better idea so far, but if anyone does...<br> <TabAtkins> annevk: Probably just doing what slots do today is fine, and if we need further overrides we can develop that.<br> <TabAtkins> annevk: Even if it comes up in practice for one person, we should probably wait a few...<br> <TabAtkins> lea: What if you call El.focus() on a display:contents element?<br> <TabAtkins> emilio: Under dbaron's proposed behavior, it does get focused.<br> <ntim> i feel like the discussion is getting off topic from the original issue<br> <TabAtkins> emilio: today it's not focusable<br> <TabAtkins> dbaron: But we want to change it<br> <TabAtkins> [point of order, no more breakouts within the room]<br> <fantasai> scribe+<br> <fantasai> TabAtkins: Sounds like conclusion is that [missed]<br> <fantasai> TabAtkins: although someone uncomfortable, nobody has a beter idea<br> <fantasai> s/[missed]/thing currently marked option 2 in PR/<br> <fantasai> TabAtkins: making `display: contents` work the same way as <slot>s do today<br> <TabAtkins> Di: So option 2 is make display:contents its own focus-scope owner, similar to <slot><br> <TabAtkins> Di: What Dom is mentioning about putting display:contents last is a different part of the proposal<br> <TabAtkins> Di: And that other part is "everything not part of the layout just goes at the end, after all the visually-sorted options"<br> <TabAtkins> fantasai: So if I have a grid with a display:contents child, and *its* children are reordered by the parent grid, what happens<br> <TabAtkins> fantasai: so we have a flex with children A, B, C. B is display:contents with B1 and B2 children<br> <TabAtkins> fantasai: visual order is A B1 C B2<br> <TabAtkins> Di: So the focus order is currently A C B1 B2 - the display:contents is put at the end, as it's not visually sorted, and then its children are sorted visually<br> <TabAtkins> fantasai: okay new order A B1 B2 C<br> <TabAtkins> fantasai: But I've set reading-flow on this element<br> <TabAtkins> fantasai: As an author I'd expect reading-flow to not change the order of things<br> <TabAtkins> annevk: I'm also confused about thtis<br> <TabAtkins> masonf: two issues, one is whether display:contents forms a scope<br> <TabAtkins> annevk: Yeah, assume we do that to align with slot<br> <TabAtkins> masonf: Then we have a choice where to put the display:contents children<br> <TabAtkins> emilio: Put them where in the visual order the first sub-item shows up?<br> <TabAtkins> emilio: I think fantasai was hinting at this<br> <TabAtkins> emilio: when you're iterating the items, you can figure out "this item's layout parent isn't it's Dom parent, so it's display:contents"<br> <TabAtkins> emilio: so at that point you'd walk the display:contents subtree and do them in visual order<br> <TabAtkins> dbaron: so two options I think I heard<br> <TabAtkins> dbaron: one is when you hit the first Dom child of the display:contents<br> <TabAtkins> dbaron: another is when you hit the first *visual order* child of the display:contents<br> <TabAtkins> fantasai: the second one<br> <TabAtkins> emilio: I also think second, it allows more intuitive behavior when you reorder inside the display:contents<br> <TabAtkins> fantasai: I think it's important to make sure A B1 B2 C order stays as it is, you haven't moved *anything*<br> <TabAtkins> fantasai: Also would be good to have A B2 B1 C (with 'order') to work visually<br> <TabAtkins> fantasai: These are the most common by far cases of using display:contents<br> <TabAtkins> fantasai: the full re-ordering examples are much rarer<br> <TabAtkins> annevk: What if the visual order is C B2 B1 A, reversed?<br> <TabAtkins> fantasai: Yes, should still work visually. As long as the items are in contiguous visual order, it should still work<br> <TabAtkins> emilio: Say you flip the order in a display:contents. question is what tab order would you expect<br> <TabAtkins> emilio: I think ideal is what elika said, actually reorder them<br> <TabAtkins> emilio: I dunno how that interacts with the scope owner thing<br> <fantasai> s/full re-ordering examples/full re-ordering examples with interleaving/<br> <TabAtkins> emilio: Unsure if we can go back up to the parent and look at that reading order<br> <TabAtkins> masonf: Layout's already happened, you know the order.<br> <TabAtkins> masonf: So it sounds like people agree that display:contents is a scope owner, regardless<br> <TabAtkins> masonf: Then the question of what order relative to other things, which it sounds like we're coming toward<br> <TabAtkins> annevk: So if the visual order is B1 A C B2...<br> <TabAtkins> masonf: order would be B1 B2 A C in tabbing<br> <ntim> In https://jsfiddle.net/0x5yuLd2/1/, I would expect the order to be "first name, last name, credit card, cvv, expiration"<br> <TabAtkins> emeyer: I'm still not okay with the display:contents reordering, if visual order doesn't match even tho I asked for it, I think CSS is broken<br> <TabAtkins> masonf: Problem is the a11y tree is also "broken" in that case<br> <TabAtkins> chrishtr: We think the full-interleaving case is an uncommon example. It works fine if there isn't interleaving.<br> <TabAtkins> emeyer: Yeah, just giving the author-facing feedback<br> <TabAtkins> chrishtr: Okay so if it's a focus scope owner<br> <TabAtkins> chrishtr: What's the exact proposed ordering, to not put the display:contents at the end?<br> <TabAtkins> TabAtkins: You go thru the layout order, until you hit one that's in a different focus scope, then you recurse into that focus scope, then pop back out<br> <TabAtkins> annevk: The main reason it has to be a scope owner is that really the order is B B2 B1, not just B2 B1<br> <TabAtkins> chrishtr: Di, does that make sense to you, giving impl experience?<br> <TabAtkins> Di: Yeah, have a question since we don't actually see the B element in the visual order<br> <TabAtkins> emilio: You'd hit B1 visually, note that its parent is display:contents, then actually put B into the order, then B1, B2<br> <TabAtkins> annevk: [missed an example]<br> <TabAtkins> masonf: That makes the algorithm stateful, currently it's stateless<br> <TabAtkins> dbaron: It doesn't have to be stateful, but making it stateless is expensive, you have to crawl the Dom to see if we *would* have hit the element<br> <TabAtkins> fantasai: Here's an example of reordering'<br> <TabAtkins> fantasai: you have a number control, has plus and minus button<br> <TabAtkins> fantasai: So your control is some container, it's got a text input, and a plus and minus button.<br> <TabAtkins> fantasai: you want to lay it out with + on the left and - on the right. You use display:contents on the control wrapper<br> <TabAtkins> [I didn't understand the example actually, i'm confused]<br> <TabAtkins> fantasai: So the a11y tree should be able to see the "control" itself (as a wrapper) before we actually hit the + button<br> <TabAtkins> dbaron: So my question is when do we recurse into the display:contents<br> <TabAtkins> dbaron: Do we do it when we encounter the first visual child, or the first DOM child?<br> <TabAtkins> dbaron: In the second, if something else was interleaved, we'd do the interleaved first, *then* hit the first child of the display:contents and do the subtree<br> <TabAtkins> [everyone agrees that's bad, it should be the first visual child<br> <TabAtkins> ]<br> <TabAtkins> emilio: Is the "first visual child" thing different if you navigate backwards?<br> <TabAtkins> dbaron: If you care about first visual child when tabbing forward, you need to care about the last visual child when going back<br> <TabAtkins> masonf: agreed<br> <TabAtkins> annevk: Again we have the visual order of B2 A B1, the focus traversal would match but with the B wrapper, B B2 B1 A<br> <TabAtkins> (sorry, he said B B2 A B1)<br> <TabAtkins> masonf: No, that breaks the a11y tree. They're always siblings in the a11y tree, so it has to be B B2 B1 A<br> <TabAtkins> annevk: So B is a hard owner of its tabbing order due to the a11y tree<br> <TabAtkins> chrishtr: Rachel, any thoughts from a teaching perspective?<br> <TabAtkins> rachelandrew: I think it's weird whatever. But consistency with <slot> is useful<br> <TabAtkins> rachelandrew: I don't feel like there's a better solution.<br> <TabAtkins> rachelandrew: And I don't think the interleaving case is a common situation anyway.<br> <TabAtkins> Sanket: So there's focus scope owner, is it only slot and display:contents?<br> <TabAtkins> [no, there's several others, like dialog]<br> <TabAtkins> sanket: So those already behave this way?<br> <TabAtkins> chrishtr: For focus, yes.<br> <TabAtkins> annevk: The display:contents case is special because it's not actually displayed<br> <TabAtkins> emilio: Request, to make emeyer happy<br> <TabAtkins> emilio: The main thing that prevents us from doing splitting is making the a11y and focus order match.<br> <TabAtkins> emilio: Is it well-documented why they need to be the same? Is it better to break that for this case, or?<br> <TabAtkins> annevk: I was curious too, if that's really a hard limitation there's no future solution either.<br> <TabAtkins> emilio: Yeah, wondering if it's a hard blocker<br> <TabAtkins> masonf: We're not the experts, but we've been told it's needed<br> <TabAtkins> ???: Does tabindex rearrange the a11y tree?<br> <TabAtkins> chrishtr: No<br> <TabAtkins> dbaron: There's a difference between "here's a thing, and you can't get to it at all" and "here's a thing, and it's in a weird position". pretty big difference<br> <fantasai> TabAtkins: We're doing the whole scope owner thing because wanted to push to the end<br> <fantasai> TabAtkins: if we're adopting where it is visually, then might not need to<br> <fantasai> TabAtkins: B still needs to show up before its first visual child<br> <fantasai> emilio: Reason we needed it was so that it doesn't mismatch the a11y tree<br> <fantasai> TabAtkins: but you can currently use tabindex<br> <fantasai> emilio: Right, you can already mismatch<br> <fantasai> annevk: maybe don't need to match tree, but [missed]<br> <fantasai> TabAtkins: if you use A and tabindex on A and 2 children inside the A, and on something else<br> <fantasai> TabAtkins: your order can flip back and forth<br> <fantasai> TabAtkins: if you display:contents the A, don't know where to put it<br> <fantasai> TabAtkins: but if we define "it goes just before its first visual child" then we're back to where we were before display:contents<br> <fantasai> TabAtkins: with this answer to where we put it, i.e. right efore first visual child, we don't need to do scope owner<br> <fantasai> emilio: right, and we have precedent for that<br> <fantasai> ?: do we need scope owner for <slot> then still?<br> <fantasai> emilio: My understanding was to avoid conflicting with a11y tree, but can already diverge with tabindex so maybe we can make Eric happy<br> <astearns> s/?/Di/<br> <fantasai> mfreed: an exmaple without tabindex, you have a mismatch<br> <fantasai> emilio: is that a problem?<br> <fantasai> ...<br> <TabAtkins> TabAtkins: tabindex is a bad *design*, but I'm not sure if it's actually a bad thing *for a11y* here<br> <fantasai> emilio: if we need to make 'display: contents' focus scope owner for matching a11y, if that's a hard block can we document vry clearly why?<br> <TabAtkins> domfarolino: So next step, talk to a11y people to see if it's *okay* to have another case, like tabindex, of tab order mismatching a11y order?<br> <TabAtkins> emilio: Yes. If we get feedback that it's bad, we have consensus on scope owner + first visual item.<br> <TabAtkins> fantasai: So we can resolve on first visual, and figur e out scope later<br> <bkardell_> I just wanted to mention that it looked like the aria group was discussing some of these same things when we started in their group - it sounds like they had questions for us, and we have (if I understand) questions for them. We're in the same actual location, maybe we should get together and talk<br> <TabAtkins> fantasai: proposed resolution: display:contents focusable element occurs in the order immediately before its child that's first in visual order<br> <TabAtkins> dbaron: and when tabbing in reverse, it's still preceding it in the original order, so reverse-tabbing it's after<br> <ntim> emilio: needs tweaking for nested display: contents<br> <masonf> +1<br> <fantasai> RESOLVED: display:contents focusable element occurs immediately before its first child in visual order<br> <ntim> 🎉 🎉<br> <ntim> 🍾<br> <dbaron> (and probably an empty display contents goes at the end?)<br> <TabAtkins> proposed resolution: tabindex is ignored (for order purposes) on the items of a reading-flow container, but it *scoped* to those items if on descendants<br> <TabAtkins> proposed resolution not passed, we'll discuss in an issue<br> <Lionel_Wolberger> scribe+<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-2369780005 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 23 September 2024 23:36:20 UTC