Streaming into non-element locations in the DOM?

[noamr]

See this comment.
Some times the place where the new content needs to be streamed into is not necessarily an "element". Perhaps it's a set of <li> elements inside a <ul>? Can we stream into something that's somehow invisible in the DOM, like a fragment? See whatwg/dom#736

[robbiespeed]

Rather than being invisible to the DOM, an element that's part of the DOM tree, but invisible to CSS (or "flattened" meaning the children of view are visible to CSS as children of view's parent) would be ideal. whatwg/dom#736 (author comment in support of this approach)

Special comment like boundaries are the approach taken currently in the persistent fragment proposal due to apparent complexity updating the DOM parser for a new element. whatwg/dom#736 (comment)

However since the view element may face similar challenges in needing to update the parser I think it's worth consolidating both streaming/match and fragment behaviour into a single view element API.

This CSS behaviour would remove view elements ability to have :partial and :deactivated pseudo classes. I'm fairly certain there could be workarounds for this like children of view receiving :deactivated. Similar to template mode=loading|error there could be template mode=partial which appends to the end of the view until fully streamed, though this does raise a question about partial and loading being in conflict (even in the :partail pseudo class case).

I suppose view being only directly selectable via css view:deactivated or something might work, but seems more strange than never being selectable, and could be confusing if there are conflicting selectors like view > li and ul > li that both match the children of the view.

---

For context to those not jumping to other comment links, this is a minimal motivating example:

ul > li:nth-child(even) {
  background-color: lightyellow;
}

<ul>
  <li>Loaded statically</li>
  <view id="list-streamed">
    <li>Waiting for more (should be yellow)</li>
  </view>
</ul>
<!-- Later streamed content -->
<template for="list-streamed" mode="replace">
  <li>First (should be yellow)</li>
  <li>Second (should not be yellow)</li>
</template>

---

A related issue with table element parsing:

<table>
  <tr><td>First Row</td></tr>
  <view id="rows-streamed">
    <tr><td>Loading More...</td></tr>
  </view>
</table>

With current parsing rules this results in:

<view id="rows-streamed">
</view>
<table>
  <tr><td>First Row</td></tr>
  <tr><td>Loading More...</td></tr>
</table>

[noamr]

This feels to me like a bit of an orthogonal use case to view, that perhaps has some nice synergies. Perhaps this is in fact whatwg/dom#736.
First of all, the examples in the comments use views but don't actually make use of view functionality... you can stream <template for> into any element with an ID.

So the following would work:

<table id="rows-streamed">
  <tr><td>First Row</td></tr>
  <tr><td>Loading More...</td></tr>
</table>

It would indeed be nice if there it was possible somehow to address a fragment of the document without it affecting layout and CSS selectors. If there was an addressable <fragment> element that somehow works inside tables and was not CSS-selectable, it would be neat, like this:

<table>
  <tr><td>First Row</td></tr>
  <fragment id="dynamic-rows">
    <tr><td>Loading More...</td></tr>
  </fragment>
</table>

However, as I said:

• This is entirely orthogonal to views, which are more like a <section> or <main> element, a part of the document that responds to URL changes and can intercept them.
• This has synergies with <template for>, but is a separate feature.

[robbiespeed]

@noamr how would your table id example work? If the template is set to replace then it will replace "First Row", if set to append then "Loading More..." remains. You could split the static and dynamic parts into separate <tbody>, but then you have the problem of CSS not respecting the intended row orders.

Limiting <view> to areas similar to <section> or <main>, means that a follow on proposal attempts to add match to all elements. If that happens, then we have a extra <view> element for no reason.

It really doesn't seem all that orthogonal, here's a snippet from the top of the proposal:

Modern web apps are often composed of multiple "fragments" of documents, or "views", presented at the same time and layed out in a flexible way. However, the primitives that the web platform offers for this fragmentation, i.e. iframes, are not flexible in this way. One cannot use a single stylesheet to style multiple iframes, or select all the elements given a CSS selector in multiple documents at the same time, and the iframe's contents cannot escape its bounds, to name a few constraints.

In order to achieve the kind of fragment behaviours web apps provide, you need a way not to affect layout or CSS.

Without it there's a strong chance existing web frameworks won't adopt this new <view> element and possibly not even the streaming capabilities of <template for>, because it's a degradation of the frameworks current capabilities.

My goal in highlighting this is that the web get's a cohesive method for element view/fragments and out of order streaming.

[noamr]

@noamr how would your table id example work? If the template is set to replace then it will replace "First Row", if set to append then "Loading More..." remains. You could split the static and dynamic parts into separate <tbody>, but then you have the problem of CSS not respecting the intended row orders.

I think this would be a nice constrain to solve going forward, but I don't see how it relates to views. It relates to <template for> and a constraint we can solve down the line.

The way I would probably solve this is have modes for a template that allow streaming the content after a given element or between given elements, e.g.:

<view match="/pages/:page"><!-- this is if you want the view URL matching -->
<table id=my-table>
  <tr><td>First Row</td></tr>
</table>
</view>

<!-- when navigating to /pages/2 -->
<template for=my-table after="tr:first-child">

The <view> deals with the navigation and the templates deal with where the data replacement occurs.

Some variant of this would allow introducing the template streaming primitive without adding an invisible DOM fragment, which would add an order of magnitude more complexity to the platform. But we can introduce this after we've established the pattern of template streaming that replaces the entire content of an element.

[jonathanhefner]

I agree with Noam that <template for> seems like an orthogonal feature.

As for the table example, I think you could target the "loading" row instead of the table itself:

<table>
  <tr><td>First Row</td></tr>
  <tr id="loading"><td>Loading More...</td></tr>
</table>

<template for="loading" mode="replace">
  <tr><td>Second Row</td></tr>
  <tr><td>Third Row</td></tr>
</template>

[noamr]

I think we do need a solution for this, and that we should use the semantics of Range.

For JS, it can be Range.prototype.patch() that opens a writable stream that replaces the content of the range with whatever comes from the stream.

That would make node.patchSelf a thin wrapper around the following script:

const range = new Range();
range.selectNodeContents(target_node);
return range.patch();

The attributes for the template element would be equivalent to the set* functions of Range that accept a node: patchStartBefore, patchStartAfter, patchEndBefore patchEndAfter, where patchfor would be equivalent to selectNodeContents.

[noamr]

... Looking at the details of the spec/implementation, streaming into a range is too much of a challenge.
What can work is the following:

// All of these return a `WritableStream`
node.patchBetween(child_a, child_b)
node.patchAfter(child_a)
node.patchBefore(child_b)

And probably patchSelf can be renamed to patchReplaceChildren or some such.

<!-- This would apply the patch between the given children, or would patch before/after a single given child -->
<!-- The patching would fail if the child is not found or is not a child of the parent -->
<!-- In case of failure, a `patcherror` event will be fired on the document -->
<template patchfor=parent patchstartafter=a patchendbefore=b>

[robbiespeed]

All of that added API surface could be avoided if there was a fragment element, whether that's view or not.

[noamr]

All of that added API surface could be avoided if there was a fragment element, whether that's view or not.

If we ever have that fragment element (which I don't think is feasible) or a DOM-parts based solution it would be great but IMO it shouldn't be a dependency here.