WHATWG
2026-07-06
plaintext logs
prev next
source on github
02:22
<Psychpsyo>

Thought I'd share this here: A while ago I wrote a user script (I use it through tampermonkey) that inserts the section name you're on into the tab title on any WHATWG specs:

// ==UserScript==
// @name         Web Spec Title Machine
// @version      2026-02-26
// @description  current section of web specs in the page title
// @author       Psychpsyo
// @match        https://*.spec.whatwg.org/*
// @grant        none
// ==/UserScript==

const titleElem = document.querySelector("title");
const originalTitle = titleElem.textContent;

function putFragmentIntoTitle() {
    if (location.hash) {
        titleElem.textContent = `${location.hash} - ${originalTitle}`;
    } else {
        titleElem.textContent = originalTitle;
    }
}
putFragmentIntoTitle();

window.addEventListener("hashchange", putFragmentIntoTitle);
02:26
<Psychpsyo>
I wish
07:45
<annevk>
Noam Rosenthal: I'm making more changes to your refactor PR, still quite a bit was wrong
07:46
<annevk>
Noam Rosenthal: I realized that Document.parseHTML() and friends also have to continue to change the document state as otherwise we are impacting what a subsequent open() call would do.
07:56
<annevk>
Okay, I think it's good now but maybe Shannon Booth can have another look. Another thing I wanted to do once this lands is to turn concept-frag-parse-context into a "fragment context" concept that the parser holds. Then the parser can also branch on that (non-null) to detect if it's doing fragment-based parsing.
08:09
<Noam Rosenthal>
Noam Rosenthal: I realized that Document.parseHTML() and friends also have to continue to change the document state as otherwise we are impacting what a subsequent open() call would do.
Ah yes of course. I am going to open an issue to change this behavior so it only relies on the parsing method rather than on something that sticks to the document
08:11
<Noam Rosenthal>
Okay, I think it's good now but maybe Shannon Booth can have another look. Another thing I wanted to do once this lands is to turn concept-frag-parse-context into a "fragment context" concept that the parser holds. Then the parser can also branch on that (non-null) to detect if it's doing fragment-based parsing.
Yea I was thinking the same about the context. I have a few pending PRs but after that I want to make the whole parser instance modern including that
13:06
<smaug>
annevk: FWIW, the reason I haven't looked at https://github.com/whatwg/dom/pull/1470 is that I've been waiting for a proper proposal for the whole thing, I mean OpaqueRange
13:14
<annevk>
smaug: happy to wait. I have the HTTP Workshop next week and then vacation so I won't be able to work on it until mid-August anyway.
14:24
<Noam Rosenthal>
I'd say customElementRegistry was more like speculative polyfilling where a userland feature was made to look like a prospective future standard, no? Rather than an actual polyfill of something that's spec'ed but not yet baseline?
14:25
<Noam Rosenthal>
It would be good to have some guidelines/postmortem about it with examples. Perhaps a good TPAC conversation
17:33
<sirreal>

👋 I've been looking at parsing Processing Instructions an have a few notes/questions:

  • I notice that the processing instruction token is not handled in the "in head noscript" insertion mode, unlike most other modes where it seems to align with comment tokens. Is that intentional?
  • The fragment serialization for PI is potentially lossy: <?pi d??> has data d?. Following the serialization instructions would produce <?pi d?> (> is the serialization closer, not ?>) which now has the data d.
17:36
<sirreal>
Happy to open issues for either of these if neceesary.
17:42
<sirreal>
Related, I opened a WPT PR for the PI node tree construction tests because I noticed the recently added tests do not follow the specified format. Since either the specified format or the tests need to be updated, it seems like there's an opportunity to update the WPT format for PI. Comments appear as <!-- + comment text + --> - they always have a space inside the comment open/close. PI nodes could serialize this way as well in the tree construction tests, for example <? + target + + data + ?>. I like the alignment with comments, and it helps to make it clear what's data and what is part of the tree syntax, like in the case above with the ??> closers.
17:57
<sirreal>
For the "in head noscript" insertion mode, this would fall through to the anything else clause, effectively moving into "in head" and inserting the PI.
18:06
<sirreal>
Processing instruction tokens are also missing from the "in template" insertion mode.
In that case, there's no "anything else" clause, PI tokens just aren't handled.
I suppose PI in templates should be handled the same a comment and "Process the token using the rules for the 'in body' insertion mode."
18:59
<bkardell (out part of monday)>
I'd say customElementRegistry was more like speculative polyfilling where a userland feature was made to look like a prospective future standard, no? Rather than an actual polyfill of something that's spec'ed but not yet baseline?
Yea