21:00:35 RRSAgent has joined #css 21:00:39 logging to https://www.w3.org/2024/09/23-css-irc 21:00:39 RRSAgent, make logs Public 21:00:40 Meeting: Cascading Style Sheets (CSS) Working Group Teleconference 21:00:43 present+ 21:00:45 Present+ 21:00:50 present+ 21:00:51 present+ 21:00:57 tantek has joined #css 21:01:02 https://github.com/whatwg/meta/issues/326 21:01:03 present+ 21:01:07 noamr has joined #css 21:01:16 agenda? 21:01:27 Agenda here: https://github.com/whatwg/meta/issues/326 21:01:46 agenda: https://github.com/whatwg/meta/issues/326 21:01:57 ethanjv has joined #css 21:01:58 past has joined #css 21:02:22 kizu has joined #css 21:02:49 jfkthame__ has joined #css 21:03:10 astearns has changed the topic to: joint WHATWG/CSS agenda: https://github.com/whatwg/meta/issues/326 21:04:34 tantek has changed the topic to: CSSWG + WHATWG joint meeting: https://github.com/whatwg/meta/issues/326 “Topics for the joint session with the CSSWG” 21:04:53 ScribeNick: TabAtkins 21:04:53 present+ 21:04:57 present+ 21:05:04 present+ 21:05:20 lea has joined #css 21:05:28 khush has joined #css 21:05:32 present+ 21:05:32 present+ 21:05:33 Di has joined #css 21:05:37 jensimmons has joined #css 21:05:37 present+ 21:05:41 present+ 21:05:47 present+ 21:05:47 florian_irc has joined #css 21:05:50 andreubotella has joined #css 21:05:51 ydaniv has joined #css 21:05:52 present+ 21:05:52 past: First topic adding a new member to the "blocking" set 21:05:53 present+ 21:05:55 annevk has joined #css 21:05:56 present+ 21:06:17 github-bot, topic https://github.com/whatwg/html/issues/10513 21:06:17 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. 21:06:17 present+ 21:06:19 bkardell_ has joined #css 21:06:25 Topic: New "blocking" value for VTs 21:06:32 moonira has joined #css 21:06:36 present+ 21:06:47 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 21:06:51 present+ 21:06:56 present+ 21:07:03 present+ 21:07:04 noamr: We added a while back a "blocking" attribute to control this better, so it's not just stylesheets. 21:07:04 present+ 21:07:13 noamr: When the page is unblocked from rendering, the VT starts 21:07:24 kbabbitt has joined #css 21:07:30 present+ 21:07:34 noamr: The main disconnection is that render blocking isn't just for VT, it's also for preventing a flash of unstyled content 21:07:51 noamr: So people can avoid doing tricks with hiding content and revealing withi script after it's rendered 21:08:08 noamr: There are situations where VT render blocking and document render blocking have reasons to be slightly different 21:08:10 noamr: one is timeout 21:08:16 s/withi/with 21:08:23 noamr: If what you're preventing is af lash of unstyled content, we can't reason about the correct timeout 21:08:34 noamr: say we ahve a render-blocked page, and we wanted to unblock it automatically after 5s 21:08:44 kschmi has joined #css 21:08:46 noamr: What'll happen is a flash of unstyled content until the stylesheet loads 21:08:57 noamr: did we improve the user experience? will people just go back to loading the css via js? 21:08:59 atrigent__ has joined #css 21:09:05 oriol has joined #css 21:09:07 noamr: in VT this is different, they're just a progressive enhancement 21:09:33 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 21:09:43 noamr: The initial proposal we discussed is, this works with blocking=render 21:09:53 noamr: But blocking can accept mroe values, potentially 21:10:00 noamr: we can say a possible value is blocking=view-transition 21:10:07 present+ 21:10:12 noamr: that could have a different timeout, and wouldn't block if there wasn't a VT 21:10:26 noamr: would just give the browser a little time to prep the VT, rather than blocking for unstyled content 21:10:32 (seems good to me) 21:10:38 q+ 21:11:00 emilio: what are the specifics here? what do you mean by "it won't block when there's no VT" 21:11:09 emilio: When there's no incoming? or when there's none starting on the new page? 21:11:13 noamr: The former, incoming VT. 21:11:29 noamr: If there's no incoming VT, with blocking=view-transition we wouldn't block, there's no reason to 21:11:44 emilio: okay I think that's better than blocking for all VTs, yeah 21:12:04 zcorpan: what's the current timeout for render=blocking? 21:12:13 noamr: in the spec it's U 21:12:16 noamr: UA-defined 21:12:40 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 21:12:55 noamr: If there's a network request for a render-blocking resource *taht* can timeout eventually and unblock 21:13:17 fserb has joined #css 21:13:41 q? 21:13:48 ack emilio 21:14:02 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? 21:14:16 annevk: If they're already doing it wrong, i wonder if they have enough knowledge of which to apply to do it well 21:14:30 ntim has joined #css 21:14:35 present+ 21:14:46 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 21:15:17 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 21:15:20 annevk: sounds reasonable 21:15:24 noamr: I asked Matt Woodrow about this issue and here was his reply: 21:15:24 21:15:24 > 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". 21:15:25 It's not super obvious that that's a common thing to want? 21:15:37 annevk: just hope that next year we dont' have another case 21:15:53 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 21:16:07 q? 21:16:07 q+ 21:16:32 zcorpan: i thought document render blocking was mainly added for the VT use-case 21:16:48 zcorpan: if we want different behavior, what are the other use-cases we want to preserve the current behavior for? 21:17:02 noamr: there are people who use render blocking to avoid usntyled content 21:17:21 noamr: some people that were using popular libraries for JS-based render blocking - display:none and removing it in script 21:17:26 zcorpan: that's subresource render blocking 21:17:28 noamr: not only 21:17:38 noamr: there were people who didn't want gradually-rendered content to appar 21:17:50 zcorpan: okay, that's fine 21:18:08 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 21:18:23 noamr: 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. 21:18:23 Hard to reason about all the different timeouts 21:18:43 ntim: I left some feedback from Matt Woodrow in IRC 21:19:19 ntim: [narrates previous comments] 21:19:23 s/noamr: I asked/I asked/ 21:19:37 s/noamr: Also/Also/ 21:19:50 noamr: I think the impl-defined timeout is a godo question 21:20:02 noamr: for regular render blocking we might not have one at all, or maybe a very long 21:20:24 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 21:21:02 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. 21:21:33 past: Are you unblocked to move forward? 21:21:38 noamr: Yes, I think so. 21:21:55 Topic: reading-flow 21:22:11 past: there's a bunch of links 21:23:16 Di: from the agenda for this meeting, many issues are related to each other 21:23:20 github-bot, take up https://github.com/w3c/csswg-drafts/issues/9230 21:23:20 Topic: [css-display-4] Define how reading-flow interacts with focusable display: contents elements. 21:23:20 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/9230. 21:23:25 Di: so i'm gonna focus on the proposal of how to implement css reading-flow 21:23:31 Di: I'm the Blink engineer working on this new property 21:23:41 Di: quick summary, the reading-flow property is in Display 4 draft 21:23:55 Di: This redefines the navigation order when the user presses Tab, and similar for a11y tree 21:24:03 Di: currently only works on display:grid and flex elements 21:24:16 Di: but with other proposals that touch on display orderring, like Masonry, it'll get bigger 21:24:34 Di: This is valuable because it helps authors choose the right reading order for their users, when it doesn't match the dom order 21:24:42 https://rachelandrew.github.io/reading-order-items-examples/ 21:24:46 Di: rachel has a video showing how unintuitive the current dom-based order can be and how this property can fix 21:25:06 Di: I want to talk about the impl of the feature, and some of the edge cases, like display:content or abspos/fixpos 21:25:21 Di: the goal here is to get more feedback on the HTML PR 21:25:22 siye has joined #css 21:25:22 https://github.com/whatwg/html/pull/10613 21:25:36 Di: any questions to start? otherwise i'll go into details 21:25:40 q? 21:25:52 ack zcorpan 21:26:12 Di: the current impl defines reading-flow relative ot eh "reading flow scope owner" 21:26:24 dholbert has joined #css 21:26:25 Di: it's either a container with a 'reading-flow' value, or a display:contents whose parent is a reading-flow container 21:26:27 s/ot eh/to the/ 21:26:29 present+ 21:26:42 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 21:26:46 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 21:26:54 Di: Like it could be grid-rows or grid-columns 21:27:06 Di: some items are not sorted by the layout, like elements that are abspos 21:27:19 Di: in that case, they're visited after the ones that are sorted, in normal dom tree order 21:28:00 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? 21:28:06 Di: tabindex takes priority over reading flow 21:28:36 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 21:28:43 q+ 21:28:46 q+ 21:29:15 ack kizu 21:29:54 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? 21:30:07 Di: no mixing, within a scope you visit all the elements first 21:30:32 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 21:32:08 TabAtkins: I think there's some confusion, you always visit all the focusable elements in a given element anyway. 21:33:11 some discussion of scopes, tab index and other things not minutes 21:33:28 [will fill in later] 21:33:45 zcorpan: question on the general need for this property 21:33:53 ack zcorpan 21:33:55 zcorpan: the preivous sense of the csswg is people should use the dom order for correct reaading order 21:34:16 zcorpan: what changed? do we have more layout mechanism now, different layouts on different devices, etc? just inconvenient to reorder the dom 21:34:27 rachelandrew: we've got tons of dev feedback on the preivous issues 21:34:32 rachelandrew: loads of usecases where devs ask for this 21:34:52 rachelandrew: simple is you have a layout with grid where the ideal layout in mobile vs layout presents things in a differnet visual order 21:35:07 rachelandrew: we give people the ability to rearrang ethings with grid, then basically say don't do it because it causes this problem 21:35:21 rachelandrew: I'll link in threads later 21:35:33 +1 to rachelandrew, this is a very common pain point 21:35:33 rachelandrew: But pretty mcuh every workshop i've done someone has said "i want to do this, but you said I can't" 21:35:57 resolution to work on this: https://github.com/w3c/csswg-drafts/issues/7387#issuecomment-1690281298 21:36:23 Di: So the author issues is talking more about display:contents, it's all related tho for focus scope navigation 21:36:26 q+ 21:36:37 annevk: wonder why you decided tab index should win in the end? 21:37:12 TabAtkins: is that asked with the understanding about focus groups, which scope the tabindex behavior? 21:37:31 annevk: there's a scoping aspect, but there's also an element-by-element feature 21:37:52 annevk: we invented the css feature to win out, but then HTML wins 21:37:55 lots of cases in this issue https://github.com/w3c/csswg-drafts/issues/7387 21:38:09 masonf: our general feeling is using this feature in conjunction with tabindex would be a mistake, but we still have to define what happens 21:38:26 annevk: one thing you could imagine is tabindex just delegates to the css feature 21:38:32 also dense packing causes reordering, and the author can't control it, as will masonry. 21:38:33 annevk: then you could use CSS to further override it 21:38:46 annevk: so if you reorder the visual vs Dom, you can use CSS to fix that 21:39:19 annevk: it makes sense to me that CSS would win, so we could explain the HTML in terms of that 21:39:55 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. 21:40:21 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. 21:40:53 q+ 21:40:54 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. 21:41:07 removing the index resolution and discussion: https://github.com/w3c/csswg-drafts/issues/8589#issuecomment-1721504153 21:41:12 annevk: I thought the CSS feature has a scoping mechanism, and the ability to say focus next 21:41:38 tabatkins: you can choose a few options, but not arbitrarily. 21:42:04 tabatkins: several examples where that happens. 21:42:09 q? 21:42:24 annevk: I don't have an answer as to why tabindex shouldn't just be ignored 21:43:06 annevk: Once you start using this, shouldn't we just ignore tabindex? 21:43:25 TabAtkins: We just needed to give an answer to how they work together. If you feel strongly otherwise, we can have an issue 21:43:39 annevk: Yeah, makes the most sense to me to have it be ignored 21:43:56 domfarolino: what do you think is better - making tabindex secondary, or ignoring completely? 21:44:09 annevk: I think ignoring completely, based on what I've heard. 21:44:26 q+ 21:44:26 annevk: probably woudln't want things moving around based on tabindex 21:44:35 q? 21:45:08 ack fantasai 21:45:09 fantasai, you wanted to react to zcorpan 21:45:12 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 21:45:35 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 21:45:42 fantasai: I'm guessing that's the logic behind the current behavior 21:46:00 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 21:46:24 fantasai: for example, a right-hand sidebar, versus an item around that sidebar, might want the sidebar read first 21:46:36 fantasai: so we have some mixed cases. I think tabindex is somewhat addressing that 21:46:50 s/an item/a collection of auto-positioned items/ 21:46:53 q+ 21:47:04 ack bkardell_ 21:47:30 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? 21:47:38 wow bkardell_ brings up nav-index 21:47:38 annevk: It was a thought, yes. Not a complete proposal. 21:47:57 annevk: but Tab made a convincing point that tabindex is a bad API, not sure we should just copy it 21:47:58 pretty sure we implemented nav-index in Tasman back in the day 21:48:11 bkardell_: I liked your idea about ignoring it, would you ignore all of it? 21:48:31 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. 21:48:31 q? 21:48:44 annevk: But the mix of the two doesn't make a lot of sense to me right now. 21:48:55 +1 , agree with what annevk just said 21:49:29 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 21:49:47 q? 21:49:48 domfarolino: so then you'd have to stop using tabindex entirely if you wanted to use reading-flow 21:49:52 +1 to ignoring tabindex inside a reading-flow scope 21:49:56 annevk: Yeah, seems reasonable 21:50:30 zcorpan: Wanted to ask about the a11y mapping 21:50:39 ack zcorpan 21:50:44 Di: we have asked for feedback 21:50:55 Di: the reading-flow items that are sorted, we use that to present the items in the a11y tree 21:51:11 Di: normally the a11y tree follows by Dom order, so the unsorted items we keep in dom order 21:51:12 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 21:51:35 zcorpan: So the plan is to spec that the a11y tree is reordered, good 21:51:51 ack fantasai 21:52:03 q- 21:52:19 dbaron: about the tabindex thing 21:52:46 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 21:53:01 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 21:53:12 dbaron: but not really changing the whole tree traversal, just the visitation order of those siblings 21:53:42 (and their concepts) 21:53:50 s/cepts/tents/ 21:53:55 (was also going to say subgrid might be an exception) 21:53:56 dbaron: maybe subgrid has an exception 21:54:07 miketaylr has joined #css 21:54:13 dbaron: maybe that impinges on your point about tabindex working, this changes just the visitation order of the siblings 21:54:20 ethanjv has joined #css 21:54:24 q? 21:54:29 ack dbaron 21:54:34 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 21:54:44 annevk: so does the scoping happen at the parent level, or for each sibling? 21:54:49 masonf: the parent 21:55:21 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 21:55:37 masonf: I see your point there, we might need more thought 21:55:39 TabAtkins: agreed 21:55:42 Penny has joined #css 21:56:09 I propose we ignore tabindex ordering *on the reordered children*, and then scope the childrne's subtrees 21:56:24 domfarolino: If we don't honor tabindex for the siblings, would we honor it inside the subtree? 21:56:39 annevk: I guess so, it makes sense with what David was saying 21:57:09 Di: So are there any questions about making display:contents a focus scope owner 21:57:49 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? 21:57:53 masonf: two current proposals 21:58:02 masonf: one is put all the display:contents children last 21:58:31 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 21:58:44 rachelandrew: We asked devs if anyone is doing this, and couldn't find an example yet 21:58:51 discussion and resolution about reading order and display:contents interaction: https://github.com/w3c/csswg-drafts/issues/9230#issuecomment-2261469723 21:58:57 rachelandrew: I think it's an unusual case to solve, not something we're seeing everywhere 21:59:14 masonf: we also prefer option 2, because eit's better for a11y and easier to implement 21:59:50 tabatkins: because display:contents, they don't have a layout, but it's also safe to hold the layout, that makes sense. 22:00:34 https://developer.chrome.com/blog/reading-flow-display-contents the request for feedback I've been sharing, which explains the issue 22:00:45 s/hold the layout/pull the layout from the parent, and apply it to the children/ 22:00:59 Making flex items is not terribly uncommon fwiw 22:01:09 Making flex items display: contents* 22:01:19 TabAtkins: As if the display:contents element become a display:flex (or whatever) holding its children 22:01:35 panos: Di, are you unblocked? 22:01:46 Di: Yes. We ask for everyone to look at the HTML spec PR 22:01:47 I use it to conditionally hide a set of flex items sometimes 22:01:50 q+ 22:01:56 masonf: Everything should be in the Html PR, modulo the new tabindex question 22:02:13 annevk: So the display:contents thing is being resolved in this new property? Or only comes up in the context of this property? 22:02:18 masonf: Only comes up in this context. 22:02:37 annevk: Okay, it does sound like of your two options, putting the display:contents at the end was weird 22:02:51 Di: And is display:contents, which is why we spend so much time thinking about this 22:03:01 ack emilio 22:03:04 emilio: This is only an issue if the display:contents is focusable, yeah? 22:03:27 masonf: current proposal is display:contents children of these containers *always* makes them into reading order containers 22:03:50 emilio: Okay, and that prevents reordering across siblings 22:04:10 emilio: So for the purpose of focus, this sis only an issue if the display:contents element was focusable as well 22:04:21 masonf: Yes, the traversal algo would be a little more complicated, but that's it 22:04:31 example of what i use `display: contents` flex children for: https://jsfiddle.net/dk1Lryhj/ 22:04:36 s/this sis/this is/ 22:04:46 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 22:04:50 gsnedders has joined #css 22:04:58 masonf: I think yes, except the a11y tree becomes harder in that case. 22:05:06 masonf: And I think the tab order should match the a11y order 22:05:54 TabAtkins: Okay, so display:contents scopes the ordering, even if their items are visually interwoven 22:06:10 emilio: that seems a little confusing to me as an author, you're saying use the visual order, but you don't get that 22:06:24 masonf: Yeah, all the possible solutions aren't obvious 22:06:45 emilio: display:contents that's focusable is indeed rare, but display:contents that isn't focusable seems a lot more common. 22:07:06 emilio: that's the main use-case of display:contents, to let the parent take up the children 22:07:15 masonf: If focus order was all we had to deal with, I'd agree 22:07:24 emilio: Yeah, I understand the a11y tree makes it hard. 22:07:42 rachelandrew: It seems that people are generally using display:contents in mostly simplistic ways at the moment 22:07:55 rachelandrew: whenever I ask for example they're just removing a wrapper from an element 22:08:37 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... 22:08:57 masonf: slots are *already* focus scoped, actually, so that "breaks" today already 22:09:09 emilio: Hm, the way I'd want to use this feature might override that behavior... 22:09:14 florian_irc has joined #css 22:09:22 masonf: Yeah, we're proposing to make display:contents act like how slots work today 22:09:49 florian_irc has joined #css 22:10:19 [discussion of the grid use-case] 22:11:02 rachelandrew: We have tried to design some friction into this property anyway, so people don't just apply it willy-nilly. 22:11:07 fserb has joined #css 22:11:28 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. 22:12:08 q? 22:12:36 emilio: So I think there are some realistic use-cases that would break under this behavior. 22:12:43 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 22:12:50 emilio: two non-slots, forget the slot behavior 22:13:07 emilio: both display:contents, and use 'order' to put some elements of each at the top, you'd still get the weird order 22:13:51 masonf: It doesn't work in that it gives the wrong order, but at least it is focusable 22:14:58 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 22:15:51 TabAtkins: Rachel has a lot of examples of *simple* display:contents use, just not complex ones that would run into this discussed issue 22:16:00 dbaron: I think there was a big discussion of whether display:contents should be in the a11y tree. 22:16:21 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 22:17:11 lea: If authors need slots to be focusable, they'd also override display:contents, right? 22:17:25 annevk: I'm still confused that display:contents isn't more like display:none 22:17:42 TabAtkins: If you display:contents an , the contents are still clickable. They need to be focusable too 22:17:52 annevk: Becuase links are done via Dom structure... 22:18:09 [more discussion about links being display:contents] 22:18:26 florian_irc has joined #css 22:18:46 masonf: So this has been a good discussion. Dont' think anyone's come up with a better idea so far, but if anyone does... 22:18:59 annevk: Probably just doing what slots do today is fine, and if we need further overrides we can develop that. 22:19:13 annevk: Even if it comes up in practice for one person, we should probably wait a few... 22:19:28 lea: What if you call El.focus() on a display:contents element? 22:19:39 emilio: Under dbaron's proposed behavior, it does get focused. 22:19:51 i feel like the discussion is getting off topic from the original issue 22:19:59 emilio: today it's not focusable 22:20:04 dbaron: But we want to change it 22:20:59 [point of order, no more breakouts within the room] 22:21:40 scribe+ 22:21:45 TabAtkins: Sounds like conclusion is that [missed] 22:21:53 TabAtkins: although someone uncomfortable, nobody has a beter idea 22:22:01 ethanjv has joined #css 22:22:05 s/[missed]/thing currently marked option 2 in PR/ 22:22:30 TabAtkins: making `display: contents` work the same way as s do today 22:23:05 Di: So option 2 is make display:contents its own focus-scope owner, similar to 22:23:29 Di: What Dom is mentioning about putting display:contents last is a different part of the proposal 22:23:47 Di: And that other part is "everything not part of the layout just goes at the end, after all the visually-sorted options" 22:24:23 fantasai: So if I have a grid with a display:contents child, and *its* children are reordered by the parent grid, what happens 22:25:19 fantasai: so we have a flex with children A, B, C. B is display:contents with B1 and B2 children 22:25:49 fantasai: visual order is A B1 C B2 22:26:27 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 22:26:41 fantasai: okay new order A B1 B2 C 22:26:48 fantasai: But I've set reading-flow on this element 22:26:58 fantasai: As an author I'd expect reading-flow to not change the order of things 22:26:59 florian_irc has joined #css 22:27:06 gsnedders has joined #css 22:27:10 annevk: I'm also confused about thtis 22:27:17 masonf: two issues, one is whether display:contents forms a scope 22:27:26 annevk: Yeah, assume we do that to align with slot 22:27:37 masonf: Then we have a choice where to put the display:contents children 22:27:59 emilio: Put them where in the visual order the first sub-item shows up? 22:28:14 emilio: I think fantasai was hinting at this 22:28:15 florian__ has joined #css 22:28:33 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" 22:28:47 emilio: so at that point you'd walk the display:contents subtree and do them in visual order 22:28:51 dbaron: so two options I think I heard 22:29:00 dbaron: one is when you hit the first Dom child of the display:contents 22:29:14 dbaron: another is when you hit the first *visual order* child of the display:contents 22:29:23 fantasai: the second one 22:29:37 emilio: I also think second, it allows more intuitive behavior when you reorder inside the display:contents 22:29:57 fantasai: I think it's important to make sure A B1 B2 C order stays as it is, you haven't moved *anything* 22:30:03 karlcow has joined #css 22:30:10 fantasai: Also would be good to have A B2 B1 C (with 'order') to work visually 22:30:18 fantasai: These are the most common by far cases of using display:contents 22:30:41 fantasai: the full re-ordering examples are much rarer 22:30:51 annevk: What if the visual order is C B2 B1 A, reversed? 22:31:08 fantasai: Yes, should still work visually. As long as the items are in contiguous visual order, it should still work 22:31:34 emilio: Say you flip the order in a display:contents. question is what tab order would you expect 22:31:41 emilio: I think ideal is what elika said, actually reorder them 22:31:49 emilio: I dunno how that interacts with the scope owner thing 22:32:07