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.

[Dan Clark]

Thanks for working to make this into a consistent API surface!

This seems like something the TAG should have a chance to look at, would you mind filing a TAG review?

After scanning through https://github.com/whatwg/html/issues/11669 and the sub-issues I'm still uncertain on where we're at with the state of the spec work. You mentioned that the PRs are stacked per reviewer request and some are still waiting, but does complete spec text exist somewhere for all of these APIs? Or does some still need to be written, pending completion of earlier PRs? For spec PRs still open, what needs to happen for them to land?

Thanks,

Dan

[Noam Rosenthal]

On Mon, Jul 20, 2026 at 8:03 PM 'Dan Clark' via blink-dev <blin...@chromium.org> wrote:
>
> Thanks for working to make this into a consistent API surface!
>
> This seems like something the TAG should have a chance to look at, would you mind filing a TAG review?

This was discussed at part of out-of-order streaming before it was split out to a separate feature
https://github.com/w3ctag/design-reviews/issues/1134#issuecomment-3357614978 (your own comment :))
I've read that discussion as a go ahead to continue working on the details at WHATWG, but I'm happy to interpret it differently.

There was not much change to the API since that discussion, perhahps some nits around how this works with trusted types.

> After scanning through https://github.com/whatwg/html/issues/11669 and the sub-issues I'm still uncertain on where we're at with the state of the spec work. You mentioned that the PRs are stacked per reviewer request and some are still waiting, but does complete spec text exist somewhere for all of these APIs? Or does some still need to be written, pending completion of earlier PRs? For spec PRs still open, what needs to happen for them to land?

There are two HTML PRs waiting to be merged.
https://github.com/whatwg/html/pull/12583 (trusted types support)
https://github.com/whatwg/html/pull/12645 (sanitize while parsing)

On top of them there are going to be two PRs. Draft versions of both exist in isolation but they would all need to be rebased on top of the stack:
https://github.com/whatwg/html/pull/12528 (positional methods to replace insertAdjacentHTML)
https://github.com/whatwg/html/pull/11631 (streamHTML*)

Nothing in particular is preventing these PRs from merging, apart from the HTML standard editors' workload (and summer holidays).

As always, unforeseen issues can arise during the review.

Waiting for more upstreaming is one reasonable decision, shipping and adjusting later if needed is also a possible one.

I'm laying out the trade offs here and we can all make a decision :)

[Daniel Clark]

> This was discussed at part of out-of-order streaming before it was split out to a separate feature
> https://github.com/w3ctag/design-reviews/issues/1134#issuecomment-3357614978 (your own comment :))
> I've read that discussion as a go ahead to continue working on the details at WHATWG, but I'm happy to interpret it differently.

> There was not much change to the API since that discussion, perhahps some nits around how this works with trusted types.

 

I forgot that we'd looked at these as part of that review. :) I think that suffices for TAG then if there haven't been major changes since.

 

Thanks for clarifying the state of the spec PRs. In general I think it’s reasonable that not all the spec PRs be fully landed if there’s been an opportunity for review and all the known issues have been addressed.

A concern I have in this case though is that since some of the PRs are still in draft status due to the dependencies on the first round, it’s not clear the extent that they’ve really had thorough review from everyone that might be interested.

E.g. AnneVK has looked at https://github.com/whatwg/html/pull/11631, but it doesn’t seem like someone from Gecko has, and I don’t see any indication that https://github.com/whatwg/html/pull/12528 has been looked at. And those two PRs are the ones that contain the actual API surface that we’d be baking into the platform.

 

I’d have more confidence about moving forward here if we could at least get the first round landed so that the remaining PRs can get rebased and moved out of draft status so they can get a more formal round of review.

 

-- Dan

[Rick Byers]

We discussed this in the API owners meeting right now. While we are comfortable shipping prior to the PR landing in HTML, it looks like the PRs are still marked as draft and so not officially requesting review yet, right? We're worried that may mean people don't realize that their window for providing feedback may be closing. Noam / Philip, can you set the PRs to officially be requesting review? 

Rick

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/DS0PR00MB2527596D5A57235166CECBB5C5C12%40DS0PR00MB2527.namprd00.prod.outlook.com.

[Noam Rosenthal]

On Wed, Jul 29, 2026 at 4:33 PM Rick Byers <rby...@chromium.org> wrote:
>
> We discussed this in the API owners meeting right now. While we are comfortable shipping prior to the PR landing in HTML, it looks like the PRs are still marked as draft and so not officially requesting review yet, right? We're worried that may mean people don't realize that their window for providing feedback may be closing. Noam / Philip, can you set the PRs to officially be requesting review?

The main reason they are in draft is that they require rebasing on top
of the currently non-draft PRs and github doesn't have the concept of
"stacked PRs".
Since we passed the M152 deadline anyway and reviewers from other
browsers are OOO, I suggest I'll allow some time for review once they
return. If it's still delayed then, I will post one non-draft PR that
includes all of these together and we can re-assess.

Does that make sense?

[Rick Byers]

On Wed, Jul 29, 2026 at 12:12 PM Noam Rosenthal <nrose...@chromium.org> wrote:

On Wed, Jul 29, 2026 at 4:33 PM Rick Byers <rby...@chromium.org> wrote:
>
> We discussed this in the API owners meeting right now. While we are comfortable shipping prior to the PR landing in HTML, it looks like the PRs are still marked as draft and so not officially requesting review yet, right? We're worried that may mean people don't realize that their window for providing feedback may be closing. Noam / Philip, can you set the PRs to officially be requesting review?

The main reason they are in draft is that they require rebasing on top
of the currently non-draft PRs and github doesn't have the concept of
"stacked PRs".

Ah interesting, thanks for explaining.

 

Since we passed the M152 deadline anyway and reviewers from other
browsers are OOO, I suggest I'll allow some time for review once they
return. If it's still delayed then, I will post one non-draft PR that
includes all of these together and we can re-assess.

That sounds good. As long as it's clear people were aware that we were looking for review and gave a week or more for discussion, then I am fine with proceeding with shipping in parallel.

[Noam Rosenthal]

>>
>> Since we passed the M152 deadline anyway and reviewers from other
>> browsers are OOO, I suggest I'll allow some time for review once they
>> return. If it's still delayed then, I will post one non-draft PR that
>> includes all of these together and we can re-assess.
>
>
> That sounds good. As long as it's clear people were aware that we were looking for review and gave a week or more for discussion, then I am fine with proceeding with shipping in parallel.

Thanks for discussing this and clarifying the requirements.
I will get back to this thread once we have published non-draft PRs
and there has been sufficient time for discussion.

[Dan Clark]

Thanks Noam! I saw this news that might be helpful here: https://github.blog/changelog/2026-07-30-stacked-pull-requests-are-now-in-public-preview/

[Noam Rosenthal]

On Mon, Aug 3, 2026 at 5:12 PM 'Dan Clark' via blink-dev
<blin...@chromium.org> wrote:
>
> Thanks Noam! I saw this news that might be helpful here: https://github.blog/changelog/2026-07-30-stacked-pull-requests-are-now-in-public-preview/

Thanks I saw that just the other day! Good coincidental timing :)