Repository navigation
HTML fragment parsing algorithm needs to set its document's custom element registry #12209
Closed as not planned
Description
What is the issue with the HTML Standard?
Specifically, in the HTML fragment parsing algorithm, step 1 creates a temporary Document "document", that is used for parsing.
- Let document be a Document node whose type is "html".
By default its custom element registry is null. I believe it should be set here to the context element's document's custom element registry.
The effect of not doing this, is that when created elements get adopted into document, step 3.1.3.2 of adopt node overwrites it:
- If inclusiveDescendant’s custom element registry is null or inclusiveDescendant’s custom element registry’s is scoped is false, then set inclusiveDescendant’s custom element registry to document’s effective global custom element registry.
The document here is document, which as explained above has a null custom element registry, so the element's gets set to null too. If document has the same registry as the "real" document, then this functions as expected instead.
Activity
AtkinsSJ commentedon Feb 27, 2026
See also: #12213 for a similar case of ending up with a null registry.
noamr commentedon Mar 4, 2026
I don't think this is right, or I'm misunderstanding something.
At some point, the node is going to be adopted into the "real" document/tree-scope which has a real custom element registry.
Setting a custom element registry on the inert document would make it so that, for example, custom element constructors would be called as a result of
createContextualFragment.keithamus commentedon Mar 9, 2026
I'm a little confused because my initial interpretation would be that fragment parsing should not have a custom element registry to keep elements from being upgraded during fragment parsing.
But then @AtkinsSJ expects differently:
Fragment parsing step 7. already says "and context's custom element registry.", so it seems this is per your expectations?
Did this change between you filing this issue and today? Perhaps @annevk has some context here.
AtkinsSJ commentedon Mar 10, 2026
OK. I need to check again what issue I was having and get more details, because it makes sense that they shouldn't get upgraded until they're added to the real document. I wish I'd added a small repro case. 😅
If I remember right the problem was that if the element already has a registry, this step erases it, and then it never gets set again when attached to the real document. But I may have that wrong.
AtkinsSJ commentedon Mar 25, 2026
Coming back to this now, and sorry for anything I'm muddling up because I do not find these algorithms easy to wrap my head around. 😅
Yeah I'm wrong with my solution here. I had originally been debugging a regression on a Friday afternoon, finally found something that seemed to make sense and fix it, and reported it. But I clearly had that a bit wrong. The regression I was seeing without this is in https://wpt.live/custom-elements/builtin-coverage.html : all of the
ELEMENT: innerHTML should instantiate a customized built-in elementtest cases fail, with the element not getting upgraded:And, I think I figured out the actual issue! And, it's already been fixed, but I missed it when I last checked for spec changes. 😆
Adopt node, step 3.1.3.2 didn't check for element having a
nullCER before, but now does. That solves the problem. It does create some other failures, for example the two last subtests of https://wpt.fyi/results/custom-elements/registries/Element-innerHTML.html?label=experimental&label=master&aligned which Safari fails, also fail because of that null check. But that's a separate thing. I'll close this now.