- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Fri, 15 Sep 2023 13:29:38 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed ``[css-shadow-parts] Make `::slotted()` a combinator``.
<details><summary>The full IRC log of that discussion</summary>
<ntim> leaverou: making ::slotted a pseudo created a couple of issues<br>
<ntim> leaverou: I linked to a couple of them<br>
<astearns> [lists issues]<br>
<ntim> leaverou: we already discussed of making it a pseudo class<br>
<ntim> leaverou: it seems possible to make it a combinator<br>
<fantasai> scribenick: fantasai<br>
<fantasai> lea: which would address all of these issues<br>
<fantasai> lea: proposed syntax for a named combinator /slotted/<br>
<fantasai> lea: which follows a plan we had for named combinators so they're not all weird ascii<br>
<emilio> q?<br>
<astearns> ack emilio<br>
<Zakim> emilio, you wanted to say that reduced-motion has various side effects in Firefox<br>
<fantasai> lea: ::part() has similar issues, but more complicated, so figure out later<br>
<fantasai> lea: question is can we spec this combinator without giving too much access, without leaking info about shadows to the outside<br>
<fantasai> lea: There are lots of reactions in the issue (31 thumbs up 17 hearts) so at least positive reaction from some people<br>
<emilio> q+<br>
<futhark> q+<br>
<astearns> zakim, open queue<br>
<Zakim> ok, astearns, the speaker queue is open<br>
<fantasai> [note for the audience, very few CSSWG issue have that many reactions]<br>
<astearns> q+ futhark<br>
<fantasai> emilio: This potentially makes it possible to style things that are not slotted from inside the shadow tree, right?<br>
<fantasai> emilio: if you have /slotted/ + something else<br>
<fantasai> lea: we'll need to provide some kind of limitation<br>
<westbrook> q+<br>
<fantasai> emilio: how would that work?<br>
<fantasai> lea: that's the question<br>
<bkardell_> q+<br>
<fantasai> lea: we need limitation on grammar of what comes after slotted combinator<br>
<fantasai> emilio: seems hard to do<br>
<fantasai> lea: we could start by allowing the same grammar as argument of ::slotted() and expand from there<br>
<fantasai> lea: I disagree with "small benefit", it does seem to solve a buch of issues<br>
<fantasai> emilio: wrt targetting siblings<br>
<fantasai> emilio: [didn't hear]<br>
<fantasai> lea: right<br>
<astearns> s/[didn’t hear]/is the thing we cannot do<br>
<fantasai> lea: the issue is asking to style siblings that are also slotted<br>
<fantasai> emilio: we don't have a great way of distinguishing slotted vs unslotted<br>
<fantasai> westbrook: if a sibling isn't slotted, it isn't visible.<br>
<fantasai> emilio: could be in a different slot<br>
<fantasai> westbrook: if these are slotted, incredibly low specificity<br>
<lea> q?<br>
<lea> q+<br>
<fantasai> westbrook: majority of custom element devs would expect, to have control over that at low specificity<br>
<fantasai> westbrook: customer could override using standard mechanics of light DOM<br>
<fantasai> emilio: would that change nature of sibling combinator after slotted combinator in a way that ignores slotted things? Otherwie no way to make it work<br>
<fantasai> emilio: not in the DOM tree, not slotted<br>
<fantasai> lea: a few questions here<br>
<fantasai> lea: 1. can we define something like this, is it implementable<br>
<fantasai> lea: 2. what kind of restrictions do we need to prevent breaking encapsulation<br>
<fantasai> lea: I think we should resolve on these separately<br>
<fantasai> emilio: if you have combinator that does same thing as pseudo, then why not not have a combinator?<br>
<bkardell_> s/ do we need to prevent breaking encapsulation/ do we need to prevent breaking encapsulation (that's a whole other set of discussions)<br>
<fantasai> emilio: seems hard to imagine non-problematic expansions of pseudo<br>
<fantasai> lea: some obvious expansions that clearly don't break<br>
<fantasai> lea: e.g. pseudo-classes or pseudo-elements that depend on that selector<br>
<fantasai> lea: and room for expansions not posisble inside pseudo-element<br>
<fantasai> emilio: expansions are allowed, see ::part()<br>
<fantasai> lea: it would solve query selector out of the box<br>
<fantasai> lea: also targetting descendants and pseudo-elements<br>
<fantasai> lea: only question is targetting siblings<br>
<astearns> ack fantasai<br>
<Zakim> fantasai, you wanted to ask about order of slotting or order in light dom<br>
<astearns> ack futhark<br>
<lea> q-<br>
<fantasai> futhark: This is same as content shadow DOM [missed]<br>
<emilio> q+<br>
<fantasai> futhark: thinking about limitations, if you add :is() and :where(), you can walk up ancestry of slotted element which is almost like :host-context() which has been turned down before<br>
<fantasai> futhark: I would also like to point out that we support pseudo-elements on ::slotted() today, can expand the list<br>
<astearns> ack westbrook<br>
<emilio> q-<br>
<fantasai> westbrook: Westbrook, Adobe, Web Components CG<br>
<futhark> It's probably implementable in Blink since this is basically the same as ::content from Shadow DOM v0<br>
<fantasai> westbrook: It's likely that many of us in the CG that were enthusastic in the issue, because as Web Component devs we're very excited about the possibilities of /slotted/ combinator<br>
<fantasai> westbrook: both for reasons listed in the issue, but also for being able to leverage :has() to style based on what has been slotted<br>
<fantasai> westbrook: this currently requires JS, and JS has to be context-dependent<br>
<fantasai> westbrook: so this would simplify JS and open up capabilities we've not had in the past<br>
<astearns> ack bkardell_<br>
<fantasai> bkardell_: Complicated feelings about this proposal<br>
<fantasai> bkardell_: on the one hand, find both ::slotted() to be awkward<br>
<fantasai> bkardell_: and not powerful enough<br>
<fantasai> bkardell_: but also know why we have them, and what emilio says probably true<br>
<westbrook> Examples of JS for Slot Content Detection: https://github.com/w3c/webcomponents-cg/discussions/72<br>
<fantasai> bkardell_: around 2012-ish, we had 2 combinators proposed to cross the shadow boundaries<br>
<fantasai> bkardell_: and we did that, and it was implemented in Chrome, and then it was removed<br>
<astearns> (like /deep/)<br>
<fantasai> bkardell_: I thought that was a hasty decision, and I really do support revisiting combinators that help wiht these cases<br>
<fantasai> bkardell_: people are building in userspace querySelector that can cross shadow boundaries, because sometimes you want that<br>
<fantasai> bkardell_: so totally support revisiting with good use cases<br>
<fantasai> bkardell_: also make sure we don't create something bad<br>
<rniwa> q+<br>
<fantasai> bkardell_: but currently I don't think it's bad, do more in this proposal to get there<br>
<astearns> ack fantasai<br>
<TabAtkins> Scribe+<br>
<TabAtkins> fantasai: first question, when you say you want to target siblings, do you mean in the slotted subtree?<br>
<lea> q?<br>
<TabAtkins> fantasai: If so, sibling relationships as slotted, or as originally in the light dom?<br>
<TabAtkins> (I think the answer is as slotted)<br>
<fantasai> lea: Definitely siblings within the subtree of slotted should be accessible, one of the main use cases<br>
<TabAtkins> fantasai: I mean like if you slot all the even children, are you seeing siblings as they're slotted, or as they were in the original light dom<br>
<fantasai> lea: Only looking at slotted elements would break encapsulation less, but might be harder to implement<br>
<emilio> westbrook: it seems that use case could be solved by a `slot` pseudo-class or so?<br>
<fantasai> lea: but this is going in the weeds<br>
<fantasai> lea: more important to see if consensus to pursue this if we can find restrictions<br>
<astearns> q+<br>
<TabAtkins> Basing on the slot relationships is what the use-cases want - letting you select *as if* the slotted elements were always in the position they ended up being slotted into.<br>
<TabAtkins> fantasai: Details can matter. This suggest that you're not necessarily using a combinator, but rather looking thru a pseudo-element into a new structure.<br>
<fantasai> lea: Not necessarily needed, not a major use case<br>
<fantasai> lea: they need pseudo-classes, descendants, access to subtree of the slotted element itself<br>
<fantasai> lea: but if we could restrict to access only the element itself and its subtree<br>
<westbrook> emilio: there are definitely other paths to solving that situation, why we called it "Slot Content Detection" rather than any specific API or syntax.<br>
<emilio> q+<br>
<fantasai> lea: that would still solve a lot of the problems today<br>
<fantasai> s/emilio:/emilio,/<br>
<astearns> ack rniwa<br>
<fantasai> rniwa: As implementer, I think short answer is no, we don't want to make this supported as a combinator<br>
<fantasai> rniwa: because it poses significant implementation complexity<br>
<fantasai> rniwa: I question the proposition that these are actual use cases that need solving<br>
<fantasai> rniwa: it's often the case that when someone wants to style slotted content based on their descendants or siblings, it's often a mistake made in the DOM structure itself<br>
<westbrook> q+<br>
<fantasai> rniwa: at least in the cases I've seen, you need a different DOM structure, not a combinator<br>
<lea> q?<br>
<fantasai> astearns: Challenge that assertion<br>
<fantasai> astearns: I think there are valid use cases that are not achievable, this is why ppl are writing JS to do it<br>
<fantasai> astearns: and it's a lot easier to restructure DOM in your component than to write JS to achieve the right effect<br>
<fantasai> astearns: but we are talking about a combinator that's different from other combinators, and will require safety restrictions<br>
<fantasai> astearns: we have three implementers saying "I don't want to do this"<br>
<fantasai> astearns: Pseudo-element doesn't do everything we want it to do<br>
<lea> q+ another use case that came up that is addressed by this is that pepple are asking for a :has-slotted pseudo-class that applies to slots — with this, this would simply become `:has(/slotted/ *)` (can't find it now but astearns has a link to it)<br>
<fantasai> astearns: what if we make pseudo-elements do things other pseudos don't do? And enable some of these effects?<br>
<astearns> ack astearns<br>
<bkardell_> s/pepple/people<br>
<lea> q?<br>
<lea> q+<br>
<fantasai> emilio: asking a slot whether it has content seems useful<br>
<fantasai> emilio: but combinator...<br>
<fantasai> emilio: pseudo-class of a slot that says whether it's got content is a lot more straightforward<br>
<fantasai> emilio: and that's trivially implementable<br>
<fantasai> emilio: some use cases, like querySelector, that's a no-go to me<br>
<astearns> ack emilio<br>
<fantasai> emilio: same reason why ?? in shadow trees<br>
<fantasai> emilio: the compelling use case I see here is whether or not slot has content, and that's much simpler to fix<br>
<astearns> ack westbrook<br>
<fantasai> westbrook: To respond to two things<br>
<emilio> s/??/document.querySelector doesn't return stuff stuff inside shadow trees<br>
<fantasai> westbrook: rniwa says maybe DOM structure should change<br>
<fantasai> westbrook: but HTML parser requires certain DOM structures<br>
<fantasai> westbrook: if user wants UL in its content, and want to manage the LIs, we can't just change the DOM structure<br>
<fantasai> westbrook: the second use case Lea mentioned is most important<br>
<rniwa> q+<br>
<fantasai> westbrook: whether UL, or TABLE, or any places where DOM structures can't be change<br>
<fantasai> westbrook: these are where we most need ability to reach into the child of the element<br>
<fantasai> westbrook: wrt emilio's point about knowing slotted content or not is easier, yes of course<br>
<keithamus> q?<br>
<fantasai> westbrook: that's a second situation, not the same as the issues listed here (just you can use what lea proposes to do the same thing)<br>
<fantasai> westbrook: but we don't think that's the center of what she's proposing<br>
<fantasai> lea: I agree, we could add combinators and pseudo-classes and allow to be querySelector and maybe add some ad-hoc specificity rules to fix that problem<br>
<fantasai> lea: but as we start to add these, we're just re-inventing combinators<br>
<fantasai> lea: might be useful if implementors could elaborate what makes the combinator hard to implement<br>
<emilio> q+<br>
<fantasai> lea: so we can understand what we need to restrict<br>
<astearns> ack lea<br>
<fantasai> emilio: scenario where WebKit and Gecko differe from Blink<br>
<fantasai> emilio: we store our data for shadow trees in the shadow root<br>
<fantasai> emilio: there's a perf benefit to that<br>
<fantasai> emilio: you don't add rules from inside the shadow tree<br>
<bkardell_> to emilio's point about queryselector not crossing shadow root: by default, yes, that's the whole idea of it. That doesn't mean there shouldn't be an explcit way to do it that isn't "re-write queryselector in user space, but to cross boundaries". Any way.<br>
<fantasai> emilio: wrt implementation complexity, things outside the shadow tree that are super far related from tehs shadow tree cannot affect styles inside it<br>
<keithamus> q+<br>
<fantasai> emilio: and can't match rules inside it<br>
<fantasai> emilio: let's say you have combinator and descendant selector<br>
<fantasai> emilio: inside shadow root you have stylsheet with .myslot /slotted/ div, can reach deep inside the slotted subtree<br>
<fantasai> emilio: now any time anything changes in that element, we need to go find the shadow tree where that may have been<br>
<fantasai> emilio: in order to invalidate style<br>
<bramus> q+<br>
<fantasai> lea: doesn't this already apply to ::slotted()?<br>
<fantasai> emilio: yes, but only askes about the slotted element itself<br>
<fantasai> emilio: wherease if you do it on any random element, then ...<br>
<fantasai> emilio: And now I'm sad, you need to do a whole tree-walk to find where the rule came from<br>
<fantasai> lea: would restricting the combinators allowed after /slotted/ help?<br>
<fantasai> emilio: but then you can select slotted content<br>
<fantasai> lea: basically same as nesting, first we resolve on limited syntax<br>
<fantasai> lea: and then eventually opened up to syntax we actually wanted<br>
<fantasai> lea: so even if almost as restricted as pseudo-element, can expand<br>
<fantasai> lea: if we add that, then we have a hybrid between pseudo-elements and combinators<br>
<fantasai> lea: with weird syntax<br>
<fantasai> lea: as we figure out how to implement things, we relax restrictions<br>
<fantasai> astearns: sounds like you would be OK with /slotted/ combinator with massive restrictions to begin with<br>
<fantasai> astearns: you would hope that they can be lifted, but OK if not possible<br>
<fantasai> emilio: lifting those restrictions is similar to allowign slotted pseudo<br>
<fantasai> emilio: you may end up poking outside the shadow tree<br>
<fantasai> emilio: not super positive that we would be able to address perf<br>
<astearns> q?<br>
<fantasai> emilio: and has a lot of other questions, like DOM APIs<br>
<fantasai> emilio: what does .matches() do?<br>
<fantasai> emilio: whether slotted matches depends on where the rule comes from<br>
<fantasai> emilio: ? would allow you to poke inside the shadow tree structure<br>
<fantasai> emilio: which is not anything we want<br>
<fantasai> emilio: we don't want to expose shadow tree structure to the outside<br>
<lea> q?<br>
<astearns> ack rniwa<br>
<fantasai> rniwa: agree with emilio<br>
<emilio> s/?/.matches("foo /slotted/ div")<br>
<lea> emilio: how did /deep/ work around these issues? I seem to remember that implementability was not the reason for removing it (but I could be wrong)<br>
<fantasai> rniwa: challenge as implmenter is, the use cases you want are exactly the ones with perf problems<br>
<fantasai> rniwa: consider :has(), devs really want it<br>
<fantasai> rniwa: eventually we added it, but at great cost<br>
<lea> q?<br>
<lea> q+<br>
<fantasai> rniwa: cost of adding something like this is extremely high, and benefit extremely questionable<br>
<emilio> ack emilio<br>
<fantasai> astearns: I'm not confident all the examples have perf problems<br>
<astearns> ack keithamus<br>
<fantasai> keithamus: seems use cases around built-ins, and those like UL styling LI, is this the wrong forum and do we need to think about some way to customize built-ins<br>
<fantasai> keithamus: or do we need something other than combinator that can represent similar trees<br>
<fantasai> keithamus: e.g. styling LI inside UL inside custom element<br>
<fantasai> keithamus: want to slot the LIs<br>
<fantasai> keithamus: [missed]<br>
<astearns> ack bramus<br>
<fantasai> bramus: we seem to be stuck on this pseudo-element selector scope it somehow, which comes to @scope<br>
<fantasai> bramus: we have other way sto contain where your selectors reach into<br>
<fantasai> bramus: if you could @scope onto slotted UL, your selection is contained<br>
<rniwa> q+<br>
<fantasai> bramus: I don't think @scope pseudo-elements are allowed, but maybe pseudo-state idk<br>
<astearns> ack lea<br>
<fantasai> lea: I wanted to challenge what rniwa said, if you look at the actual proposal<br>
<fantasai> lea: he said :has() has a high cost, but also big benefit<br>
<fantasai> lea: if you look at actual issue, lots of excitement from web components community about it<br>
<fantasai> lea: I understand that there are challenges, but not like benefit is marginal either<br>
<fantasai> rniwa: we can continue to disagree on this point<br>
<astearns> ack rniwa<br>
<westbrook> q+<br>
<fantasai> rniwa: another point, some of the use cases could b resolved by having [missed] child descendant to a slot<br>
<fantasai> rniwa: we've been saying we should be able to slot a non-direct descendant<br>
<bkardell_> q+<br>
<fantasai> rniwa: havne't pursued because of priorities, but we would support doing this<br>
<astearns> ack westbrook<br>
<fantasai> westbrook: if there's a link to that conversation, woudl be really awesome to see<br>
<ntim> s/[missed]/non-direct child ?<br>
<fantasai> westbrook: wanted to take a pass on bramus's posit, what if we could create an @scope on a slot element that talked to the light DOM tree of that slotted element represnts?<br>
<fantasai> westbrook: seems like some of the conflict here is about capabilities of a combinator<br>
<bkardell_> https://github.com/whatwg/html/issues/3534#issuecomment-371716571 I believe is the issue (or one of) that rniwa was referring to westbrook<br>
<fantasai> westbrook: but if scope is on track to land, but if could say scope of a slot is the light DOM, and could control all the children of that, could we leverage those capabilities<br>
<fantasai> westbrook: to style things<br>
<fantasai> westbrook: and leverage growing syntax of CSS to this issue<br>
<astearns> ack fantasai<br>
<Zakim> fantasai, you wanted to respond to that<br>
<rniwa> q+<br>
<emilio> fantasai: I don't think @scope is what you want if you want to just "trap" it inside<br>
<ntim> more precisely: https://github.com/WICG/webcomponents/issues/574<br>
<emilio> ... has some interesting cascade implications<br>
<fantasai> .shadowroot::slotted slotted-descendant<br>
<emilio> ... we want a pseudo with tree structure inside<br>
<fantasai> .shadowroot::slotted(slotted-child) > more stuff<br>
<emilio> ... or if we want to restrict the jumping we could do ^<br>
<astearns> ack rniwa<br>
<fantasai> s/we want/better to use/<br>
<fantasai> rniwa: @scope doens't solve the perf issue, because even then you have problem that some shadow root could affect your style<br>
<fantasai> rniwa: that's the challenge that we don't want to take on without extremely high benefit<br>
<astearns> ack bkardell_<br>
<lea> q?<br>
<fantasai> emilio: you need to go from a random DOM element, to the shadow tree where the style may have come from<br>
<fantasai> emilio: if you want random elements to be styled by random slots, to find the right shadow tree you have to do arbitrary shadow tree walks<br>
<lea> q+<br>
<fantasai> <fantasai> OK, thanks, that helps<br>
<fantasai> astearns: [missed]<br>
<fantasai> emilio: pseudo-element is easier<br>
<bkardell_> q+<br>
<fantasai> emilio: [missed this]<br>
<astearns> s/[missed]/is that the case for all solutions (combinator, pseudo, @scope)/<br>
<fantasai> bkardell_: some of the things, I had similar questions about what exactly those combinators were doing exactly<br>
<astearns> ack bkardell_<br>
<fantasai> bkardell_: I'm not sure that I agree when you said that a non-direct chid would solve that<br>
<fantasai> bkardell_: but I aso wanted to just publicly cheer that use case<br>
<lea> +1 slotting non direct children wouldn't solve anyt of my use cases<br>
<fantasai> bkardell_: because I think that use case is way beyond this one<br>
<astearns> s/[missed this]/is that the case for all solutions (combinator, pseudo, @scope)/<br>
<fantasai> bkardell_: would love to see it solved<br>
<astearns> ack lea<br>
<fantasai> lea: we've gone back into discussing other combinators and subtrees<br>
<fantasai> lea: I think there's value in having it be a combinator even if all it does is the same thing current syntax does<br>
<emilio> q+<br>
<fantasai> lea: first, niceer syntax. Don't have to manage parens<br>
<fantasai> lea: it works with querySelectorAll<br>
<fantasai> lea: it has specificity<br>
<fantasai> lea: even if no other extenion, it's still useful<br>
<fantasai> lea: if ppl agree with that, we could go from there<br>
<fantasai> lea: it wouldn't be exactly the same as pseudo-element, just a little bit more<br>
<fantasai> lea: even if no combinators are allowed after slotted combinator, still some value -- and easier to implement<br>
<fantasai> emilio: that still has open question<br>
<fantasai> astearns: open questions different from blocking concerns<br>
<fantasai> emilio: do you want shadow root to be able to query things outside the shadow tree?<br>
<fantasai> emilio: people want it, but not normally how it works<br>
<rniwa> q+<br>
<fantasai> emilio: can argue about syntax<br>
<astearns> q+<br>
<astearns> ack emilio<br>
<fantasai> lea: wrt DOM APIs, you can access anything if the shadow tree is open<br>
<fantasai> emilio: but first of all, this would give you a new capability if we make :matches (???) actually follow this combinator<br>
<fantasai> emilio: exposes shadow tree structure<br>
<ntim> I think he meant Element.prototype.matches()<br>
<fantasai> emilio: we can say doesn't match if you call it from outside shadow tree where the slot lives<br>
<fantasai> lea: I suspect we have to answer these questions in general<br>
<fantasai> lea: can't just make everything a pseudo-element<br>
<fantasai> emilio: yes we can<br>
<astearns> ack rniwa<br>
<fantasai> rniwa: once again, I agree with emilio<br>
<emilio> s/:matches/.matches()/<br>
<fantasai> rniwa: DOM API, entire whole point of shadow DOM is [missed]<br>
<ntim> encapsulation?<br>
<fantasai> rniwa: so idea of finding the element that's not in your tree from another tree fundamentally goes against the design of shadow DOM<br>
<bkardell_> q+<br>
<fantasai> rniwa: this is such a highly important aspect of design<br>
<fantasai> rniwa: I don't think we should introduce any API that violates it<br>
<fantasai> astearns: not sure that creating a combinator with such a radical deviation from other combinators is easy to explain<br>
<fantasai> astearns: limitations in some contexts where we use selectors...<br>
<astearns> ack astearns<br>
<fantasai> astearns: register that concern<br>
<fantasai> bkardell_: what should be in or out wrt shadow DOM<br>
<rniwa> q+<br>
<fantasai> bkardell_: but disagree that we should be against<br>
<fantasai> bkardell_: you *can* walk across, reasonable to have convenience to select across<br>
<fantasai> bkardell_: see it in the wild<br>
<fantasai> bkardell_: closed vs open shadow DOM exists<br>
<fantasai> bkardell_: I think there are use cases<br>
<lea> q?<br>
<lea> q+<br>
<astearns> ack bkardell_<br>
<astearns> ack rniwa<br>
<fantasai> rniwa: I think we can continue to disagree with you on the point, this is not the venue<br>
<fantasai> rniwa: as far as I'm concerned as an implementer, we wouldn't consider this as a possible path<br>
<astearns> ack lea<br>
<fantasai> lea: rniwa, you said against the model of shadow trees<br>
<fantasai> lea: philosophically between elements under a slotted subtree vs light DOM anywhere<br>
<fantasai> lea: I think slotted elements should be fair game<br>
<fantasai> lea: we know from dev surveys that the encapsulation of shadow DOM is one of the reaosns devs don't use shadow DOM<br>
<fantasai> lea: citing that as a reason not to give devs what they need, not a good path forward<br>
<fantasai> lea: priority of constituencies<br>
<fantasai> astearns: Lots of discussion, but no consensus on moving forward, so suggest we take back to the issue<br>
<fantasai> astearns: come up with some alternate approaches, work through the pros and cons of each<br>
<fantasai> astearns: particularly from author perspective<br>
<fantasai> astearns: and discuss this later<br>
<fantasai> ntim: I would add looking at which use case [no audio] so we can agree on more specific syntax that addresses the perf footguns<br>
<fantasai> astearns: so ranking the use cases, looking at most improtant first, and maybe adding for those not in the issue?<br>
<fantasai> s/[no audio]/are perf footguns and which are not/<br>
<fantasai> s/agree/converge/<br>
<fantasai> s/the perf/the non-perf/<br>
<fantasai> astearns: thanks for the discussion, we'll talk later<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7922#issuecomment-1721286352 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 15 September 2023 13:29:40 UTC