Meeting minutes
<jarhar> whatwg/
past: First topic adding a new member to the "blocking" set
github-bot, topic whatwg/
<github-bot> TabAtkins, I can't comment on that github issue because it's not in a repository I'm allowed to comment on, which are: w3c/csswg-drafts w3c/fxtf-drafts w3c/css-houdini-drafts w3c/svgwg web-platform-tests/wpt WICG/animation-worklet WICG/construct-stylesheets WICG/scroll-animations WICG/custom-state-pseudo-class.
New "blocking" value for VTs
noamr: When we started cross-doc VTs, we talked last year at TPAC that we'd be relying on the render-blocking mechanism of the browser
noamr: We added a while back a "blocking" attribute to control this better, so it's not just stylesheets.
noamr: When the page is unblocked from rendering, the VT starts
noamr: The main disconnection is that render blocking isn't just for VT, it's also for preventing a flash of unstyled content
noamr: So people can avoid doing tricks with hiding content and revealing with script after it's rendered
noamr: There are situations where VT render blocking and document render blocking have reasons to be slightly different
noamr: one is timeout
noamr: If what you're preventing is af lash of unstyled content, we can't reason about the correct timeout
noamr: say we ahve a render-blocked page, and we wanted to unblock it automatically after 5s
noamr: What'll happen is a flash of unstyled content until the stylesheet loads
noamr: did we improve the user experience? will people just go back to loading the css via js?
noamr: in VT this is different, they're just a progressive enhancement
noamr: We can say if the page didn't unblock after a second or two, it doesn't matter for the VT. We don't have to unblock the whole page, but can skip the VT and unblock that element
noamr: The initial proposal we discussed is, this works with blocking=render
noamr: But blocking can accept mroe values, potentially
noamr: we can say a possible value is blocking=view-transition
noamr: that could have a different timeout, and wouldn't block if there wasn't a VT
noamr: would just give the browser a little time to prep the VT, rather than blocking for unstyled content
(seems good to me)
emilio: what are the specifics here? what do you mean by "it won't block when there's no VT"
emilio: When there's no incoming? or when there's none starting on the new page?
noamr: The former, incoming VT.
noamr: If there's no incoming VT, with blocking=view-transition we wouldn't block, there's no reason to
emilio: okay I think that's better than blocking for all VTs, yeah
zcorpan: what's the current timeout for render=blocking?
noamr: in the spec it's U
noamr: UA-defined
noamr: in Chromium we don't have one. we can't reason about whether unblocking will just give you unstyled content, and whether that's better or not for the user
noamr: If there's a network request for a render-blocking resource *taht* can timeout eventually and unblock
annevk: since websites currently use blocking=render in a way that's bad for VT, do we expect them to know which of these APIs to use correctly?
annevk: If they're already doing it wrong, i wonder if they have enough knowledge of which to apply to do it well
noamr: I think people are already using blocking=render for VT, so they're using the tool they have. but it's too blunt of an instrument for them
noamr: So new people learning the blocking feature will be able to see that it has a view-transition value, that guides them. they won't need to use render
annevk: sounds reasonable
<ntim> I asked Matt Woodrow about this issue and here was his reply:
<ntim> > I guess I'd like to know more about the use cases they had in mind. If I'm reading this correctly, this lets the author say "if there's a view transition, then wait for this subresource to load, but if there's not, then it's fine to render without it".
<ntim> It's not super obvious that that's a common thing to want?
annevk: just hope that next year we dont' have another case
noamr: in the design work for blocking=render it had a list of cases to jsutify it, if we have more cases it doesn't weaken it
zcorpan: i thought document render blocking was mainly added for the VT use-case
zcorpan: if we want different behavior, what are the other use-cases we want to preserve the current behavior for?
noamr: there are people who use render blocking to avoid usntyled content
noamr: some people that were using popular libraries for JS-based render blocking - display:none and removing it in script
zcorpan: that's subresource render blocking
noamr: not only
noamr: there were people who didn't want gradually-rendered content to appar
zcorpan: okay, that's fine
zcorpan: was just wondering if we could redefined document render blocking to be better for VT, but seems like that's not the case. so a second value makes sense
<ntim> Also from Matt: I also don't love yet another (shorter) implementation defined timeout. Seems like it'll cause confusion as sometimes VTs just won't run and it likely won't be consistent between browsers.
<ntim> Hard to reason about all the different timeouts
ntim: I left some feedback from Matt Woodrow in IRC
ntim: [narrates previous comments]
noamr: I think the impl-defined timeout is a godo question
noamr: for regular render blocking we might not have one at all, or maybe a very long
noamr: we already have a delay for same-document VTs, so this isn't really a new concept, we're just applying it to cross-document
noamr: But yes, regardless of timing itself, having something that doesn't block if you don't have a VT is useful regardless of whether you have a timeout of not. Just coming to a page and blocking when there's no reason to isn't a good user experience.
past: Are you unblocked to move forward?
noamr: Yes, I think so.
reading-flow
past: there's a bunch of links
Di: from the agenda for this meeting, many issues are related to each other
<astearns> github-bot, take up w3c/
[css-display-4] Define how reading-flow interacts with focusable display: contents elements.
<github-bot> OK, I'll post this discussion to https://
Di: so i'm gonna focus on the proposal of how to implement css reading-flow
Di: I'm the Blink engineer working on this new property
Di: quick summary, the reading-flow property is in Display 4 draft
Di: This redefines the navigation order when the user presses Tab, and similar for a11y tree
Di: currently only works on display:grid and flex elements
Di: but with other proposals that touch on display orderring, like Masonry, it'll get bigger
Di: This is valuable because it helps authors choose the right reading order for their users, when it doesn't match the dom order
<Di> https://
Di: rachel has a video showing how unintuitive the current dom-based order can be and how this property can fix
Di: I want to talk about the impl of the feature, and some of the edge cases, like display:content or abspos/fixpos
Di: the goal here is to get more feedback on the HTML PR
<Di> whatwg/
Di: any questions to start? otherwise i'll go into details
Di: the current impl defines reading-flow relative to the "reading flow scope owner"
Di: it's either a container with a 'reading-flow' value, or a display:contents whose parent is a reading-flow container
<rachelandrew> we moved examples to https://
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
Di: Like it could be grid-rows or grid-columns
Di: some items are not sorted by the layout, like elements that are abspos
Di: in that case, they're visited after the ones that are sorted, in normal dom tree order
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?
Di: tabindex takes priority over reading flow
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
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?
Di: no mixing, within a scope you visit all the elements first
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
TabAtkins: I think there's some confusion, you always visit all the focusable elements in a given element anyway.
<astearns> some discussion of scopes, tab index and other things not minutes
[will fill in later]
zcorpan: question on the general need for this property
zcorpan: the preivous sense of the csswg is people should use the dom order for correct reaading order
zcorpan: what changed? do we have more layout mechanism now, different layouts on different devices, etc? just inconvenient to reorder the dom
rachelandrew: we've got tons of dev feedback on the preivous issues
rachelandrew: loads of usecases where devs ask for this
rachelandrew: simple is you have a layout with grid where the ideal layout in mobile vs layout presents things in a differnet visual order
rachelandrew: we give people the ability to rearrang ethings with grid, then basically say don't do it because it causes this problem
rachelandrew: I'll link in threads later
<lea> +1 to rachelandrew, this is a very common pain point
rachelandrew: But pretty mcuh every workshop i've done someone has said "i want to do this, but you said I can't"
<astearns> resolution to work on this: w3c/
Di: So the author issues is talking more about display:contents, it's all related tho for focus scope navigation
annevk: wonder why you decided tab index should win in the end?
TabAtkins: is that asked with the understanding about focus groups, which scope the tabindex behavior?
annevk: there's a scoping aspect, but there's also an element-by-element feature
annevk: we invented the css feature to win out, but then HTML wins
<rachelandrew> lots of cases in this issue w3c/
masonf: our general feeling is using this feature in conjunction with tabindex would be a mistake, but we still have to define what happens
annevk: one thing you could imagine is tabindex just delegates to the css feature
<rachelandrew> also dense packing causes reordering, and the author can't control it, as will masonry.
annevk: then you could use CSS to further override it
annevk: so if you reorder the visual vs Dom, you can use CSS to fix that
annevk: it makes sense to me that CSS would win, so we could explain the HTML in terms of that
<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.
<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.
<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.
<astearns> removing the index resolution and discussion: w3c/
annevk: I thought the CSS feature has a scoping mechanism, and the ability to say focus next
<masonf> tabatkins: you can choose a few options, but not arbitrarily.
<masonf> tabatkins: several examples where that happens.
annevk: I don't have an answer as to why tabindex shouldn't just be ignored
annevk: Once you start using this, shouldn't we just ignore tabindex?
TabAtkins: We just needed to give an answer to how they work together. If you feel strongly otherwise, we can have an issue
annevk: Yeah, makes the most sense to me to have it be ignored
domfarolino: what do you think is better - making tabindex secondary, or ignoring completely?
annevk: I think ignoring completely, based on what I've heard.
annevk: probably woudln't want things moving around based on tabindex
<Zakim> fantasai, you wanted to react to zcorpan
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
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
fantasai: I'm guessing that's the logic behind the current behavior
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
fantasai: for example, a right-hand sidebar, versus a collection of auto-positioned items around that sidebar, might want the sidebar read first
fantasai: so we have some mixed cases. I think tabindex is somewhat addressing that
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?
<tantek> wow bkardell_ brings up nav-index
annevk: It was a thought, yes. Not a complete proposal.
annevk: but Tab made a convincing point that tabindex is a bad API, not sure we should just copy it
<tantek> pretty sure we implemented nav-index in Tasman back in the day
bkardell_: I liked your idea about ignoring it, would you ignore all of it?
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.
annevk: But the mix of the two doesn't make a lot of sense to me right now.
<bkardell_> +1 , agree with what annevk just said
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
domfarolino: so then you'd have to stop using tabindex entirely if you wanted to use reading-flow
<kizu> +1 to ignoring tabindex inside a reading-flow scope
annevk: Yeah, seems reasonable
zcorpan: Wanted to ask about the a11y mapping
Di: we have asked for feedback
Di: the reading-flow items that are sorted, we use that to present the items in the a11y tree
Di: normally the a11y tree follows by Dom order, so the unsorted items we keep in dom order
<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
zcorpan: So the plan is to spec that the a11y tree is reordered, good
dbaron: about the tabindex thing
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
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
dbaron: but not really changing the whole tree traversal, just the visitation order of those siblings
(and their contents)
<astearns> (was also going to say subgrid might be an exception)
dbaron: maybe subgrid has an exception
dbaron: maybe that impinges on your point about tabindex working, this changes just the visitation order of the siblings
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
annevk: so does the scoping happen at the parent level, or for each sibling?
masonf: the parent
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
masonf: I see your point there, we might need more thought
TabAtkins: agreed
I propose we ignore tabindex ordering *on the reordered children*, and then scope the childrne's subtrees
domfarolino: If we don't honor tabindex for the siblings, would we honor it inside the subtree?
annevk: I guess so, it makes sense with what David was saying
Di: So are there any questions about making display:contents a focus scope owner
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?
masonf: two current proposals
masonf: one is put all the display:contents children last
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
rachelandrew: We asked devs if anyone is doing this, and couldn't find an example yet
<astearns> discussion and resolution about reading order and display:contents interaction: w3c/
rachelandrew: I think it's an unusual case to solve, not something we're seeing everywhere
masonf: we also prefer option 2, because eit's better for a11y and easier to implement
<masonf> tabatkins: because display:contents, they don't have a layout, but it's also safe to pull the layout from the parent, and apply it to the children, that makes sense.
<rachelandrew> https://
<ntim> Making flex items is not terribly uncommon fwiw
<ntim> Making flex items display: contents*
TabAtkins: As if the display:contents element become a display:flex (or whatever) holding its children
panos: Di, are you unblocked?
Di: Yes. We ask for everyone to look at the HTML spec PR
<ntim> I use it to conditionally hide a set of flex items sometimes
masonf: Everything should be in the Html PR, modulo the new tabindex question
annevk: So the display:contents thing is being resolved in this new property? Or only comes up in the context of this property?
masonf: Only comes up in this context.
annevk: Okay, it does sound like of your two options, putting the display:contents at the end was weird
Di: And <slot> is display:contents, which is why we spend so much time thinking about this
emilio: This is only an issue if the display:contents is focusable, yeah?
masonf: current proposal is display:contents children of these containers *always* makes them into reading order containers
emilio: Okay, and that prevents reordering across siblings
emilio: So for the purpose of focus, this is only an issue if the display:contents element was focusable as well
masonf: Yes, the traversal algo would be a little more complicated, but that's it
<ntim> example of what i use `display: contents` flex children for: https://
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
masonf: I think yes, except the a11y tree becomes harder in that case.
masonf: And I think the tab order should match the a11y order
TabAtkins: Okay, so display:contents scopes the ordering, even if their items are visually interwoven
emilio: that seems a little confusing to me as an author, you're saying use the visual order, but you don't get that
masonf: Yeah, all the possible solutions aren't obvious
emilio: display:contents that's focusable is indeed rare, but display:contents that isn't focusable seems a lot more common.
emilio: that's the main use-case of display:contents, to let the parent take up the children
masonf: If focus order was all we had to deal with, I'd agree
emilio: Yeah, I understand the a11y tree makes it hard.
rachelandrew: It seems that people are generally using display:contents in mostly simplistic ways at the moment
rachelandrew: whenever I ask for example they're just removing a wrapper from an element
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...
masonf: slots are *already* focus scoped, actually, so that "breaks" today already
emilio: Hm, the way I'd want to use this feature might override that behavior...
masonf: Yeah, we're proposing to make display:contents act like how slots work today
[discussion of the grid use-case]
rachelandrew: We have tried to design some friction into this property anyway, so people don't just apply it willy-nilly.
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.
emilio: So I think there are some realistic use-cases that would break under this behavior.
<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
emilio: two non-slots, forget the slot behavior
emilio: both display:contents, and use 'order' to put some elements of each at the top, you'd still get the weird order
masonf: It doesn't work in that it gives the wrong order, but at least it is focusable
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
TabAtkins: Rachel has a lot of examples of *simple* display:contents use, just not complex ones that would run into this discussed issue
dbaron: I think there was a big discussion of whether display:contents should be in the a11y tree.
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
lea: If authors need slots to be focusable, they'd also override display:contents, right?
annevk: I'm still confused that display:contents isn't more like display:none
TabAtkins: If you display:contents an <a>, the contents are still clickable. They need to be focusable too
annevk: Becuase links are done via Dom structure...
[more discussion about links being display:contents]
masonf: So this has been a good discussion. Dont' think anyone's come up with a better idea so far, but if anyone does...
annevk: Probably just doing what slots do today is fine, and if we need further overrides we can develop that.
annevk: Even if it comes up in practice for one person, we should probably wait a few...
lea: What if you call El.focus() on a display:contents element?
emilio: Under dbaron's proposed behavior, it does get focused.
<ntim> i feel like the discussion is getting off topic from the original issue
emilio: today it's not focusable
dbaron: But we want to change it
[point of order, no more breakouts within the room]
TabAtkins: Sounds like conclusion is that thing currently marked option 2 in PR
TabAtkins: although someone uncomfortable, nobody has a beter idea
TabAtkins: making `display: contents` work the same way as <slot>s do today
Di: So option 2 is make display:contents its own focus-scope owner, similar to <slot>
Di: What Dom is mentioning about putting display:contents last is a different part of the proposal
Di: And that other part is "everything not part of the layout just goes at the end, after all the visually-sorted options"
fantasai: So if I have a grid with a display:contents child, and *its* children are reordered by the parent grid, what happens
fantasai: so we have a flex with children A, B, C. B is display:contents with B1 and B2 children
fantasai: visual order is A B1 C B2
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
fantasai: okay new order A B1 B2 C
fantasai: But I've set reading-flow on this element
fantasai: As an author I'd expect reading-flow to not change the order of things
annevk: I'm also confused about thtis
masonf: two issues, one is whether display:contents forms a scope
annevk: Yeah, assume we do that to align with slot
masonf: Then we have a choice where to put the display:contents children
emilio: Put them where in the visual order the first sub-item shows up?
emilio: I think fantasai was hinting at this
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"
emilio: so at that point you'd walk the display:contents subtree and do them in visual order
dbaron: so two options I think I heard
dbaron: one is when you hit the first Dom child of the display:contents
dbaron: another is when you hit the first *visual order* child of the display:contents
fantasai: the second one
emilio: I also think second, it allows more intuitive behavior when you reorder inside the display:contents
fantasai: I think it's important to make sure A B1 B2 C order stays as it is, you haven't moved *anything*
fantasai: Also would be good to have A B2 B1 C (with 'order') to work visually
fantasai: These are the most common by far cases of using display:contents
fantasai: the full re-ordering examples with interleaving are much rarer
annevk: What if the visual order is C B2 B1 A, reversed?
fantasai: Yes, should still work visually. As long as the items are in contiguous visual order, it should still work
emilio: Say you flip the order in a display:contents. question is what tab order would you expect
emilio: I think ideal is what elika said, actually reorder them
emilio: I dunno how that interacts with the scope owner thing
emilio: Unsure if we can go back up to the parent and look at that reading order
masonf: Layout's already happened, you know the order.
masonf: So it sounds like people agree that display:contents is a scope owner, regardless
masonf: Then the question of what order relative to other things, which it sounds like we're coming toward
annevk: So if the visual order is B1 A C B2...
masonf: order would be B1 B2 A C in tabbing
<ntim> In https://
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
masonf: Problem is the a11y tree is also "broken" in that case
chrishtr: We think the full-interleaving case is an uncommon example. It works fine if there isn't interleaving.
emeyer: Yeah, just giving the author-facing feedback
chrishtr: Okay so if it's a focus scope owner
chrishtr: What's the exact proposed ordering, to not put the display:contents at the end?
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
annevk: The main reason it has to be a scope owner is that really the order is B B2 B1, not just B2 B1
chrishtr: Di, does that make sense to you, giving impl experience?
Di: Yeah, have a question since we don't actually see the B element in the visual order
emilio: You'd hit B1 visually, note that its parent is display:contents, then actually put B into the order, then B1, B2
annevk: [missed an example]
masonf: That makes the algorithm stateful, currently it's stateless
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
fantasai: Here's an example of reordering'
fantasai: you have a number control, has plus and minus button
fantasai: So your control is some container, it's got a text input, and a plus and minus button.
fantasai: you want to lay it out with + on the left and - on the right. You use display:contents on the control wrapper
[I didn't understand the example actually, i'm confused]
fantasai: So the a11y tree should be able to see the "control" itself (as a wrapper) before we actually hit the + button
dbaron: So my question is when do we recurse into the display:contents
dbaron: Do we do it when we encounter the first visual child, or the first DOM child?
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
[everyone agrees that's bad, it should be the first visual child
]
emilio: Is the "first visual child" thing different if you navigate backwards?
dbaron: If you care about first visual child when tabbing forward, you need to care about the last visual child when going back
masonf: agreed
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
(sorry, he said B B2 A B1)
masonf: No, that breaks the a11y tree. They're always siblings in the a11y tree, so it has to be B B2 B1 A
annevk: So B is a hard owner of its tabbing order due to the a11y tree
chrishtr: Rachel, any thoughts from a teaching perspective?
rachelandrew: I think it's weird whatever. But consistency with <slot> is useful
rachelandrew: I don't feel like there's a better solution.
rachelandrew: And I don't think the interleaving case is a common situation anyway.
Sanket: So there's focus scope owner, is it only slot and display:contents?
[no, there's several others, like dialog]
sanket: So those already behave this way?
chrishtr: For focus, yes.
annevk: The display:contents case is special because it's not actually displayed
emilio: Request, to make emeyer happy
emilio: The main thing that prevents us from doing splitting is making the a11y and focus order match.
emilio: Is it well-documented why they need to be the same? Is it better to break that for this case, or?
annevk: I was curious too, if that's really a hard limitation there's no future solution either.
emilio: Yeah, wondering if it's a hard blocker
masonf: We're not the experts, but we've been told it's needed
???: Does tabindex rearrange the a11y tree?
chrishtr: No
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
TabAtkins: We're doing the whole scope owner thing because wanted to push to the end
TabAtkins: if we're adopting where it is visually, then might not need to
TabAtkins: B still needs to show up before its first visual child
emilio: Reason we needed it was so that it doesn't mismatch the a11y tree
TabAtkins: but you can currently use tabindex
emilio: Right, you can already mismatch
annevk: maybe don't need to match tree, but [missed]
TabAtkins: if you use A and tabindex on A and 2 children inside the A, and on something else
TabAtkins: your order can flip back and forth
TabAtkins: if you display:contents the A, don't know where to put it
TabAtkins: but if we define "it goes just before its first visual child" then we're back to where we were before display:contents
TabAtkins: with this answer to where we put it, i.e. right efore first visual child, we don't need to do scope owner
emilio: right, and we have precedent for that
Di: do we need scope owner for <slot> then still?
emilio: My understanding was to avoid conflicting with a11y tree, but can already diverge with tabindex so maybe we can make Eric happy
mfreed: an exmaple without tabindex, you have a mismatch
emilio: is that a problem?
…
TabAtkins: tabindex is a bad *design*, but I'm not sure if it's actually a bad thing *for a11y* here
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?
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?
emilio: Yes. If we get feedback that it's bad, we have consensus on scope owner + first visual item.
fantasai: So we can resolve on first visual, and figur e out scope later
<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
fantasai: proposed resolution: display:contents focusable element occurs in the order immediately before its child that's first in visual order
dbaron: and when tabbing in reverse, it's still preceding it in the original order, so reverse-tabbing it's after
<ntim> emilio: needs tweaking for nested display: contents
<masonf> +1
RESOLUTION: display:contents focusable element occurs immediately before its first child in visual order
<ntim> 🎉 🎉
<ntim> 🍾
<dbaron> (and probably an empty display contents goes at the end?)
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
proposed resolution not passed, we'll discuss in an issue
CSS Speech
janina1: Background: for several years we have been considering the challenge of having TTS on various platforms
… to pronounce words in a similar way
CSS Speech
janina1: We have a path to a solution
… We propose two solutions split along a fairly traditional or classic divide
… We propose CSS speech, in a preliminary version 1.0
… to divide out presentational aspects such as volume, from pronunciational aspects (such as the long i or short i vowel in wind)
… Justification is the difficulties introduced by mispronunciations are huge and many, e.g., picture a blind person taking an LSAT by means of a screen reader
matatk: We have specific use cases from education where people require fine-grained control of pronunciation
<matatk> For reference: Pronunciation Gap Analysis and Use Cases: https://
matatk: other use cases where the content provider wishes to determine the pace, quality of voice
… We acknowledge that the idea of CSS Speech has been around for a while, we wanted to share these needs and find common ground
<PaulG> https://