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

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

Thanks for sending this to the TAG! We have some questions and things you may want to consider.

- Since perceived performance is a primary motivation, we're wondering if you have expectations about how much time can be saved and where specifically the saved time is going to come from. Maybe the benefit of one-off (JS-driven)  patches could be measured as [INP](https://developer.mozilla.org/en-US/docs/Glossary/Interaction_to_next_paint) improvement? How about Interleaved (HTML-driven) patches? Or is the goal more about reducing JS payload size because streamed updates no longer need to be managed in JS? Maybe both?
- It's good to see `patchid` used to target patches rather than `id`, but consider also https://github.com/webplatformco/explainers/blob/main/html-element-references/README.md. How does the scoping of `patchid` work with shadow DOM?
- Regarding "The first patch for a target in the document stream replaces its content, and the next ones append." The need to append is clear but it seems like it'd be simpler if all patches appended, without the first one replacing. If there's a desire to show a "Loading" message/icon that goes away when the first patch comes in, that could alternatively be managed with the proposed `:patch-pending` pseudo.
- If the first patch appended rather than replaced the initial content, would there still be a use case for [replacing a range](https://github.com/WICG/declarative-partial-updates/blob/main/patching-explainer.md#enhancement---replace-range-instead-of-whole-contents)?
- The Security & Privacy self-review answer to "Does data exposed by your specification carry related but distinct information that may not be obvious to users?" should probably be "Yes" since this is about streaming HTML, which carries lots of different kinds of information, to an arbitrary node, where different nodes might expect different kinds of information.
- What does interaction with the BFCache look like if the page navigates while there's an active stream? Does the streaming continue? Or does the fetch get cancelled in a way that might not be recoverable when the page is reloaded?
- The `pending` state in https://github.com/w3c/csswg-drafts/issues/12579 seems useful, especially since it seems to replace the use case for the first patch to replace the initial content as discussed above. Triggering it based on the presence of the `patchid` attribute is a little worrying. Maybe the declarative patch should also be able to update the original node's attributes? We're happy that the CSSWG is exploring how and whether to merge the proposed `:patching` pseudo-classes into other pseudo-classes that already exist.
- "Patch" might not be the right name. The action is either to replace or append to an existing node (and we'd prefer to avoid "replace" if possible), while "patch" implies changes in the middle of the content. Perhaps something like `appendto` as the declarative attribute is a better fit?
- We see that the API shape and naming question has continued in https://github.com/whatwg/html/issues/11669. We think that's going in a good direction, with a consistent structure across the streaming and non-streaming methods, and different names for synchronous vs asynchronous methods. We don't have any further comments on the details.
- Can multiple patches be active at once? Can a patch be started when the main HTML parser is still active on the document? Would any issues arise from allowing multiple instances of the HTML parser to be active (in a paused state) simultaneously on the same document?
- If started before the `load` event fires, do active patches block the `load` event? Or `DOMContentsLoaded`? More generally, is there a need for a central way for developers to track whether there are active patches, or is it enough to be able to track them individually?
- [Patching contents from a URL](https://github.com/WICG/declarative-partial-updates/blob/main/patching-explainer.md#potential-enhancement---patch-contents-from-url) kind of sounds like what [HTML imports](https://chromestatus.com/feature/5144752345317376) was trying to do; it's worth revisiting the history there to ensure the same issues aren't getting repeated that led to its deprecation. An issue with HTML imports was that it was a new type of dependency that didn't integrate well with ES modules (also new at the time). Is that a problem for this proposal? ES modules seem incompatible with streaming, as they require all module dependencies to be loaded prior to execution.
- Can a single patch be directed into multiple elements?
- Can interleaved patches be chained as follows?

```html
<section patchid=gallery>Loading...</section>
<template patchfor=gallery>
 <div patchid=gallery-item>Loading item...</div>
...
</template>
<template patchfor=gallery-item>...</template>
```

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

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