2026-08-03
[06:22:51.0463] <zcorpan (OOO June 29 - July 31)>
mfreed: https://addons.mozilla.org/en-US/firefox/addon/xslt-polyfill/

[14:19:22.0662] <bkardell>
zcorpan: interesting... are you going to promote this?

[14:22:06.0060] <bkardell>
I just went to see if you posted about it on socials but didn't see anything 

[15:55:26.0591] <zcorpan>
A search for "xslt polyfill" will be linked from the message at the top of xml files with an xslt xml-stylesheet PI when xslt is disabled


2026-08-04
[03:48:38.0765] <nicolo-ribaudo>
It seems like `html-build/build.sh --docker` is not working anymore:
```
 => ERROR [stage-1 5/6] RUN pipx install bs-highlighter                                            2.8s
------                                                                                                  
 > [stage-1 5/6] RUN pipx install bs-highlighter:                                                       
0.170 creating virtual environment...
0.193 creating shared libraries...
1.262 upgrading shared libraries...
1.992 installing bs-highlighter...
2.737 Fatal error from pip prevented installation. Full pip output in file:
2.737     /opt/pipx/logs/cmd_2026-08-04_10.43.42_pip_errors.log
2.737 
2.737 pip seemed to fail to build package:
2.737     'bs-highlighter'
2.737 
2.737 Some possibly relevant errors from pip install:
2.737     error: subprocess-exited-with-error
2.737     FileNotFoundError: [Errno 2] No such file or directory: 'requirements.txt'
2.737     ERROR: Failed to build 'bs-highlighter' when getting requirements to build wheel
2.738 Error installing bs-highlighter.
2.738 
------
```

TabAtkins I see that there is a `bs-highlighter` release from a few days ago, could it have caused issues?

[03:50:53.0612] <TabAtkins>
Yes new release is slightly breaking, I brought up exactly how it breaks in þͤ issue Sam raised

[03:51:23.0930] <TabAtkins>
That's why it's 3.x, lol

[03:52:23.0447] <nicolo-ribaudo>
Well, "`pipx install bs-highlighter` doesn't work anymore" seems enough of an error that it seemed to not be an intended breaking change :P If it's intended I'll just pin to v2

[03:52:47.0702] <nicolo-ribaudo>
* Well, "`pipx install bs-highlighter` doesn't work anymore" seems enough of an error that I asumed it was not an intended breaking change :P If it's intended I'll just pin to v2

[03:52:52.0438] <TabAtkins>
Oh, I see hm

[03:53:02.0023] <TabAtkins>
Let me test on a bit

[03:54:12.0442] <TabAtkins>
I'm minuting rn 

[03:54:35.0194] <nicolo-ribaudo>
No rush, pinning to 2.0.3 is a good enough workaround for me

[03:54:49.0630] <TabAtkins>
Yes

[11:22:08.0317] <Noam Rosenthal>
If anyone is interested, I'm playing around with the new "stacked PR" feature of github and it seems kind of nice for HTML PRs.
(See https://github.com/whatwg/html/pull/12583, scroll to the bottom and you can see the stack)
I wonder if it can help with reviewing/contributing.

[11:22:12.0884] <Tim van der Lippe>
zcorpan: Do you mind taking a look at https://github.com/whatwg/html/pull/12630 ?

[11:22:28.0515] <Noam Rosenthal>
(https://docs.github.com/en/pull-requests/how-tos/stacked-pull-requests)

[12:19:31.0733] <jmdyck>
I don't really get how a stack of discrete pull requests is better than a stack of discrete commits within one pull request.

[12:24:28.0598] <Noam Rosenthal>
Each PR has its own conversations and review, I don't think you get that per commit?

[12:25:01.0823] <jmdyck>
Ah okay, that makes sense.


2026-08-05
[04:01:12.0873] <keithamus-OOO (return 3rd Aug)>
annevk: https://github.com/web-platform-tests/wpt/pull/61751 I spotted some edge cases with scoped registries which seem inconsistent between browsers/spec. I don't know what the right choice is here but I thought I'd test them per the spec which highlights the failures.


2026-08-06
[00:04:45.0284] <Noam Rosenthal>
whoever was wondering or didn't remember, APAC/EMEA WHATNOT is going ahead as planned today (in a little less than an hour)

[01:22:55.0808] <keithamus>
https://html.spec.whatwg.org/#attr-associated-element 3.1 & 3.2 is the issue, I believe. 

[01:23:13.0515] <keithamus>
(Around attr associated elements cross shadow root not working)

[01:25:44.0536] <Luke Warlow>
Here's a jsfiddle to demonstrate that not working too: https://jsfiddle.net/m0x5enay/

[01:52:47.0830] <smaug>
Isn't commandForElement broken. That is not a content attribute, so how does the reflect part even work?

[01:53:22.0756] <Luke Warlow>
Can you clarify what you mean? commandForElement reflects the commandfor attribute?

[01:53:25.0704] <Luke Warlow>
* Can you clarify what you mean? commandForElement reflects the commandfor content attribute?

[01:53:40.0472] <smaug>
I'm trying to find where that is defined

[01:55:06.0252] <Luke Warlow>
Huh, yeah you're right. It's msising the string in the Reflect

[01:55:16.0697] <Luke Warlow>
I'll make a PR to fix that

[02:03:28.0373] <smaug>
popoverTargetElement similarly broken

[02:03:57.0453] <Luke Warlow>
https://github.com/whatwg/html/pull/12762

[02:06:08.0435] <smaug>
=hmm, is ="<value>" correct syntax, or should it be =<value>

[02:06:15.0740] <smaug>
* hmm, is ="\<value>" correct syntax, or should it be =\<value>

[02:06:29.0377] <Luke Warlow>
The syntax is to use strings there rather than idents

[02:06:43.0051] <smaug>
ah

[02:07:13.0610] <Luke Warlow>
The syntax highlighter doesn't yet handle it very well unfortunately I need to take some time to look into that better

[02:07:21.0182] <Luke Warlow>
* The syntax highlighter doesn't yet handle it very well unfortunately I need to take some time to look into that better. The parsers did get updated.

[02:08:00.0471] <smaug>
PutForwards uses ident. Weird inconsistency 

[02:15:52.0290] <Luke Warlow>
That was a suggestion from Domenic iirc.

[02:16:21.0477] <Luke Warlow>
* That was a suggestion from Domenic iirc. We could always change it in future if we wanted to as it's not actually web observable.

[02:16:39.0165] <smaug>
sure

[02:17:04.0302] <Luke Warlow>
That being said I think for the enumerated attribute stuff that I want to do eventually we do need to use strings as idents don't cover all attribute value syntax.

[02:17:28.0821] <smaug>
yeah, could be

[03:01:16.0797] <smaug>
FWIW, I think the getter part was discussed [here](https://github.com/whatwg/html/issues/5401). It is a bit weird that setting the property somehow just gets eaten - when trying to get it, one gets null. And on the other hand if one sets any random expando property, that would happily leak the shadow node. (and now I need to check if I commented in that issue and said something opposite I'm saying now 🙂 )

[08:01:03.0062] <Dominic Farolino>
Do we have a policy against hyphens in fetch destinations? Things like `serviceworker` and `paintworklet` make sense to me because they're a single term everywhere in the platform. Anne and I got pinged about `email-verification` in https://github.com/WICG/email-verification/issues/45#issuecomment-5052363748. I personally don't see an issue, but could be missing some style policy.

[08:03:53.0696] <smaug>
aha, no openui/whatwg even though it is in the calendar? 

[08:04:02.0192] <smaug>
(but the issues says Aug 20)

[08:04:25.0604] <dbaron>
It's the CSSWG face-to-face having a joint-meeting-relevant session about styling of customizable select

[08:04:48.0609] <dbaron>
dialin info at https://lists.w3.org/Archives/Member/w3c-css-wg/2026JulSep/0095.html

[08:05:15.0797] <smaug>
Any specific agenda?

[08:05:16.0889] <dbaron>
issue is a presentation of https://github.com/w3c/csswg-drafts/issues/14256

[08:05:48.0843] <smaug>
dbaron: main or breakout? 

[08:05:53.0865] <dbaron>
main

[08:06:29.0921] <smaug>
thanks

[08:06:46.0362] <smaug>
* (but the issue says Aug 20)

[08:44:31.0805] <River>
It's not my place to say this, and if such comments are avoided from me, I will respect that.

But I also believe that the point of good defaults is to make it accessible by default not just to make it look better, when people see something that doesn't feel natural, they are more likely to change it, and possibly make something more inaccessable.

[08:44:41.0532] <River>
* I also believe that the point of good defaults is to make it accessible by default not just to make it look better, when people see something that doesn't feel natural, they are more likely to change it, and possibly make something more inaccessable.

[08:45:03.0428] <River>
(apologies if this is unrequited from my side)

[15:09:49.0182] <River>
I do want to say, it was lovely meeting the CSSWG group in person and to witness how the CSS language improves itself. The demos were a wonderful experience, and a look at an aspect of mob programming, for spec improvements was incredible. It's a vast difference from startup culture.

I think I have learnt alot, and I am going to try to contribute to different specifications in the web (or just complain more about them!) as I tend to feel them more with my work :)

[15:09:57.0973] <River>
* I do want to say, it was lovely meeting the CSSWG group in person and to witness how the CSS language improves itself. The demos were a wonderful experience, and a look at an aspect of mob programming, for spec improvements was incredible. It's a vast difference from startup culture.

I think I have learnt much, and I am going to try to contribute to different specifications in the web (or just complain more about them!) as I tend to feel them more with my work :)


2026-08-07
[01:27:56.0449] <Alan Stearns>
Complaints welcome! And as I said yesterday, the more we can hear about use cases from your work, the better we can fit the standards to actual author experience. 

[03:36:17.0100] <Psychpsyo>
Complaining at the CSSWG is my favourite pastime 🙃

[03:41:50.0749] <Psychpsyo>
* Complaining at the CSSWG is one of my favourite pastimes 🙃

[08:40:06.0746] <Dominic Farolino>
annevk: Can I somehow get write access to the sg repo? I'd like to submit a PR, but would also like to not have to fork the repo.

[13:06:50.0233] <River>
Hey for yesterdays truncation conversation - as in what should screen readers read on truncated text? - I think the best solution here is if screen readers can say "text clipped" in the end, because truncation could be truncated very very long text which is irrelevant (i.e. complete articles when reading)

[13:07:38.0330] <River>
meaning that get too much text, rather than being able to effectively read a page (imagine having to read an entire newspaper - rather than choosing which article you read in a newspaper)

[13:07:52.0864] <River>
I don't know if this is possible

[13:08:12.0435] <River>
I guess the Aria team will come back with an answer


2026-08-08
[09:28:32.0106] <Psychpsyo>
Pretty sure screenreaders already offer efficient ways of nacigating around a page, for example by listing out all the headings and letting you skip to one. Otherwise I'd imagine all the headers and sidebars and navbars that come before actual page content on many pages would be completely unbearable. But I think screenreaders should not just read out clipped text either way, since I assume that the developer expectation is that that thext isn't accessible to the user at that point in time. It'd be weird to present it as if it was just all there. It'd also produce a somewhat jarring disconnect between the amount of stuff that's visible on the page and how much the screen reader seems to be getting from it. (Not all screenreader users are 100% blind)

[09:29:22.0058] <Psychpsyo>
* Pretty sure screenreaders already offer efficient ways of navigating around a page, for example by listing out all the headings and letting you skip to one. Otherwise I'd imagine all the headers and sidebars and navbars that come before actual page content on many pages would be completely unbearable. But I think screenreaders should not just read out clipped text either way, since I assume that the developer expectation is that that thext isn't accessible to the user at that point in time. It'd be weird to present it as if it was just all there. It'd also produce a somewhat jarring disconnect between the amount of stuff that's visible on the page and how much the screen reader seems to be getting from it. (Not all screenreader users are 100% blind)


2026-08-10
[00:45:21.0281] <Noam Rosenthal>
smaug zcorpan: good morning! any thoughts about https://github.com/whatwg/html/issues/12652? Seems like blink/webkit are ok with simplifying things in that bit around "allow declarative shadow roots"

[00:51:30.0232] <smaug>
Changing document.open feels a bit risky

[00:54:44.0956] <smaug>
Some telemetry data there could reveal something?

[00:55:13.0596] <Noam Rosenthal>
wdym? this is not a security thing, more of a backwards compat thing?

[00:57:24.0355] <smaug>
I wasn't thinking security but webcompat

[00:57:55.0686] <Noam Rosenthal>
ah gotcha

[00:58:17.0013] <Noam Rosenthal>
note that currently document.open has allowDeclarativeShadowRoots on for the main doc

[00:58:28.0320] <smaug>
sure

[00:59:19.0985] <Noam Rosenthal>
this only changes document.open on documents created with XHR and the such. I don't think it's very common

[00:59:43.0974] <smaug>
"allow declarative shadow roots" is super weird, that I admit 

[01:00:23.0589] <smaug>
parseHTML sets it always true?

[01:01:27.0863] <smaug>
I assume we can get rid of it, but a tiny bit of telemetry data would give some confidence 

[01:02:11.0983] <smaug>
(I can see use cases for using document.open/write for data documents and this would change that behavior)

[01:02:26.0072] <smaug>
* (I can see use cases for using document.open/write with data documents and this would change that behavior)

[01:19:24.0024] <Noam Rosenthal>
> <@smaug:mozilla.org> parseHTML sets it always true?

Yes 

[01:21:46.0197] <Noam Rosenthal>
> <@smaug:mozilla.org> I assume we can get rid of it, but a tiny bit of telemetry data would give some confidence 

Sure. It will take some time to produce that and the numbers are probably above zero and very small (xhr + document.write on the result + template with shadowrootmode for this to have any effect)

[01:22:13.0122] <Noam Rosenthal>
But I am happy to collect that first if it adds confidence 

[01:54:11.0868] <zcorpan>
It sounds like a super-rare case

[01:56:18.0998] <Noam Rosenthal>
note that it's also for detached document streaming which might be less rare
(`document.implementation.createHTMLDocument.write(html)`)

[01:56:29.0299] <Noam Rosenthal>
* note that it's also for detached document streaming which might be less rare
(`document.implementation.createHTMLDocument().write(html)`)

[01:57:13.0992] <Noam Rosenthal>
and I'm kind of OK with making dsd work there... it's not like we're breaking something. Sure keeping `innerHTML` behavior without it makes sense

[02:02:56.0398] <zcorpan>
What was the security rationale for innerHTML? That it could introduce a way to bypass sanitizers? 

[02:04:29.0089] <Noam Rosenthal>
I guess it made <template> something that's potentially unsafe

[02:09:12.0297] <Noam Rosenthal>
Yea it's an mXSS discussion from 2020, see https://github.com/whatwg/dom/issues/831#issuecomment-714240292
I think it was never an issue TBH... downstream sanitizers normally use attribute allowlists, blocklist ones are discouraged for this kind of reason

[02:10:00.0442] <Noam Rosenthal>
Downstream sanitizers don't really work that well with `document.write()` anyway because they don't stream

[02:11:35.0207] <Noam Rosenthal>
Also not sure if checking DSD rejection with telemetry will tell us the story; if we allow DSD to an existing detached document streaming code path it might not be exploited yet... we'll have to check if people use detached document streaming at all and we know people use that.

[02:22:50.0719] <zcorpan>
Noam Rosenthal: sanitizers removing the attribute on `template` wouldn't have an effect on where nodes are inserted though.

But if sanitizers don't use `document.write` then it seems fine

[02:25:10.0356] <Noam Rosenthal>
Server side sanitizers allowing <template> and not checking its attributes would be a problem. But that's not a thing... even very old sanitizers are "deny-by-default", otherwise a lot of the web platform would be in trouble

[02:25:58.0361] <Noam Rosenthal>
TBC - server-side sanitizers usually require the whole document's AST and don't know how to sanitize a partial string like what you'd put into `document.write()`

[02:26:48.0689] <zcorpan>
Noam Rosenthal: I mean a client-side sanitizer that itself uses `document.write` in its sanitization code path

[02:27:17.0838] <Noam Rosenthal>
oh yea that's definitely not a thing

[02:31:24.0492] <zcorpan>
So... maybe shipping on canary and 50% of beta or similar would provide an answer to if it's web compatible? 

[02:32:00.0923] <Noam Rosenthal>
Yea I like that better than ahead-of-time telemetry.

[02:32:58.0021] <Noam Rosenthal>
but actually I don't think it would teach us much, because if this is an mXSS prevention, we'd be adding the mXSS vector and shipping it wouldn't tell us if it's exploited

[02:34:12.0717] <Noam Rosenthal>
all it would do is make detached document streaming respect <template shadowrootmode>. I don't think anyone would complain about it until it's exploited for mXSS.
(but for it to be exploited for mXSS you'd need very badly configured sanitizers in the first place in conjunction with detached document streaming etc)

[02:50:31.0487] <zcorpan>
Noam Rosenthal: I thought the argument for some testing or data collection was currently-unknown usage that would break. But I think it's unlikely. smaug wdyt

[02:52:16.0366] <Noam Rosenthal>
yea "breaking" here is making DSD work so I don't think anyone would complain about that

[02:52:30.0539] <Noam Rosenthal>
(I thought it was about this as well but it's actually an mXSS thing)


2026-08-11
[02:13:44.0545] <Michael Reeves>
Hi! I submitted my first spec PR a few days ago, and I just wanted to double-check that I did everything right as its my first time, and if there's anything else I need to do to mark it as ready to be reviewed? Thanks! The PR is here: https://github.com/whatwg/console/pull/254 :)

[03:18:45.0938] <zcorpan>
Dominic Farolino: ^

[10:18:54.0557] <Dominic Farolino>
Thanks Michael Reeves . I will take a look this week, I was out yesterday so still catching up on things.

[12:31:59.0275] <TabAtkins>
Sorry for the delay, but I've fixed the install issue. However the heck I set up the install for this previously to make it work is a complete mystery, but I know it was a completely bodge due to me not understand python packaging or module/package expectations.

[12:32:06.0092] <TabAtkins>
please try with 3.0.3


2026-08-12
[00:43:07.0407] <Michael Reeves>
That's okay, thanks so much for offering to take a look!


2026-08-13
[22:12:45.0072] <Mark Larah>
Hi folks!

First timer to whatwg here.

At the risk of trudging up ancient history, I'm interested in https://github.com/whatwg/console/issues/222

I note that the spec clarifies that "the printer operation is implementation-defined" - my understanding is that this is where the pushback comes from, given that `console.json` would be strictly normative in its output, as defined by rfc8259 (perhaps with exceptions for syntax highlighting and decorations and such)

So my question is: is `console.json` something we could special case and finagle some wording in the spec? Or am I barking up the wrong tree? (Happy to take a stab at this if so)

Thanks!

[22:13:26.0372] <Mark Larah>
* Hi folks!

First timer to whatwg here.

At the risk of trudging up ancient history, I'm interested in https://github.com/whatwg/console/issues/222

I note that the spec clarifies that "the printer operation is implementation-defined" - my understanding is that this is where the pushback comes from, given that `console.json` would be strictly normative in its output, as defined by rfc8259 (perhaps with exceptions for syntax highlighting and decorations and such)

So my question is: is `console.json` something we could special case and finagle some wording in the spec, at least in principle? Or am I barking up the wrong tree? (Happy to take a stab at this if so)

Thanks!

[22:13:41.0825] <Mark Larah>
* Hi folks!

First timer to whatwg here.

At the risk of trudging up ancient history, I'm interested in https://github.com/whatwg/console/issues/222

I note that the spec clarifies that "the printer operation is implementation-defined" - my understanding is that this is where the pushback comes from, given that `console.json` would be strictly normative in its output, as defined by rfc8259 (perhaps with exceptions for syntax highlighting and decorations and such)

So my question is: is `console.json` something we could special case and finagle some wording in the spec, at least in principle? Or am I still barking up the wrong tree? (Happy to take a stab at this if so)

Thanks!

[22:13:59.0871] <Mark Larah>
* Hi folks!

First timer to whatwg here.

At the risk of trudging up ancient history, I'm interested in https://github.com/whatwg/console/issues/222

I note that the spec clarifies that "the printer operation is implementation-defined" - my understanding is that this is where the pushback comes from, given that `console.json` would be strictly normative in its output, as defined by rfc8259 (perhaps with exception for syntax highlighting and decorations and such)

So my question is: is `console.json` something we could special case and finagle some wording in the spec, at least in principle? Or am I still barking up the wrong tree? (Happy to take a stab at this if so)

Thanks!

[03:52:33.0006] <annevk>
keithamus: does Gecko now support https://github.com/whatwg/html/pull/9546 given your comment? If so, I can rebase it. The a11y issue is already filed. Will see about updating OP so it's linked.

[03:54:06.0072] <keithamus>
I don’t think so. I just had a look given Microsoft are looking into it for chromium; it came up in an open-ui meeting. 

[03:55:27.0134] <annevk>
I see. Well I don't think there's much point in me doing additional work if there's not more support since it might just get out-of-sync again.

[04:01:38.0542] <annevk>
Updated OP at least. Happy to do more once it has a better chance of landing.

[04:29:09.0433] <keithamus>
Noam Rosenthal: I am getting confused about the sanitizer & adoption agency algo interplay.

```
data:text/html,<!DOCTYPE html><body><div id=d></div><script>d.setHTMLUnsafe('<i>a<p>b</i>c', { sanitizer: { replaceWithChildrenElements: ['i'] } });</script>
```

What is the right output here? Without sanitizer, adoption means: `<div><i>a</i><p><i>b</i>c</p></div>`.

If sanitizer ran before adoption then this would perhaps be `<div>a<p>bc</p></div>`? Or if after maybe `<div><p>c</p></div>`?

Chrome says: `<div>a<p>c</p></div>` which... seems wrong?

[04:29:53.0925] <keithamus>
I can ofc make a WPT for this and similar.

[04:30:04.0526] <Noam Rosenthal>
We're currently fixing this in chrome. see https://chromium-review.git.corp.google.com/c/chromium/src/+/8250959

[04:30:31.0527] <keithamus>
Ahh there we go

[04:30:51.0549] <Noam Rosenthal>
(It's fixed in the spec PR)

[04:30:52.0961] <keithamus>
Thanks Noam Rosenthal! I guess the spec PR will need updating for this also?

[04:30:59.0632] <keithamus>
Oh it is? I need to refresh 😂

[04:31:24.0438] <Noam Rosenthal>
I fixed it in the spec PR yesterday. So your question is quite timely

[04:31:59.0325] <keithamus>
Hmm. Build error on https://github.com/whatwg/html/pull/12756; would you kindly try pushing again or something? I kind of rely on the diff preview.

[04:32:24.0254] <Noam Rosenthal>
Oh will do. Wattsi has been really moody recently

[04:32:43.0960] <keithamus>
Maybe the heat is getting to Wattsi like it is the rest of us 😠

[04:35:13.0993] <Noam Rosenthal>
The AAA is kind of mind-bending, but I think it works nicely with the sanitizer... since mostly "Replace with children" means "don't AAA this element" or some such.


[04:35:26.0776] <Noam Rosenthal>
try now

[05:32:02.0640] <zcorpan>
Noam Rosenthal: that seems right I think. Demo  https://software.hixie.ch/utilities/js/live-dom-viewer/saved/14819

I'm my canary (153.0.8005.0) the "foo" is removed. With the new spec text it should not be removed IIUC

[05:46:48.0681] <Noam Rosenthal>
Yea, as I told keithamus above, there is a chromium fix that hasn't landed yet specifically for AAA+streaming sanitizer, matching the new spec text. I've verified that it fixes this scenario and it matches the WPTs added in that CL

[08:49:43.0026] <annevk>
Noam Rosenthal: it seems https://github.com/whatwg/html/pull/6401 got reverted in Chrome but not in the HTML standard. Can you or someone else from Chrome create the patch to revert it in the standard too?

[08:50:36.0929] <annevk>
Oh I was partially misled. That's not the only relevant change. There's one more that added the early return requirement.

[09:00:46.0241] <Noam Rosenthal>
I'll dig about this, sure

[09:02:36.0951] <Noam Rosenthal>
What is "got reverted in chrome"? Is that a particular revert, or some WPTs that doesn't pass, what is the observation?

[09:05:24.0285] <annevk>
Noam Rosenthal: https://issues.chromium.org/issues/40051855 

[09:05:52.0383] <annevk>
Noam Rosenthal: in particular cross-origin `alert()` and friends appear to still work in all browsers, but the specification says they should not work.

[09:32:38.0888] <Noam Rosenthal>
Yea seems like we're not doing this. Other browsers never implemented this?

[09:34:39.0969] <Noam Rosenthal>
(If so, I'm happy to remove it next week)

[09:35:01.0660] <annevk>
Noam Rosenthal: that's my understanding, yes.

[09:41:58.0831] <annevk>
keithamus: any chance you're willing to give the `focusgroup` PR another go? I'm doing an AI review to start. I suspect it still needs somewhat significant work.

[09:42:16.0988] <keithamus>
Just looking over it now.

[13:19:09.0211] <Luke Warlow (ooo till 17th Aug)>
> <@annevk:matrix.org> keithamus: does Gecko now support https://github.com/whatwg/html/pull/9546 given your comment? If so, I can rebase it. The a11y issue is already filed. Will see about updating OP so it's linked.

it's being implemented in chromium and I think Microsoft are pretty on board with this. So we should be able to get that checkbox filled in. Is there something specific we need? I can probably get Greg to comment?


2026-08-14
[06:59:53.0261] <smaug>
Hmm, source.chromium.org works now only in chromium browsers because it uses non-standard stuff? Other browsers get "Uncaught ReferenceError: chrome is not defined"

[07:00:12.0301] <smaug>
Noam Rosenthal or anyone, want to file a bug?

[07:01:22.0835] <smaug>
[Example](https://source.chromium.org/chromium/chromium/src/+/main:chrome/browser/file_system_access/chrome_file_system_access_permission_context.cc?q=chrome_file_system_access_permission_context.cc)

[07:23:39.0053] <Noam Rosenthal>
Oh interesting. Yea I will check this out, thanks 🙏

[07:37:57.0357] <smaug>
thanks


2026-08-15
[03:29:13.0456] <Noam Rosenthal>
Yea seems like it uses `chrome.runtime` for some non-standard screenshot feature. I filed a bug internally


2026-08-17
[02:44:51.0932] <zcorpan>
Hmm for https://github.com/whatwg/html/issues/12782 I guess we could reduce the number of elements (and response size) by using Custom Highlight for syntax highlighting. Don't know if it would make much difference though

[04:59:12.0106] <farre>
I wrote [a bit](https://blog.farre.se/posts/2026/08/17/tracing-web-specs/) about tracing algorithms through web specs, using jjaschke's [`webspec-index`](https://github.com/jjaschke/webspec-index) and a [Firefox extension](https://addons.mozilla.org/firefox/addon/webspec-tracer/) I made.

[06:10:48.0648] <annevk>
zcorpan Noam Rosenthal: could you review https://github.com/whatwg/html/pull/12708 and https://github.com/whatwg/html/pull/12709 and the tests?

[06:40:47.0780] <annevk>
githubstatus.com is all green, yet many things seem to be falling over.

[06:41:40.0983] <annevk>
Ah there we go, now there's a red banner.

[07:03:23.0390] <jmdyck>
@farre: interesting

[07:13:30.0850] <Noam Rosenthal>
sure, will look at it when github is back up...

[07:53:07.0252] <Noam Rosenthal>
Also my stack of PRs (https://github.com/whatwg/html/pull/12583), which has already gone through a few review cycles, touches the adoption agency and I am a bit weary of conflicts... any way we could finish that and then apply this fix on top?

[08:29:59.0840] <Noam Rosenthal>
(specifically supporting the streaming sanitizer needed some extra work around AAA)

[08:33:00.0977] <annevk>
I guess that depends on what kind of changes you ended up making. GitHub is still a shit show so I guess I'll have to look at that tomorrow.

[08:34:38.0620] <Noam Rosenthal>
yea same for your AAA changes... it's likely not a big deal to rebase in either direction 

[08:35:54.0502] <Noam Rosenthal>
Regardless of your change, the first couple of PRs in that stack were already reviewed by zcorpan so I'd like to know if you want to review them as well or proceed with that

[08:40:56.0997] <annevk>
I'd like to take a cursory look at least to see what ends up being changed.

[08:41:17.0408] <annevk>
Especially since I did a bunch of parser maintenance patches just before vacation.

[08:42:39.0013] <Noam Rosenthal>
sure, have at it! I've made sure to rebase on your before-OOO patches (IIRC it was about creating some nodes with the appropriate realm)

[08:48:38.0462] <annevk>
I'm not sure I understand "before-OOO", but yes, any node we create from now on needs to have a specified and ideally tested realm. Specifying it should be fairly automatic as all the creation algorithms now have a realm argument.

[08:53:50.0765] <Noam Rosenthal>
"before-OOO patches" "before the patches you've made before you were out of office"

[08:59:39.0190] <annevk>
Ah, doh. 😀

[09:30:51.0640] <mfreed>
Hi all, just a friendly reminder to post any discussion topics for this Thursday's joint CSSWG/WHATWG/OpenUI task force meeting to the meeting agenda issue: https://github.com/whatwg/html/issues/12715

[12:49:55.0255] <Noam Rosenthal>
Github seems to be mostly up

[14:55:20.0198] <smaug>
There must be a secret plan here to hint to searchfox maintainers to get blink there 😛 

[15:03:25.0743] <smaug>
* There must be a secret plan to hint to searchfox maintainers to get blink there 😛 


2026-08-18
[23:38:48.0417] <zcorpan>
Landing Noam's stack first seems easier wrt rebasing

[01:08:20.0521] <Noam Rosenthal>
Also I found some cases where I think this PR doesn't cover, added a comment

[01:53:42.0671] <annevk>
That's the wrong PR for that comment I think?

[02:05:49.0514] <annevk>
Also, that's technically not a case you can reach per spec because we don't have sync pagehide, but in practice we do have sync pagehide of course. I'll add a tentative test for that as well.

[02:13:59.0939] <Noam Rosenthal>
https://github.com/whatwg/html/pull/12708#issuecomment-5319853865 ?

[02:19:39.0484] <Noam Rosenthal>
We should probably fix https://github.com/whatwg/html/issues/10194 or change the spec to reflect reality

[02:35:33.0067] <Noam Rosenthal>
or just have a global "chrome" property on window that does all kinds of things

[03:28:03.0674] <Noam Rosenthal>
https://github.com/whatwg/html/pull/12794

[04:06:35.0137] <annevk>
Yes we should. Note that 12709 covers AAA (and also covers the pagehide scenario now, I also updated WPT with a tentative test).

[04:07:49.0898] <Noam Rosenthal>
Great looks good now!

[04:08:06.0776] <Noam Rosenthal>
ah it's two different PRs, I thought the second one was the tests

[04:30:46.0780] <annevk>
Note that there's also a second test PR: https://github.com/web-platform-tests/wpt/pull/61398

[04:51:00.0390] <Noam Rosenthal>
Thanks! https://chromium-review.git.corp.google.com/c/chromium/src/+/8261279 fixes some of this in blink

[07:12:08.0128] <annevk>
Noam Rosenthal: some more tests that require further spec changes (Chromium already gets these right): https://github.com/web-platform-tests/wpt/pull/62020

[07:14:15.0191] <Noam Rosenthal>
noice

[07:32:03.0454] <annevk>
I'm going to merge them into 12708 I think. And then tomorrow I'll try to review your four PRs.

[07:34:13.0244] <Noam Rosenthal>
hsivonen, zcorpan, are you OK with landing
https://github.com/whatwg/html/pull/11818? It's been up for a month waiting for additional review (understood since folks were OOO etc, but maybe it's time to move forward...)

[07:55:53.0785] <Noam Rosenthal>
SG!

[08:03:41.0088] <Noam Rosenthal>
Once there are less PRs in flight I want to do a big parser cleanup, specifically around having a parser instance with the different things associated with it, and specifying the type of an "insertion location"

[08:29:00.0142] <Shannon Booth>
speaking of PRs, is there any chance #12127 and #12391 could please get a look? been open for a little and i _think_ ready (maybe just queued in the backlog though)

[09:17:48.0872] <Noam Rosenthal>
I gave these an unofficial review, they look good


2026-08-19
[00:25:20.0354] <hsivonen>
Let's land.

[01:04:58.0440] <annevk>
Hmm we can't land as somehow https://github.com/web-platform-tests/wpt/pull/61156 ended up with conflicts. Noam Rosenthal or foolip can you take a look?

[01:49:28.0052] <Noam Rosenthal>
Yea we changed a couple of tests when we decided to make PI attribute case sensitive, so those were conflicting. Fixed now

[02:07:24.0319] <sideshowbarker>
For the repro at https://github.com/LadybirdBrowser/ladybird/issues/8584#issuecomment-4129011132 we’re trying to figure out which of the following is what the spec requires:

- `beforetoggle` → `toggle` → `beforeunload`
- `beforetoggle` → `beforeunload`  → `toggle`

`beforetoggle` → `beforeunload` → `toggle` is what WebKit and Blink do, but as far as I can see, `beforetoggle` → `toggle` → `beforeunload` is what the spec actually requires.

See my comment at https://github.com/LadybirdBrowser/ladybird/issues/8584#issuecomment-5339875259 for what I found from stepping through the spec.

[02:07:48.0240] <sideshowbarker>
* For the repro at https://github.com/LadybirdBrowser/ladybird/issues/8584#issuecomment-4129011132 we’re trying to figure out which of the following is what the spec requires:

- `beforetoggle` → `toggle` → `beforeunload`
- `beforetoggle` → `beforeunload`  → `toggle`

`beforetoggle` → `beforeunload` → `toggle` is what WebKit and Blink do — but as far as I can see, `beforetoggle` → `toggle` → `beforeunload` is what the spec actually requires.

See my comment at https://github.com/LadybirdBrowser/ladybird/issues/8584#issuecomment-5339875259 for what I found from stepping through the spec.

[02:08:08.0217] <sideshowbarker>
Am I wrong? Is there something I missed?

[02:17:17.0174] <Noam Rosenthal>
annevk: it's mergeable now.

[02:46:30.0626] <Noam Rosenthal>
(Happy to click the button myself if you're Ok with)

[05:08:00.0003] <nicolo-ribaudo>
Is garbage collection happening "in parallel"?

[05:08:19.0234] <nicolo-ribaudo>
https://html.spec.whatwg.org/#ports-and-garbage-collection fires an event when the object is garbage collected, and I'm not sure if it should instead schedule a task to do it

[05:09:12.0643] <nicolo-ribaudo>
Maybe "disentangle" itself should schedule a task, otherwise if the two ports are in two threads it will synchronously call into one from the other

[05:11:19.0415] <nicolo-ribaudo>
Oh yeah all three main browsers already dispatch it asynchronously when calling `.close()`, even for the same-thread case. It's just a spec bug

[05:28:16.0450] <annevk>
Where did the commits go with the tests that I added?

[05:28:53.0456] <annevk>
I think you deleted my work. Can you please undo?

[05:29:48.0980] <annevk>
nicolo-ribaudo: JS defines when garbage collection happens, no? At some implementation-defined time for these new APIs which then goes through a host callback iirc?

[05:35:22.0589] <Noam Rosenthal>
Oh crap sure. I will re-cherry pick those when back at the keyboard 

[06:20:57.0045] <nicolo-ribaudo>
JS delegates to the implementation to actually decide when the "objects become unreachable", and at that point it also then re-delegates to the host to schedule the callback for it

[06:21:15.0628] <nicolo-ribaudo>
In https://tc39.es/ecma262/#sec-weakref-execution

[06:21:45.0559] <nicolo-ribaudo>
* JS delegates to the implementation to actually decide when to do what can be done after that "objects become unreachable", and at that point it also then re-delegates to the host to schedule the callback for it

[06:26:34.0123] <nicolo-ribaudo>
Anyway, I think the answer is "you cannot synchronously run JS code in a _when X is garbage collected, do ..._ kind of thing"

[06:36:57.0739] <nicolo-ribaudo>
* ~~Oh yeah all three main browsers already dispatch it asynchronously when calling `.close()`, even for the same-thread case. It's just a spec bug~~

[06:37:03.0351] <nicolo-ribaudo>
* <del>Oh yeah all three main browsers already dispatch it asynchronously when calling `.close()`, even for the same-thread case. It's just a spec bug</del>

[06:37:26.0547] <nicolo-ribaudo>
Ah it looks like no browser dispatches the `close` event at all, probably it's not worth fixing the spec for it, if anything it should just be removed 😅

[06:58:58.0771] <annevk>
Oh yeah, I think that's another Chromium vestigial thing I've been complaining about. :-(

[07:00:44.0775] <annevk>
I think that's https://github.com/whatwg/html/issues/10201

[07:45:54.0388] <Noam Rosenthal>
Done

[07:49:25.0078] <Noam Rosenthal>
(Sorry for this, forgot to do the double-rebase thing)

[09:52:48.0597] <keithamus>
Noam Rosenthal: https://github.com/web-platform-tests/wpt/pull/62060, https://github.com/web-platform-tests/wpt/pull/62061, https://github.com/web-platform-tests/wpt/pull/62062, https://github.com/web-platform-tests/wpt/pull/62063, & https://github.com/web-platform-tests/wpt/pull/62064 are some edge cases around sanitizer I think aren't covered yet. 

[10:10:19.0391] <Noam Rosenthal>
Nice! I will make sure they're covered when I am back next week. Thanks for the tests!

[11:02:40.0296] <Noam Rosenthal>
Gemini analysis is that all of this is handled: https://gist.github.com/noamr/c674101503818a6b01896c0b39162868

I will go over it tomorrow/monday to see that it's not lying but you can do the same :)

[11:19:01.0683] <Noam Rosenthal>
Oh these are not specific to the streaming sanitizer PR, I see now

[11:30:57.0111] <Noam Rosenthal>
If it's all kinds of pre existing issues with sanitizer can you open specific issues keithamus: ?

Otherwise if one or more of these is specific to sanitizer please be more detailed about the problem 

[11:32:00.0244] <Noam Rosenthal>
(in any case I am happy to review the PRs but maybe freddyor evilpie can do a better job)

[13:19:08.0924] <Dominic Farolino>
Does every single reference to https://webidl.spec.whatwg.org/#legacy-platform-object-getownproperty end up in the same place for you, as it does me?

[14:37:22.0203] <keithamus>
Sorry yeah I was mostly looking through the tests and trying to find gaps in tests, not specific to implementation issues in chrome. 


2026-08-20
[23:58:15.0218] <annevk>
Yeah that seems busted somehow. Might be a Bikeshed issue.

[00:33:29.0432] <annevk>
freddy: did you review https://github.com/whatwg/html/pull/12583? I'm curious where we ended up as you also had a Trusted Types proposal around sanitization.

[00:43:23.0318] <zcorpan>
Merged, thanks!

[00:57:11.0640] <freddy>
not yet, let me see..

[00:59:49.0496] <freddy>
* Adding to my queue, but likely not reviewing this week

[01:01:19.0191] <annevk>
Noam Rosenthal: AI has found a lot of blockers for these 1 TT + 4 HTML stacked PRs. Given that we likely need a couple more rounds here based on what I'm seeing I'd rather merge my PRs.

[01:02:29.0551] <Noam Rosenthal>
Can you send these blockers over?

[01:03:10.0988] <Noam Rosenthal>
That's OK of course, I'll manage with the rebase

[01:04:07.0637] <annevk>
Yeah will do. I guess I'll create a gist again as that seemed to work okay, right?

[01:04:41.0276] <Noam Rosenthal>
yea sure, whatever format. comment/gist/fax all works

[01:05:51.0724] <Noam Rosenthal>
interesting how different people get different results on LLMs for these reviews. Both zcorpan and myself did a few rounds. I wonder if it's a matter of prompt, personal context, or which LLM engine

[01:07:12.0155] <Noam Rosenthal>
annevk: also I'd like to see if anything in the API shape has an issue - I'd like to at least move this to stage 3, or if this is only logical bugs/editorial issues

[01:07:30.0794] <annevk>
https://gist.github.com/annevk/973d21ae390332babf94d6abddaf9a08 

Note that the initial HTML PR is covered by both files. Probably the second file has a better review for it.

[01:07:55.0803] <annevk>
I was using Opus 5 at max effort FWIW.

[01:09:08.0219] <annevk>
I think we have agreement on most of these features, except for maybe the Trusted Types integration. At least I know freddy wanted to look at that.

[01:10:31.0097] <zcorpan>
Might be worthwhile to set up a loop that reviews with different models

[01:17:26.0645] <annevk>
It seems my own PRs have also been invalidated, but hopefully they are not too hard to rebase on top of out-of-order streaming.

[01:40:12.0154] <annevk>
Noam Rosenthal: I guess I should wait with further refactoring. I really want to turn the insertion location into a tuple. Though if you can think of changes that would make your PRs easier to review, perhaps it would be good to make those as smaller standalone changes first.

[01:45:42.0771] <annevk>
See https://github.com/whatwg/html/issues/1706 for context. Before vacation I was just trying to address a number of old HTML parser issues which is how I stumbled upon this mess.

[01:47:31.0599] <Noam Rosenthal>
Yea there's a ton of mess in the parser. I am more familiar with it now after integrating it with all the new stuff (sanitizer/streamHTML) 

[01:48:17.0380] <Noam Rosenthal>
Rebasing was actually quite easy

[01:57:44.0809] <Noam Rosenthal>
Though the bottom 2 PRs in the stack don't rely on anything special in the parser. It's just new calls to the fragment parser. Where it touches the parser internals is with streaming

[02:55:42.0035] <Noam Rosenthal>
freddy: we discussed this a few weeks ago and at WHATNOT

[03:21:51.0637] <Michael Reeves>
Dominic Farolino: just following up on this, no worries if you're busy!

[03:25:46.0554] <Noam Rosenthal>
I can address the "make insertion into a tuple" thing before, and also making the "fragment case" more normative. I think doing those would make the reviews of the upper two PRs easier (though they shouldn't affect the bottom two at all)

[03:36:59.0427] <annevk>
Thanks! And interesting, I would have expected it to impact the sanitizer integration.

[03:38:11.0432] <Noam Rosenthal>
yea it does affect that, that's the 3rd PR in the stack

[03:39:10.0630] <Noam Rosenthal>
The first two are mostly independent of parser stuff, but they touch the fragment parser initialization so I preferred to put them first. they're also much simpler

[03:39:28.0398] <annevk>
Oh I guess this shows my confusion with stacks.

[03:40:04.0093] <Noam Rosenthal>
yea it goes bottom up... I guess it's more like a queue

[03:41:13.0042] <Noam Rosenthal>
point is, the first two are quite independent, and this stack is built in a way where each PR can be submitted sequentially and we don't need to review *everything* at once

[03:41:27.0026] <annevk>
Noam Rosenthal Luke Warlow: so for innerHTML, an XML document, and Trusted Types, the story is that TrustedHTML is accepted and a string is not, right? Would we throw for this new type so we can make it work later?

[03:42:24.0734] <annevk>
Okay, I guess we should focus on Trusted Types for now then and hopefully freddy can review it soon. Or am I incorrect in assuming that has to land first as well?

[03:43:12.0906] <Luke Warlow>
> <@annevk:matrix.org> Noam Rosenthal Luke Warlow: so for innerHTML, an XML document, and Trusted Types, the story is that TrustedHTML is accepted and a string is not, right? Would we throw for this new type so we can make it work later?

Yes TrustedHTML is accepted and a string is rejected, I think the idea is that this new type is rejected too (because sanitizer just doesn't work for XML)

[03:43:46.0552] <Noam Rosenthal>
it has to land first as well in this stack, but I could change the order if absolutely necessary (rather not)

[03:49:01.0968] <annevk>
Alright cool. Let's aim for that then.

[03:50:09.0592] <annevk>
Okay, yeah that makes sense to me. I doubt we'll ever put it in the effort, but who knows.

[04:55:17.0828] <zcorpan>
Noam Rosenthal: are the extra commits in https://github.com/web-platform-tests/wpt/pull/61748 expected? 

[05:27:55.0972] <Noam Rosenthal>
Maybe it's not stacked correctly on top of the other ones. But there are a few new commits for streamHTML together with template for 

[06:46:38.0423] <Noam Rosenthal>
I will check on Monday. Perhaps let's focus on the bottom of the stack first (trusted types, positional methods) and then I will re-align the rest once that lands?

My initial goal with stacking is that reviewers will be able to see the whole picture but we can land them one at a time 

[07:17:55.0848] <danae404>
Would someone be able to send me a link to the WHATNOT meeting today? Also, if there's time in the agenda, could someone add https://github.com/whatwg/html/pull/12735? (I think I don't have permission to add agenda+ myself)

[07:41:55.0624] <annevk>
Hey danae404, I added you to the calendar. I'll also fix your permissions in a second.

[07:42:33.0810] <danae404>
Thank you!

[07:44:12.0612] <annevk>
danae404: also, it seems it was already discussed two weeks ago and people are generally supportive based on the comments on the PR.

[08:02:55.0274] <danae404>
annevk: I wasn't sure if it needed further discussion regarding whether or not to restrict it to added tracks

[08:45:34.0003] <annevk>
zcorpan: could you review https://github.com/whatwg/html/pull/12703?

[08:45:52.0920] <annevk>
* zcorpan Noam Rosenthal: could you review https://github.com/whatwg/html/pull/12703?

[09:11:45.0028] <Noam Rosenthal>
Afk until Monday, will look then if no one beats me to it

[09:57:30.0837] <annevk>
Dominic Farolino: https://github.com/web-platform-tests/wpt/commit/ed37f83e79426194b075cfc29a5454894ae6f36f has the crashing test. https://github.com/whatwg/html/commit/57811ef0dca48568665d65eafd827764e9e454a2 is the HTML parser fix.

[09:58:20.0457] <annevk>
It's done, ta!


2026-08-21
[00:52:58.0116] <zcorpan>
annevk: how is a shadow root for color input observable?

[02:17:27.0834] <zcorpan>
https://github.com/whatwg/html/issues/12782#issuecomment-5367466383 may be of interest for someone wanting to address perf issues with HTML singlepage

[02:34:36.0994] <annevk>
https://github.com/whatwg/html/issues/3748

[03:14:19.0898] <zcorpan>
Thanks.  https://software.hixie.ch/utilities/js/live-dom-viewer/saved/14839 logs inline-block in firefox and safari, and the empty string in chrome.

[03:17:49.0619] <zcorpan>
I guess it should also be the empty string in safari if it uses a shadow root (and no `slot`), per spec?

[04:54:02.0537] <annevk>
Yoav Weiss's AI counterpart just migrated a bunch of Navigation API issues. Perhaps it's time for a "topic: navigation api" label? farre Noam Rosenthal?

[04:54:47.0322] <farre>
sounds good to me

[04:55:11.0945] <Noam Rosenthal>
Yea I promised I will triage these next week. Having it as a topic sg

[04:56:12.0279] <Noam Rosenthal>
I have a blink fix for this stuff that needs polishing but almost ready

[04:58:21.0887] <annevk>
I think that's right, but it might also be that we have an older version of getComputedStyle or some such as I'm pretty sure that used to work on out-of-tree elements before.

[06:05:02.0453] <annevk>
Stephen: I randomly came across https://github.com/whatwg/html/pull/12153 again. Are you still pushing that, should I put it on my queue?

[06:08:41.0934] <Stephen>
I would like to make progress on it, yes. But obviously it's not urgent thanks to the prioritization of HTML-in-Canvas. Let me check exactly where it's at, rebase if necessary, and I'll get back to you.

[06:10:38.0024] <annevk>
(Was not obvious to me btw.)

[06:12:33.0582] <Stephen>
Fair enough, sorry.

[07:01:23.0566] <Tim van der Lippe>
Is there a particular historical reason why WebKit export PRs to https://github.com/web-platform-tests/wpt/ are all "WebKit export of <bug link here>"? All other browsers include the text of the actual description, which I find a lot easier to figure out what the change is. The WebKit commits don't have a PR title nor description, so it's a lot trickier to figure out what the change is.

[07:15:47.0757] <annevk>
It's the unfortunate nature of WebKit's export script. I wish someone would fix it. Maybe Sam Sneddon [:gsnedders]? 

[07:34:54.0998] <annevk>
nicolo-ribaudo jmdyck: what's next for https://github.com/tc39/ecma262/pull/3728? Would be nice to get that one resolved (along with the IDL and HTML changes).

[07:36:16.0536] <annevk>
One thing I should perhaps do is throw it at AI again to see if post-vacation AI can find some novel issues.

[07:56:28.0257] <annevk>
I've tried to fix base URL handling as we never really specified it properly. It mostly ended up matching Gecko, but there are some differences when using `<base>` with relative URLs inside `about:srcdoc` in particular. Gecko makes that work somehow despite it not working inside `about:blank`. https://github.com/whatwg/dom/pull/1492 & https://github.com/whatwg/html/pull/12674 have the proposed model as well as links to plenty of tests. smaug Dominic Farolino thoughts?

[07:57:50.0956] <smaug>
is that initial about:blank or any about:blank? 

[08:01:11.0102] <annevk>
smaug: at least initial about:blank. There's also tests for about:blank but don't recall offhand.

[08:01:50.0601] <smaug>
ok. I'll check. I wouldn't be surprised if initial about:blank has some special issues

[08:03:29.0257] <jmdyck>
It's going to take me a few days to get back to that, I think.

[08:03:34.0471] <annevk>
smaug: FWIW, I think `<base>` with relative URLs not working for these URLs is somewhat preferable if we can get away with it as it simplifies the amount of state we have to keep around. Overall this ends up being a simplification (as well as actually properly specifying cloning behavior).

[08:09:40.0293] <annevk>
No rush, just noticed it's now okay to land from a TC39 perspective. Let me know when we get closer and I'll let AI do another pass.