Preserve character data and handle void elements in innerHTML parsing

[olavoasantos]

Problem

The limited innerHTML parser discarded literal ampersands, did not decode character references, and stored encoded attribute values such that serialization could escape them again. It also treated HTML void elements as normal parents, nesting following content beneath them and emitting invented closing tags.

Impact

Important. Ordinary valid HTML assigned through the exposed innerHTML path could lose text data, produce a different tree, or serialize to different markup. In a worker-side Remote DOM tree, that means consumers can make decisions from content that does not match the markup they assigned.

Reproduction

const element = document.createElement('div');

element.innerHTML = '<p>Fish & chips</p><img src="logo.png"><p>After</p>';

Before this change, the literal & was dropped and the second paragraph was parsed beneath img, which was serialized with a closing tag. It now retains Fish & chips, keeps img and both paragraphs as siblings, and serializes the void element as <img src="logo.png">.

Change

• Decode the parser's supported named and numeric character references while preserving literal ampersands and unrecognized references.
• Decode attribute references before storing them so serialization escapes the value once.
• Keep tokenizers local to each parse call, preventing nested innerHTML parsing from corrupting an outer parse.
• Treat the defined HTML void-element set as childless during parsing and serialization.

This is a targeted correction to the existing limited parser, not browser-grade entity coverage or malformed-markup recovery.

Tests

Adds packages/polyfill/source/tests/inner-html-parsing.test.ts, covering literal ampersands; the supported named, decimal, and hexadecimal references; attribute round-tripping; reentrant parsing from an attribute callback; void-element sibling structure; self-closing void syntax; and closing-tag omission for every supported HTML void element.

Stack

• Stack: HTML serialization (#701), layer 1 of 3
• Base: normalize-dom-namespaces
• This is the bottom of its stack.
• This stack depends on Core foundation PR Normalize DOM names and attribute namespaces #677.

Validation

Fresh GitHub CI on restacked head 1b7881e passes:

• lint;
• type-check and build;
• unit tests with coverage;
• bundle-size checks;
• Playwright end-to-end tests;
• the classified Web Platform Test suite.

[henrytao-me]

The parser and reentrancy fixes check out. I found two focused corrections when comparing native Chrome 152, the namespace base, and head 1b7881e:

1. Classify void elements by namespace and exact local name

The new serialization check drops children based only on a lowercased qualified name:

const node = document.createElementNS('urn:widget', 'input');
node.append('must survive');
node.outerHTML;

• Native and base: <input>must survive</input>.
• This PR: <input>.

The same introduced content loss affects HTML-namespace elements created with established local names INPUT or Input; native preserves their children. Conversely, the name-only check misses a prefixed HTML void element such as h:br (that variant was already incorrect on the base).

Could we use one element-aware predicate for both parsing and serialization?

function isVoidElement(element: Element) {
  return (
    element.namespaceURI === HTML_NAMESPACE &&
    VOID_ELEMENTS.has(element.localName)
  );
}

Pass the created node during parsing and the element during serialization. createElement() already normalizes parsed HTML names, so the predicate doesn't need to lowercase established DOM names.

Please add regression coverage for foreign-namespace input/br/source, HTML-namespace INPUT/Input, and prefixed HTML h:br, alongside the existing lowercase HTML void cases.

2. Preserve unrecognized named-entity spellings

The decoder's /gi matching and toLowerCase() accept spellings that aren't HTML character references:

const element = document.createElement('div');
element.innerHTML = '<p>&aMp; &APOS;</p>';
element.textContent;

• Native: &aMp; '.
• This PR: & '.

Please match the exact supported named spellings and leave unknown ones literal. Include valid uppercase aliases such as & explicitly rather than accepting arbitrary casing; retain case-insensitive hexadecimal digits independently. Add text and attribute cases for these spellings.

This second issue is a gap in the new decoder, not a claim that the base handled these inputs correctly (it dropped their ampersands). Neither correction requires expanding this into a browser-grade parser.

[marvinhagemeister]

Nit: Hoisting regexes out of hot functions is typically good for perf.

[olavoasantos]

yea, hoisted the tokenizer regexes and switched the loops to matchAll() so the global regex state remains isolated during reentrant parsing.

[olavoasantos]

Fixed both. Void classification now uses the element namespace and exact localName, so foreign and established mixed-case elements keep their children while prefixed HTML void elements still use their local name. Named references now match only the exact aliases we support; arbitrary casing stays literal while hexadecimal digits remain case-insensitive.