What is the input **representation**, an opaque *string + format/`mimeType` tag*, or a *structured DOM-to-DOM* transform?

[toreini]

From #60, The real disagreement

Group members: please +1/-1 for each so we can gauge consensus.

[toreini]

Decision 1: Should the plain text be the default?

Proposal: Yes, the plain text should be the specified default, explicitely with no transformation When input is treated as plain text, the API does not escape, sanitize, or otherwise transform it. This directly addresses the concern raised in-thread that a string like Is Foo / Bar > Alice & Bob? must round-trip untouched (output may be destined for a form field, not the DOM). This also just writes down today's behavior.

[toreini]

Decision 2: How is rich text handled?

Proposal: Rich text via a structured DOM-to-DOM transform (opt-in), with a preservation invariant. Adopting the direction @jakearchibald proposed. The transform:

• operates on structured input and returns structured output of the same shape;
• translates text nodes and a spec-defined allow-list of human-readable attributes (candidate set: title, aria-label, aria-description, alt, placeholder, label, to be finalised);
• must not create, rename, or remove elements, and must not alter non-human-readable attributes (class, id, data-*, URLs, event handlers);
• defines behavior for the edge cases @jakearchibald flagged: input/textarea values, pseudo-element content (not in the DOM), and shadow DOM.

because the UA reconstructs known structure and only substitutes text/allow-listed values, it never introduces new markup, which removes the XSS surface at the API level rather than delegating sanitization to every caller. This is why this decision point is preferred over "HTML string in, HTML string out" on the safety and interop criteria, and aligns with the TAG's guidance to prefer higher-level APIs where the UA can intervene for safety/accessibility (Design Principles §2.2) and to limit consequences at the API level first (§1.4.1).