Intent to Ship: Renewed HTML insertion&streaming methods

[Chromestatus]

Contact emails

nrose...@chromium.org, foo...@chromium.org

Explainer

https://github.com/WICG/declarative-partial-updates/blob/main/dynamic-markup-revamped-explainer.md

Specification

https://github.com/WICG/declarative-partial-updates/blob/main/dynamic-markup-revamped-explainer.md#resulting-api

Summary

Expose multiple HTML setting methods that provide a coherent story for dynamically inserting markup into an existing document. - Positional methods (before/after/append/prepend/replaceWith) that take HTML as argument, effectively replacing insertAdjacentHTML. - Streaming methods (stream{Append}HTML{Unsafe}) which return a WritableStream - Passing {runScripts} as part of SetHTMLUnsafeOptions, mimicking createContextualFragment behavior. - Supporting createParserOptions in trusted types, allowing trusted types to override scripting mode and sanitizer.

Blink component

Blink>HTML>Parser

Web Feature ID

Missing feature

Motivation

Updating HTML dynamically from script has multiple disjointed API, each with its own subtle differences. Developers can partially update an element using insertAdjacentHTML, use sanitizer with setHTML, execute scripts with createContextualFragment, stream with detached documents. This can be confusing and frustrating to web developers, as well as create bugs or security issues if the differences are not well understood. This change replaces those with a coherent set of methods and arguments, that use the same settings (sanitizer/runScripts) with different variants (where to insert the HTML, stream/one-shot, safe/unsafe) as well as the same support in trusted types.

Initial public proposal

https://github.com/whatwg/html/issues/11669

TAG review

No information provided

TAG review status

Issues addressed

Goals for experimentation

None

Risks

Interoperability and Compatibility

See "anticipated spec changes". Because this is not fully standardized yet, there is some risk that some of the API will change between shipping and landing the standards change. Note that the proposed API was up for scrutiny for almost a year and hasn't gone through substantial changes.

Gecko: No signal (https://github.com/mozilla/standards-positions/issues/1370) (It's in "suggests positive" state)

WebKit: No signal (https://github.com/WebKit/standards-positions/issues/629) Note: WebKit folks have been active in the feature's design, despite not filing an official positive position yet.

Web developers: Positive (https://github.com/whatwg/html/issues/2142) See also https://github.com/whatwg/html/issues/10122

Other signals:

Security

Since this is about dynamic markup insertion, XSS needs to be carefully handled, and specifically integration with the sanitizer and trusted types. This has been a major design consideration.

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

No information provided

Debuggability

No information provided

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?

Yes

Is this feature fully tested by web-platform-tests?

Yes
https://wpt.fyi/results/domparsing/tentative?label=master&label=experimental&aligned

Flag name on about://flags

No information provided

Finch feature name

NewHTMLSettingMethods

Rollout plan

Will ship enabled for all users

Requires code in //chrome?

False

Tracking bug

https://issues.chromium.org/issues/491743369

Adoption plan

A fully functional polyfill is already available at https://github.com/GoogleChromeLabs/html-setters-polyfill

Estimated milestones

Shipping on desktop	152
DevTrial on desktop	148
Shipping on Android	152
DevTrial on Android	148
Shipping on WebView	152

Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).

Nothing, I hope, but this is in the process of being upstreamed. So it's possible that some changes will be made after shipping. The comments on this is in recent weeks were quite on the cosmetic side, around the trusted-types integration.

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5054329641893888?gate=5996320374521856

This intent message was generated by Chrome Platform Status.

[Noam Rosenthal]

Two followup notes:
- We (as in Barry) have filed for a new Web Feature ID (https://github.com/web-platform-dx/web-features/issues/4117)
- The standardization upstreaming is tracked in this meta-issue: https://github.com/whatwg/html/issues/11669.
  It contains 5 sub-issues: one has landed, two have pending PRs, and the rest are waiting on those pending items.

  The PRs for this feature are stacked at the request of the reviewers.