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).

Uh oh!

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

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

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