Re: [w3ctag/design-reviews] Incubation: patching (interleaved out-of-order streaming) (Issue #1134)

jyasskin left a comment (w3ctag/design-reviews#1134)

Thanks for letting us know about this change! We have some questions about it.

Mainly we'd like to better understand the reason for the switch away from using an element combined with `contentmethod` as the target for the patch. Introducing a new node type to HTML that can represent an arbitrary range of the document seems more [complex](https://www.w3.org/TR/design-principles/#simplicity), so we'd expect to see this switch satisfy a clear user or developer need.

The explainer's [outline of the weaknesses of the element approach](https://github.com/WICG/declarative-partial-updates/blob/main/patching-explainer.md#contentmethod-attribute) is helpful but still leaves questions.

> Doesn't support replacing arbitrary ranges of nodes, only an element or all of its children.

Most cases where only some children need to be replaced seem to be achievable with the `contentmethod`/`contentname` approach from [earlier versions](https://github.com/WICG/declarative-partial-updates/blob/5c6c6edf3cb02594d8b05e9985e9c214c4bcc5f2/patching-explainer.md) of the explainer by just wrapping the content to be replaced with more elements.

For instance this example:

```html
<div marker="part-one part-two">
 <?start name="part-one">
 Placeholder content
 <?end name="part-one">
 <hr>
 <?start name="part-two">
 Placeholder content
 <?end name="part-two">
</div>

<template for="part-one">
  <p>Actual 1st part of the content</p>
</template>

<template for="part-two">
  <p>Actual 2nd part of the content</p>
</template>
```

Could be rewritten as:
```html
<div>
 <span contentname="part-one">
 Placeholder content
 </span>
 <hr>
 <span contentname="part-two">
 Placeholder content
 </span>
</div>

<template for="part-one" contentmethod="replace">
  <p>Actual 1st part of the content</p>
</template>

<template for="part-two" contentmethod="replace">
  <p>Actual 2nd part of the content</p>
</template>
```

A case where the `contentname` element falls short would be if the desired start and end of the range to be replaced do not fall under the same parent, e.g.:

```html
<body>
  <?start name="patch">
  <section>
   Content to replace
   <?end name="patch">
    This probably isn't replaced
   </section>
</body>
```

Is this sort of scenario really something developers are asking for? It's not clear to us that there's a use case for replacing ranges whose start and end don't share a parent.

The algorithm to decide what content to delete when replacing a lopsided range like this will not be trivial. Would the algorithm for [Range.deleteContents](https://developer.mozilla.org/en-US/docs/Web/API/Range/deleteContents) be reused here? And where would inserted nodes wind up? After the start, before the end, or at the highest point in the tree within the range?

Another stated weakness of the `contentmethod` approach is:

> In order to support patching <title>, which uses the [RCDATA tokenizer state](https://html.spec.whatwg.org/multipage/parsing.html#rcdata-state), the tag name of the target element must be repeated. This is because switching to the RCDATA (or RAWTEXT) state in a `<template>` element would change how the content is parsed in supporting and non-supporting parsers, which could be a security concern.

Unclear why repeating the tag is needed -- why doesn't this "just work"?

```html
<title contentname="title">To be patched...</title>
<template for="title" contentmethod="replace-children">
  Title content from the patch
</template>
```
It does seem that patching only a substring of the `<title>` would be tough with this approach. But have you confirmed that there's a real developer need to patch substrings of `<title>`, or patch `<title>` at all?

Lastly:

> prepend can fail if the original first child of the element is removed, meaning that a patch can fail mid-stream, requiring some error handling/reporting.

This one is hard to follow. Once the patch has started, there is a single parser insertion point regardless of whether it was set using an element or ProcessingInstructions. Wouldn't we need to handle DOM mutations around that insertion point for either use case?

Other miscellaneous bits of feedback:
- The explainer shows the `marker` attribute set on the parent node of ranges to be patched, but it's not clear why this is needed. Could the reason be stated more explicitly? Could this work without the attribute, only the patch ranges?
- The [script-initiated-patching](https://github.com/WICG/declarative-partial-updates/blob/main/patching-explainer.md#script-initiated-patching) section mentions `<template contentmethod>`, should this say `<template for>` in the ProcessingInstructions version of the proposal?
- What happens when patches overlap?
```html
<div marker="part-one part-two">
 <?start name="part-one">
One
 <?start name="part-two">
Two
 <?end name="part-one">
Three
 <?end name="part-two">
Four
</div>
```

[Thanks to @dandclark for drafting this comment!]

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1134#issuecomment-4084534128
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1134/4084534128@github.com>

Received on Wednesday, 18 March 2026 17:59:29 UTC