2026-09-01
[01:24:09.0343] <annevk>
zcorpan freddy Noam Rosenthal: is everyone now on the same page with the Trusted Types bits of the parser changes? I'd like to let AI do a final-review given the many changes but hopefully we can land that soon then.

[01:29:47.0688] <annevk>
zcorpan Noam Rosenthal hsivonen: I found more HTML parser interoperability issues, this time with foster-parenting (no specification changes required this time though): https://github.com/web-platform-tests/wpt/pull/62346 

[01:29:57.0283] <freddy>
Generally yes, though I haven't re-reviewed latest changes after my first pass on friday. 

[01:51:30.0529] <Michael Reeves>
Hi! I was wondering if anyone could please review my small console spec change, I've been waiting about a month. It's here: https://github.com/whatwg/console/pull/254 If there's anything else I need to do in order for it to be reviewed LMK. Thanks! :)

[01:54:47.0680] <annevk>
Maybe Dominic Farolino can take a look.

[01:54:57.0522] <annevk>
* Hopefully Dominic Farolino can take a look.

[01:55:22.0527] <annevk>
One thing I'm noticing myself is that it's doing the setter steps pattern incorrectly.

[01:55:48.0022] <annevk>
It's pretending there's a _value_ parameter whereas instead Web IDL describes a magical "the given value" phrase we ought to use.

[01:56:42.0353] <Ms2ger>
Speaking of PRs, is there anyone who could merge https://github.com/w3c/DOM-Parsing/pull/88 ? Maybe sideshowbarker ?

[02:15:02.0346] <annevk>
zcorpan Noam Rosenthal: I'm once again surprised at the lack of alignment between AI tools. Claude found a lot that's possibly wrong. Some of the defects might be design decisions I suppose (such as not honoring the sanitizer for TrustedHTML inputs), but they do seem rather surprising and I don't think the proposed commit message spells them out?

https://gist.github.com/annevk/adeb57f8be2ccd3d75fb8d8523cf598a

[02:55:57.0344] <hsivonen>
Thanks. keithamus ^

[05:08:23.0283] <annevk>
Noam Rosenthal: a test where we invoke open() on the a parseHTMLUnsafe document is invalid as parseHTMLUnsafe creates a document with an opaque origin currently. So open() throws. I don't remember if that was intentional or not.

[05:42:13.0784] <annevk>
What do you think we should do? Who else might have an opinion? Luke Warlow?

[05:43:27.0373] <Luke Warlow>
Is there a GitHub comment for context here?

[06:23:24.0627] <annevk>
No, I was just looking at WebKit test failures for `shadow-dom/declarative/declarative-shadow-dom-opt-in.html` and stumbled across this.

[06:23:34.0535] <annevk>
I guess I should file an issue.

[06:30:40.0678] <annevk>
https://github.com/whatwg/html/issues/12878

[06:37:56.0535] <Noam Rosenthal>
oh interesting

[06:42:56.0594] <Noam Rosenthal>
For most of this stuff it seems like the problem is in the most recent change since freddy's comment (plus a few nits), so it could be a genuine mistake in that part

[07:10:14.0302] <Noam Rosenthal>
annevk: I went through them, 2 are wrong, and the rest are mostly missing comments/some changes to examples/nits. There was one logical error in the recently changes algorithm (I have to return the author-provided sanitizer and not null when the author passed TrustedHTML). 

[07:11:23.0925] <Luke Warlow>
What's weird here is Chrome does seem to do a same origin check on document.open() and at least according to the Origin API parseHTMLUnsafe() does return a document with an opaque origin

[07:13:52.0320] <annevk>
Wait Chrome does not throw when you pass a document to `Origin.from()`?

[07:19:23.0615] <Luke Warlow>
Oh whoops scratch that I used the constructor (which doesn't throw with excess params)

[07:19:40.0529] <Noam Rosenthal>
I do have to still update the HTML bit and also the commit message of the trusted-types bit

[07:43:42.0763] <bkardell>
who is the editor of fs? https://github.com/whatwg/fs. Just curious, no real particular reason - there's none listed at the top and there's an ack in the bottom but I'm not sure 

[07:45:02.0961] <Noam Rosenthal>
Didn't we assign a new editor at web engine hackfest?

[07:48:07.0454] <annevk>
I'm the editor as per https://whatwg.org/workstreams. The deputy editor is Austin Sullivan per https://github.com/whatwg/sg/blob/main/db.json though he has been inactive. James M Snell is planning to take over. We had scheduled a meeting to discuss that, but something came up.

[07:51:46.0041] <annevk>
It does seem weird that the Acknowledgments section talks about Marijn. It seems that https://github.com/whatwg/sg/commit/5d1adcc36daebc51298d9a290823777181b37ddb did not happen on both sides.

[08:17:34.0593] <Noam Rosenthal>
Fixed the html bits as well, they were 100% suggestions/nits so it makes sense different LLMs come up with different issues.

To conclude, out of all of this, the only substantial issue was carrying over the given `sanitizer` when calling unsafe methods with `TrustedHTML` and a {sanitizer}

[09:32:35.0370] <annevk>
I'll have another look tomorrow, but you're saying that ignoring the sanitizer when TrustedHTML is passed was indeed a bug?

[09:33:26.0915] <annevk>
While not substantive, I also found the "setter steps" change a bit troubling, I take it that is addressed as well?

[09:51:15.0926] <Noam Rosenthal>
Yes - that one was a bug.

[09:51:38.0777] <Noam Rosenthal>
Yes, all of the comments you've sent are addressed

[10:15:21.0967] <Noam Rosenthal>
The "setter steps" thing - why is this troubling? I thought we try to fix phrasing to be normative in places where we touch. That was at least the intention... but I reverted it to be "the given value"

[12:51:07.0280] <annevk>
Can you clarify what you mean? Web IDL defines the pattern, no?

[12:53:36.0771] <Noam Rosenthal>
those setters don't have an xref to that "given value" so I thought it's just prose like we had for "insertion point"

[12:53:53.0219] <Noam Rosenthal>
* I see, those setters don't have an xref to that "given value" so I thought it's just prose like we had for "insertion point"

[12:54:01.0748] <Noam Rosenthal>
TIL that it's a normative thing

[16:38:27.0464] <James M Snell>
Yeah still planning to jump in here soon but have been absolutely buried the past month. Hoping to start digging in on this in the coming couple of weeks


2026-09-02
[22:29:04.0633] <annevk>
We could maybe have a <dfn> for "the given value". Forgot why Domenic and I opted not to do that.

[00:12:09.0933] <hsivonen>
It looks to me like Chromium is switching (non-XSLT) XML parsing from libxml2 to https://github.com/kornelski/xml-rs . The README of the crate says that it targets XML 1.1. Is Chromium switching support for Web XML from 1.0 4th ed to 1.1, or are there some changes to keep the target as 1.0 4th ed. despite the README?

[00:15:19.0223] <hsivonen>
Whoa. TIL that 1.0th 5th ed. went this far: https://github.com/kornelski/xml-rs/commit/bd8fe074cca1ed5f1aadaa151284c3d218308484

[00:15:56.0437] <hsivonen>
Was Chromium doing 5th ed. already previously? I thought the Web was 4th ed.

[00:16:32.0478] <hsivonen>
FWIW, libexpat is explicitly 4th ed.

[00:21:08.0548] <hsivonen>
Whoa. https://wpt.fyi/results/xml/xml-prolog-accepted-versions.html?label=master&label=experimental&aligned

[00:22:42.0508] <hsivonen>
I have a recollection of the WHATWG leaning towards staying on 4th ed. Was Chromium's and WebKit's move to 5th ed. discussed here or did it just happen?

[00:25:30.0923] <hsivonen>
The wpt test case appears to come from a hidden Chromium issue: https://issues.chromium.org/issues/441911594

[00:53:06.0727] <hsivonen>
Looks like Chromium was doing this already 13 years ago: https://bugzilla.mozilla.org/show_bug.cgi?id=501837#c5

[00:54:09.0236] <sideshowbarker>
Ladybird shows the same results as WebKit and Chrome for that

https://wpt.fyi/results/xml/xml-prolog-accepted-versions.html?label=master&product=chrome%5Bexperimental%5D&product=firefox%5Bexperimental%5D&product=safari%5Bexperimental%5D&product=ladybird&aligned

And Ladybird’s just using libxml2 as-is. So I assume that’s from libxml2 behavior as-is.

[00:54:57.0450] <hsivonen>
sideshowbarker: AFAICT, libxml2 has a flag to request 4th ed. behavior, but I guess the browsers that use libxml2 don't set that flag.

[00:57:17.0953] <hsivonen>
I'm very curious why 5th ed. didn't take the relaxation of the value space of text node content from XML 1.1. That's in practice a much bigger footgun of XML and would have been worthwhile to fix if making a breaking change. Instead, stuff like https://learn.microsoft.com/en-us/openspecs/office_standards/ms-oi29500/d34ae755-c53f-4a44-a363-c6dd3ee018a4 had to happen.

[00:57:48.0285] <sideshowbarker>
Right. I implemented Ladybird’s switch over to libxml2 (away from a custom XML parser LB had until then). And I guess I didn’t even know about that switch. But even if I had, I wouldn’t have used it — because, interop.

[01:17:20.0058] <annevk>
hsivonen: pretty sure we knew this was broken and out of sync.

[01:47:25.0327] <eemeli>
Having just needed to look into something around XML, I happened to notice that the normative reference in the HTML standard points to https://www.w3.org/TR/xml/, which is currently 1.0 5th edition.

It seems a bit surprising to me that there isn't alignment on this.

[01:48:12.0439] <Ms2ger>
Is that the XML5 I've heard so much about?

[01:48:17.0568] <Ms2ger>
/me 🦆🦆🦆

[02:57:57.0070] <Noam Rosenthal>
we do have a dfn for it, but it's not referenced

[02:58:11.0840] <Noam Rosenthal>
https://webidl.spec.whatwg.org/#the-given-value

[02:58:57.0182] <Noam Rosenthal>
I can prepare a PR for a blanket replacement of this (but not before I finish the current PRs)

[02:59:27.0218] <Noam Rosenthal>
anyway, this is fixed in the new revision together with everything else, plus better PR commit messages

[04:48:29.0409] <annevk>
hsivonen eemeli: https://bugzilla.mozilla.org/show_bug.cgi?id=501837

[04:54:42.0645] <annevk>
Oh wait, you already pointed out that bug. Well, that's all I know about the topic.

[07:04:11.0231] <Stephen>
13 years ago on Chrome it might have been me who rolled a new version of libxml2 and didn't pay any attention at all to behavior changes. Honestly, at the time all we cared about was getting security fixes in.

[07:11:32.0590] <annevk>
Noam Rosenthal: https://gist.github.com/annevk/adeb57f8be2ccd3d75fb8d8523cf598a#file-tt-parser-review-follow-up-txt I removed one thing it got wrong, I didn't verify everything though.

[07:16:01.0346] <Noam Rosenthal>
Thanks! Going over it now. Looks smaller than before :)

[07:26:38.0357] <Noam Rosenthal>
Fixing now. The second "blocker" is actually editorial and I would classify it as a suggestion. Trusted types can indeed not enable JS execution if the caller didn't request it. But the note can be explicit about that being done when using the default policy

[07:32:35.0055] <annevk>
I don't see new commits on whatwg/html?

[07:34:03.0622] <Noam Rosenthal>
("Fixing", not committed yet)

[07:39:19.0869] <annevk>
Sorry :/

[08:01:25.0941] <Noam Rosenthal>
ok all that stuff is fixed.

[08:08:04.0077] <Noam Rosenthal>
(and committed to html/tt :))

[08:08:13.0549] <Noam Rosenthal>
* (and committed to html & tt :))

[08:58:13.0328] <Shannon Booth>
for spec tags:
 * navigation
 * navigation API
 * frames/navigables/browsing history
 * history

I may be missing something obvious, but what is the difference between these things? seems to have a lot of overlap

[09:07:47.0647] <Noam Rosenthal>
Maybe navigation & history can fold into the 3rd one

[09:07:58.0305] <Noam Rosenthal>
(I didn't know about that one, I don't think it was in use much)

[09:08:43.0295] <dbaron>
Not sure why it's hidden, but the issue is the issue for adding xml-rs support.

[09:09:19.0971] <dbaron>
and fwiw any substantive discussion should be in the code reviews on gerrit which should be visible

[09:11:16.0085] <dbaron>
effectively I think that test was a followup to the code review discussion in https://crrev.com/c/7088396?tab=comments

[09:12:20.0338] <dbaron>
... which I then added in https://crrev.com/c/7118800

[09:16:56.0343] <dbaron>
in particular I think I was following up on https://chromium-review.git.corp.google.com/c/chromium/src/+/7088396/comment/d88f4f53_e0ec9809/


2026-09-03
[23:10:20.0823] <annevk>
navigation API is for the sole use of the Navigation API.

navigation was originally for the complete navigate algorithm. But not necessarily browsing context creation and such.

frames/navigables/browsing history would cover browsing context creation. And I guess history, I never really read that part... So not sure why we also have a separate history. I wouldn't mind if someone reorganized this a bit.

[23:11:33.0985] <annevk>
Does anyone know since when PR Preview is not working for HTML anymore? Did anyone file an issue already?

[23:13:48.0062] <sideshowbarker>
I think the hosting will move to W3C.

[23:14:13.0745] <sideshowbarker>
For specref too

[23:15:16.0217] <sideshowbarker>
I’m not a party to any decision-making about it, but that’s what I’ve gleaned is most likely

[23:15:34.0333] <sideshowbarker>
I don’t know about when it started

[23:16:37.0155] <sideshowbarker>
First I heard was last week, auto-publishing for some W3C WG specs broke, due to specref

[23:18:14.0349] <sideshowbarker>
OK I find https://github.com/tobie/pr-preview/issues/186

[23:18:43.0473] <sideshowbarker>
…which cites https://lists.w3.org/Archives/Public/spec-prod/2026JulSep/0002.html

[23:19:11.0106] <sideshowbarker>
> Specref and PR Preview are currently unavailable due to an issue with the
> Heroku account on which these services are hosted.

[23:39:43.0787] <annevk>
I ran it again and it came up with https://gist.github.com/annevk/adeb57f8be2ccd3d75fb8d8523cf598a#file-tt-3-txt 

Seems like it should be close, but some of the fixes regressed a few things maybe?

[23:40:42.0605] <annevk>
Thank you! That's unfortunate

[23:41:14.0030] <annevk>
* Thank you! That's unfortunate. (The incident, not it moving to the W3C. That might be a good thing.)

[00:51:05.0573] <Ms2ger>
Yeah, having our entire spec ecosystem rely on tobie not cancelling his credit card (much as his contributions are appreciated) is not exactly robust

[01:19:08.0510] <Noam Rosenthal>
yea it seems mostly related to the follow up changes. Fixed now. I think the suggestion for how to handle XML is better, applied that

[01:24:02.0928] <Noam Rosenthal>
(also keeping the WPT PR up to date with these changes)

[02:11:30.0232] <zcorpan>
If PR preview was working we could see the effect of these changes https://github.com/w3c/htmldiff-ui/pull/26 

[06:05:33.0700] <Tom Schuster>
So this is a known issue? I kind of rely on it for review.

[06:33:47.0773] <zcorpan>
Yes see previous comments in the channel


2026-09-04
[21:42:10.0813] <sideshowbarker>
Trying to get Ladybird to properly handle searchfox.org pages — including the ability to click to select lines and line ranges.

[21:42:35.0979] <sideshowbarker>
And finding myself a little surprised that page like  like https://searchfox.org/firefox-main/source/modules/libpref/init/StaticPrefList.yaml#16955-16965 is 16MB.

[21:43:05.0614] <sideshowbarker>
…where the local file in my Firefox clone is 613K.

[21:43:48.0431] <sideshowbarker>
But I guess that’s probably a not-atypical case for something that’s got syntax highlighting added, and what-not.

[21:45:54.0085] <sideshowbarker>
But to put things in perspective a bit: That 16MB is the same size as the single-page https://html.spec.whatwg.org/ HTML spec.

[21:46:40.0212] <sideshowbarker>
 — which on the face of it seems… a bit excessive, just for showing one source code file

[21:46:46.0190] <sideshowbarker>
Or maybe it’s not, I dunno.

[21:49:05.0555] <sideshowbarker>
It’s just that, I actually *use* searchfox.org in Ladybird — for linking to Firefox sources in Ladybird PRs where the change includes something modeled on Firefox code.

[21:49:23.0925] <sideshowbarker>
And, I like to link the specific line numbers/ranges.

[21:50:54.0592] <sideshowbarker>
Ladybird anyway doesn’t yet have super-spectacular performance with large files. So I already did not prefer trying to use the single-page HTML spec in LB.

[21:52:49.0309] <sideshowbarker>
But … to able to at least be able to click-link as expected to line numbers in searchfox.org — that doesn’t seem like it should need to require great performance on super-large files.

[21:53:08.0711] <sideshowbarker>
 // end rant

[21:53:29.0461] <sideshowbarker>
* And finding myself a little surprised that a page like https://searchfox.org/firefox-main/source/modules/libpref/init/StaticPrefList.yaml#16955-16965 is **16MB**.

[21:54:08.0047] <sideshowbarker>
*  — which on the face of makes 16MB to show just one code file seem… a bit excessive

[21:54:57.0059] <sideshowbarker>
* It’s just that, I actually _use_ searchfox.org in Ladybird — for grabbing links to Firefox sources when I’m writing up Ladybird PR descriptions for PRs where the change includes something modeled on Firefox code.

[21:55:22.0316] <sideshowbarker>
* And, I like to give reviewers links to the specific line numbers/ranges. 

[21:55:42.0351] <sideshowbarker>
* Ladybird anyway doesn’t yet have super-spectacular performance with large files. So I already didn’t exactly prefer trying to use the single-page HTML spec in LB.

[21:56:05.0026] <sideshowbarker>
* But … to able to at least be able to click-link as expected to line numbers in searchfox.org pages — that doesn’t seem like it should need to require great performance on super-large files.

[21:56:32.0226] <sideshowbarker>
* However, to put things in perspective a bit: That 16MB is the same size as the single-page https://html.spec.whatwg.org/ HTML spec.

[21:57:08.0500] <sideshowbarker>
* But … to at least be able to click-link as expected to line numbers in searchfox.org pages — that doesn’t seem like it should need to require great performance on super-large files.

[22:10:46.0260] <sideshowbarker>
in contrast, https://github.com/mozilla-firefox/firefox/blob/main/modules/libpref/init/StaticPrefList.yaml is actually pretty snappy in Ladybird — it loads relatively quick, and the linking-to-lines behavior is usable right way

[22:11:51.0892] <sideshowbarker>
/me goes back to finishing up the PR description which led him into this ranting detour

[00:53:08.0859] <annevk>
zcorpan: instead of `posterfromimg`, was it ever considered to use `poster=""`? It seems we already special case that state.

[00:56:27.0037] <zcorpan>
annevk: It doesn't allow using a fallback and makes feature-testing harder. But maybe it's better in the long term?

[00:58:51.0645] <annevk>
zcorpan: `currentPoster` enables the feature testing, no? So you could do the fallback based on that I suppose. `posterfromimg` seems very ungainly.

[01:00:09.0776] <zcorpan>
annevk: Yes. Just lacks a declarative way to do fallback, but that seems ok

[01:25:04.0571] <zcorpan>
Do people use the 'y' shortcut in specs for the commit snapshot link? It seems to me it could be activated by accident

[01:37:00.0434] <zcorpan>
See https://github.com/whatwg/whatwg.org/pull/507

[02:46:10.0221] <zcorpan>
annevk: I think Noam's stack is ready now

[04:11:44.0475] <zcorpan>
How important is the font for https://html.spec.whatwg.org/#table-example-1 ? Thinking of yanking it and making it `monospace` to optimize perf

[04:20:19.0949] <Ms2ger>
Is very pretty though

[04:43:42.0508] <zcorpan>
https://github.com/whatwg/html/pull/12906

[09:10:56.0525] <Noam Rosenthal>
had to rebase with the `javascriptURLs` commit, it's all resolved now


2026-09-05
[03:43:46.0247] <annevk>
I'm still reviewing the TT change. AI says some of the domintro and notes might be stale.

>   - source:126274, 126518, 126611, 126737 — the four domintro TypeError sentences are now wrong and should be deleted. They say: "Throws a TypeError if the node document is an XML document and a Trusted Types default policy supplied a sanitizer
  (unless Content Security Policy is report-only)." With the fall-through, an XML document skips createParserOptions entirely, so the XML path is now identical to pre-PR behavior. Concretely, XHTML document + require-trusted-types-for 'script'
  enforced + default policy {createHTML: s => s, createParserOptions: o => ({...o, sanitizer})}: documentType is "xml" → shortcut skipped → get trusted type compliant string → createHTML runs → no TypeError, contradicting the sentence. And in the
  case where it does throw (no createHTML), the cause is the ordinary sink-type mismatch, not the supplied sanitizer — that throw already happens on main today. This PR introduces no new exception in XML documents, so all four sentences describe
  behavior that doesn't exist.


[03:46:51.0624] <annevk>
Here's the rest https://gist.github.com/annevk/adeb57f8be2ccd3d75fb8d8523cf598a#file-tt-4-txt

[03:48:07.0770] <annevk>
This behavior for XML does make sense I think. Especially if we also make TrustedHTML throw.

[04:21:49.0472] <Noam Rosenthal>
OK fixed those issues (they're mostly changes to domintro and PR description). Also added a WPT for cloning the sanitizer config (https://github.com/web-platform-tests/wpt/pull/62484)

[04:22:04.0799] <Noam Rosenthal>
* OK fixed those issues (they're mostly changes to domintro and PR description to reflect the most recent changes). Also added a WPT for cloning the sanitizer config (https://github.com/web-platform-tests/wpt/pull/62484)


2026-09-07
[00:49:40.0282] <Tobie Langel>
hey folks, pr-preview is back up, but I need you to issue new AWS credentials for the S3 bucket that's behind whatpr.org

[00:53:01.0841] <Tobie Langel>
And I realize this could look like social engineering to fish for credentials, so I'll ask whoever is able to get them to reach me using another channel.

[00:53:17.0398] <zcorpan>
foolip: ^

[00:53:52.0791] <Tobie Langel>
(I believe at least annevk has my phone number.)

[00:56:35.0967] <foolip>
I will forward this to the person now paying for the S3 bucket.

[00:59:00.0729] <Tobie Langel>
In the meantime, I can put you back on the main one. What do you prefer?

[01:04:32.0548] <Tobie Langel>
* In the meantime, I can put you back on the main S3 bucket. What do you prefer?

[01:04:58.0162] <annevk>
I think we can wait until this is fixed. Tantek has access to the account.

[01:05:13.0574] <annevk>
cc Tantek 

[01:08:27.0192] <Tobie Langel>
Sorry this whole thing took so long. Timing of the outage couldn't have been worse on my end.

[01:13:31.0854] <annevk>
Luke Warlow freddy Frédéric: when I looked through https://github.com/w3c/trusted-types/pull/606 it largely seemed fine, but I was curious what you all think about these things:

1. Should it be `TrustedHTMLParserOptions` instead of `TrustedParserOptions`?
2. Why do we make these `TrustedX` objects reflect their internal state (in a way consumers cannot trust)? I'm not really sure I see the point in `toJSON()` and `sanitizer()` and such, but I guess it also doesn't really matter.

[01:14:50.0221] <Tobie Langel>
The apps are now hosted with a new service provider and the repos are in a dedicated GH org.

[01:15:35.0530] <Tobie Langel>
It would be good to discuss longer terms plans for these services once the outage is fully behind us.

[01:16:30.0491] <Tobie Langel>
W3C offered to take over Specref but seems only mildly interested in supporting PR Preview long term.

[01:17:50.0153] <Ms2ger>
That's too bad

[01:23:41.0965] <annevk>
Tobie Langel: no worries, hope all is well! And yes, figuring out a longer-term plan would be good. I wonder if we can migrate it to CI somehow. (For which we don't really have a sustainable solution either, but it's unlikely it'll completely disappear.)

[01:25:42.0347] <zcorpan>
annevk: empty `poster` was discussed in https://github.com/whatwg/html/issues/6636#issuecomment-2610027765 + next few comments. Do you think the feature-testing by `currentPoster` changes it enough to reconsider empty `poster`?

[01:35:14.0967] <annevk>
Yeah, Jake Archibald pointed that out at the time too. I don't think we gave it enough consideration. Interesting to see that even `<poster>` was considered.

[01:36:00.0949] <Luke Warlow>
1. I guess it depends what the future plans with XML are. I think leaving it as just TrustedParserOptions is probably fine, but not strong either way.

2. I agree they seem largely pointless but also it's already there on the existing interfaces and I don't think it matters too much. Nic opened an issue around making them immutable in some way.

[01:37:25.0520] <zcorpan>
Can you comment in https://github.com/whatwg/html/issues/10378 ?

[02:07:39.0338] <Noam Rosenthal>
cannot trust because someone can mangle the prototypes?

[02:16:01.0101] <Noam Rosenthal>
I also don't mind removing the API for now. It's easier to add it later than to remove it

[02:21:45.0745] <Noam Rosenthal>
Perhaps `TrustedHTMLParserOptions` is more explicit about it currently not supporting XML... I don't mind changing it

[02:24:09.0783] <annevk>
Yes prototypes can be mangled. If nicolo-ribaudo wants them trusted it’s probably better to not expose anything for now.

[02:43:17.0071] <Noam Rosenthal>
renamed to TrustedHTMLParserOptions without members. We can add interface members for it in the future after we figure out the mangling thing for `TrustedHTML`

[03:05:33.0216] <smaug>
zcorpan: annevk remind me, where are we with ORB and getting that to the spec?

[03:27:05.0304] <zcorpan>
smaug: https://github.com/whatwg/fetch/pull/1755 needs an edit to HTML. I can try to fix it this week

[03:30:09.0404] <zcorpan>
smaug: that also links to https://github.com/annevk/orb/labels/mvp

[04:44:51.0377] <Tobie Langel>
https://lists.w3.org/Archives/Public/spec-prod/2026JulSep/0006.html

[04:46:33.0965] <Tobie Langel>
Update to the specprod mailing list and link to the  GH issues on deciding what's next long term for these services.

[05:04:18.0587] <annevk>
smaug: I think Google & Mozilla ended up not quite following the specification and nobody wrote up what you all did instead?

[05:06:50.0205] <Tobie Langel>
FYI, it sounds like W3C is planning to host their own PR Preview moving forward: https://github.com/specinfra/pr-preview/pull/209

[05:53:43.0418] <smaug>
farre might be able to tell all the required tweaks (required because of webcompat)

[05:56:17.0406] <farre>
yep, I should be able to assist


2026-09-08
[07:07:43.0938] <smaug>
How should one interpret https://html.spec.whatwg.org/#active-parser "has not yet been stopped ". That stopped is a long algorithm spinning event loop and what not. Does "stopping" happen when that algorithm is about to be called, is being called or has been called?

[07:09:28.0234] <sfarre>
and follow up, sort of related question to ^ - if we have a page whose load event has not been fired yet, we navigate away, then back, restore from bfcache, should the load event be fired then?

[07:18:01.0164] <sfarre>
what I am referring to here, is an example where chrome puts a page in bfcache before the load event, and upon restore, does not fire a load event

[07:23:18.0904] <annevk>
I suspect instrumenting Claude with that question and telling it to write a bunch of tests would be a good start to figuring out what the solution will have to look like. These definitions are probably Hixie-era. (Looking at blame and trying to figure out what Hixie modeled it after might also give some clues.)

[07:23:51.0856] <sfarre>
It was that, that led me here :)

[07:24:14.0832] <sfarre>
```python
#!/usr/bin/env python3
"""
Serve two pages to manually test BFCache with a static in-flight image.

Usage:
    python3 bfcache-static-img-test.py

Open http://localhost:8383/page1, click the link to page2, then press Back.
The page will show whether it was restored from BFCache.
"""

import http.server
import struct
import time
import zlib

PORT = 8383


def make_png(width=128, height=128):
    def chunk(ctype, data):
        c = ctype + data
        return struct.pack(">I", len(data)) + c + struct.pack(">I", zlib.crc32(c) & 0xFFFFFFFF)
    raw = b""
    for y in range(height):
        raw += b"\x00" + b"\xff\x00\x00" * width
    return (
        b"\x89PNG\r\n\x1a\n"
        + chunk(b"IHDR", struct.pack(">IIBBBBB", width, height, 8, 2, 0, 0, 0))
        + chunk(b"IDAT", zlib.compress(raw))
        + chunk(b"IEND", b"")
    )


IMAGE_PNG = make_png()

PAGE1 = b"""\
<!DOCTYPE html>
<html>
<head><title>Page 1 - static image loading</title></head>
<body>
<p>readyState: <span id="rs"></span></p>
<div id="result"></div>
<img src="/slow-image">
<p><a href="/page2">Navigate to page 2</a></p>
<script>
const rs = document.getElementById('rs');
const update = () => rs.textContent = document.readyState;
update();
document.onreadystatechange = update;

window.addEventListener('load', () => {
  document.getElementById('result').textContent += 'load event fired\\n';
});

window.addEventListener('pageshow', e => {
  if (e.persisted) {
    document.getElementById('result').textContent += 'RESTORED FROM BFCACHE\\n';
    document.getElementById('result').style.cssText =
      'background:green;color:white;padding:1em;font-size:1.5em';
  }
});
</script>
</body>
</html>
"""

PAGE2 = b"""\
<!DOCTYPE html>
<html>
<head><title>Page 2</title></head>
<body>
<p>Now press Back.</p>
</body>
</html>
"""


class Handler(http.server.BaseHTTPRequestHandler):
    def do_GET(self):
        if self.path == '/page1':
            self.send_response(200)
            self.send_header('Content-Type', 'text/html')
            self.send_header('Content-Length', str(len(PAGE1)))
            self.end_headers()
            self.wfile.write(PAGE1)
        elif self.path == '/page2':
            self.send_response(200)
            self.send_header('Content-Type', 'text/html')
            self.send_header('Content-Length', str(len(PAGE2)))
            self.end_headers()
            self.wfile.write(PAGE2)
        elif self.path == '/slow-image':
            self.send_response(200)
            self.send_header('Content-Type', 'image/png')
            self.send_header('Content-Length', str(len(IMAGE_PNG)))
            self.send_header('Cache-Control', 'no-store')
            self.end_headers()
            self.wfile.flush()
            print('  [slow-image] headers sent, stalling 120s...')
            time.sleep(10)
            self.wfile.write(IMAGE_PNG)
            print('  [slow-image] body sent')
        else:
            self.send_response(404)
            self.end_headers()

    def log_message(self, fmt, *args):
        print(f'  {fmt % args}')


if __name__ == '__main__':
    server = http.server.ThreadingHTTPServer(('127.0.0.1', PORT), Handler)
    print(f'http://localhost:{PORT}/page1')
    try:
        server.serve_forever()
    except KeyboardInterrupt:
        print()

```

simple python example 

[07:24:53.0935] <sfarre>
and i am expanding gecko behavior and realized I was also doing what chrome was doing, but I am not sure if thats right. dropping a load event seems iffy

[07:27:31.0582] <annevk>
So what I would do is find more cases where this is observable and make sure you have tests for all of them. Then contemplate what (a) good model(s) would look like and judge how likely they are/that is to be web-compatible and how it/they would fare against all the tests.

[07:28:18.0579] <smaug>
yeah, some .tentative tests would be good. 

[07:28:32.0283] <Noam Rosenthal>
smaug: I read it as the first line of stopping/aborting the parser is to make it "not active". From a quick glance at the code that's what blink does

[07:28:38.0026] <smaug>
(not firing load event at all does feel like a major bug)

[07:28:44.0946] <Noam Rosenthal>
* smaug: I read it as the first line of stopping/aborting the parser is to make it "not active". From a quick glance at the code that's what blink does but it's complex enough to miss some cases

[07:30:55.0077] <sfarre>
ok, I have a bunch of bfcache tests written, I'll make them tentative wpt instead of gecko local only and I'll see if I can whip up a tentative test for this as well

[07:35:42.0060] <annevk>
sfarre: sounds good; and link them from a specification issue. And if you're interested in taking it even further and proposing changes, that'd be most welcome too.

[07:43:40.0514] <sfarre>
thanks, I'll do that

[07:58:11.0776] <Noam Rosenthal>
https://github.com/whatwg/html/commit/0d896522e78a705d7a86563f71bd424ae037d495#diff-1bc04b5291c26a46d918139138b992d2de976d6851d0893b0476b85bfbdfc6e6R2659-R2672 has more of a note about it


2026-09-09
[04:43:31.0679] <sfarre>
filed https://github.com/web-platform-tests/wpt/pull/62562 that requires static page serving thingy, but there's a test after that, that does the explicit bfcache load event thingy, the remainder of the bfcache tests I have, will be upstreamed as they don't require that static page serving thing for remote context helper

[04:50:40.0107] <sfarre>
* filed https://github.com/web-platform-tests/wpt/pull/62562 that requires static page serving thingy, but there's a test after that, that does the explicit bfcache load event thingy, the remainder of the bfcache tests I have, will be upstreamed as they don't require that static page serve feature 

[06:54:04.0935] <Luke Warlow>
https://wpt.live:8443/html/dom/partial-updates/tentative/ - should these tests not be moved up a layer and the tentative gotten rid of at this point? Or are these tests for something not in the spec yet?

[06:55:42.0909] <Luke Warlow>
* https://wpt.live:8443/html/dom/partial-updates/tentative/ - should these tests (or at least some of them) not be moved up a layer and the tentative gotten rid of at this point? Or are these tests for something not in the spec yet?

[08:35:10.0380] <Shannon Booth>
could someone please send me invite to the whatnot tomorrow?

[13:57:45.0198] <Dominic Farolino>
There's no precedent for `optional any foo = {}`, but it's valid, right?

[14:05:51.0295] <Shannon Booth>
I was inclined to say yes, but I think webidl technically says no

> That type must be a dictionary type, or a union type that has a dictionary type in its flattened member types

[14:07:04.0304] <Shannon Booth>
actually, im wrong, thats in union

[14:07:06.0953] <Shannon Booth>
so yes

[14:15:46.0109] <Dominic Farolino>
Can you clarify? `any` is not a union type, so "or a union type that has a dictionary type in its flattened member types" does not apply, right?

[14:20:25.0952] <Dominic Farolino>
Oh nvm TIL that `any` is a union type...

[14:21:09.0288] <Shannon Booth>
Yeah this is my confusion atm and my double take. I guess it's not UnionType in grammar? But it does say it's union of all other values, which does make sense

[14:26:26.0428] <Shannon Booth>
Ah, okay, now I'm more sure that it's technically not allowed, since it doesn't count towards the flattened member types

[14:27:34.0267] <Shannon Booth>
> The any type must not be used as a union member type.

Specifically is what made me more confident in that

[14:28:44.0477] <Dominic Farolino>
That just means that you can't do `typedef Foo (any or SomethingElse)`

[14:28:55.0509] <Dominic Farolino>
Because `any` would be an (illegal) member type.

[14:29:29.0045] <Dominic Farolino>
But I think `any` is still a union type (not a member of a wider union type) which includes the "dictionary type", and thus can accept ` = {}` as a valid default value.


2026-09-10
[23:05:57.0909] <Tim van der Lippe>
annevk: do you mind considering https://github.com/whatwg/html/pull/12761#issuecomment-5284825193 ? E.g. we add more WPT tests that assert that certain CSS properties have specific colors.

[23:06:23.0387] <Tim van der Lippe>
Also looking for CSP reviewer for small fix in https://github.com/w3c/webappsec-csp/pull/821 which was necessary to get Servo to pass all CSP blob tests

[01:18:26.0730] <annevk>
What's different between optional any and just any? There shouldn't be a difference.

[01:19:24.0465] <annevk>
I guess whether the argument is required. Hmm. But I'm not sure we want to require an argument that accepts undefined.

[01:30:34.0046] <zcorpan>
It affects `.length` right?


2026-09-11
[08:30:34.0477] <Tobie Langel>
Hi folks, as a heads-up, no one has contacted me with the new credentials for PR Preview. What'

[08:30:50.0193] <Tobie Langel>
* Hi folks, as a heads-up, no one has contacted me with the new credentials for PR Preview. What's the plan, here?

[08:44:38.0104] <annevk>
Thanks for the reminder. I emailed Tantek 

[09:17:45.0246] <Tobie Langel>
Got it, thanks!


2026-09-12
[01:58:53.0598] <annevk>
👋 PR Preview should be back up, but there might be some issue still with the HTML standard. Please let me know if you see anything weird. (It works for the multipart/form-data PR at least: https://github.com/whatwg/fetch/pull/1922.)


2026-09-13
[12:33:03.0769] <nektro>
gentle ping for https://github.com/whatwg/html/issues/9986


2026-09-14
[01:00:17.0987] <annevk>
Dominic Farolino: when will you get back to the base URL PRs? I'd like to land them. The tests have been reviewed.

[01:07:11.0745] <annevk>
keithamus: are you still planning to complete https://github.com/whatwg/html/pull/12893?

[01:18:48.0119] <keithamus>
Yeah I’ll complete it today

[02:51:00.0792] <annevk>
zcorpan: could you review https://github.com/whatwg/html/pull/12936? It fixes a regression from the customizable select work. All boxes ticked. cc jarhar 

[04:01:01.0756] <annevk>
Tobie Langel: judging based on the above PR it seems that PR Preview works for HTML as well. No outstanding issues as far as I'm aware. 🎉

[08:43:59.0091] <annevk>
emilio Jake Archibald: are you all no longer pursuing the `:hover` & top layer change?

[09:04:51.0817] <emilio>
annevk: yeah, I plan to put something up, just haven't had the time for it yet

[09:34:59.0918] <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/12900