Re: [WICG/webcomponents] DOM parts use outside of <template> seems unlikely (Issue #1035)

I could be misunderstanding this, but it seems this would be far more challenging for a server framework to manage, since now when someone writes an expression in their server template, the framework would have to split that out into two different files entirely. The SSR'd value would need to go into a style tag just before the element that was being generated, and the binding expression would need to be extracted into a separate CSS file. It's also not clear how this would target individual text nodes or whole elements (not necessarily an attribute), or handle block scenarios. Here's a more realistic example showing what the current proposal would support in terms of block rendering, element targeted parts, attribute interpolated parts, and text interpolated parts.

```html
<ul parseparts>
  {{# for user of users}}
    <li {{draggable}}>
      <a href="./user/{{user.id}}">User {{user.name}} is {{user.age}} years old.</a>
    </li>
  {{/}}
</ul>
```

(Again, note that everything between `{{` and `}}` is considered metadata at this point in the game. So, "for user of users" is just something I made up right now; that's just considered metadata by the browser for now.)

The CSS-like approach here also seems a bit tricky for the browser to manage because even if the SSR'd value for userId is provided in the style tag for bindings, the browser can't do anything with that until it downloads the css file that tells it what to do. I would worry that this would cause all sorts of content update flashes and potentially perf issues with needing to do a double render for almost everything. First the browser renders the `a` tag, and then it has to re-render it, and it has to do this across the entire DOM, potentially hundreds or thousands of nodes. When we were initially working through different options, we heard from browser vendors that it wasn't really acceptable to have bindings without values. It makes it difficult for the rendering engine to know what to do. I understand this isn't exactly the same situation, but it seems to introduce a set of related problems.

Let's keep iterating. We need a concrete workable alterative if there is really dissatisfaction with the current direction. Any new proposal has to address the core set of requirements as well as the concerns that browser vendors have raised with past iterations of dom parts.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/WICG/webcomponents/issues/1035#issuecomment-1804469514
You are receiving this because you are subscribed to this thread.

Message ID: <WICG/webcomponents/issues/1035/1804469514@github.com>