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

Hey all, thanks for the lively discussion.

I have a few thoughts.

This API has one central goal - replace clientside JavaScript and HTML markers with a browser native API. The clientside JS we are currently targeting is: 
1. Code that does HTML rendering with a combination of static template content (<template>) and dynamic template content (updated via DOM APIs).
2. Code that updates DOM that is already rendered, this includes SSR hydration. The intention here is event listeners for interactivity or other dynamic content that can only be known on the client.
3. Code that updates DOM that has previously been rendered by either CSR as in #1 or SSR in #2.

Code that does not fall into one of those categories is interesting to us, but not the MVP that we've agreed on up to this point (we're open to changing that, if there's feedback).

I think setting HTML content via CSS is a design direction we have been discouraged from exploring, but I'm interested in it as well. There was quite a bit of pushback on the CSS toggle proposal, where people questioned why CSS was not responsible for what would normally have been the domain of HTML. I'm talking about this example:

```
a {
  href: "./user/" var(--user-id);
}
```

The DOM parts equivalent would be something like:

HTML
```
<div id="root" parseparts>
  <a href={{}}></a>
</div>
```

JS
```
const root = document.getElementById('root');
root.getParts()[0].node.setAttribute('href', `./user/{userId}`);
```

I agree it would be nice if `userId` there was some data variable that the browser knew about and it could referenced in CSS as well as JS. We have been ruminating about introducing a data layer (update this one JS object and the HTML is automatically re-rendered based on rendering rules that you set) as well here - but we want to deliver value first in the above use cases before we propose something bigger. That remains an open question - but one that we're interesting in exploring next.

We also explored an idea where you would pass in a data object to some DOM API to update attributes, rather than having to visit the `NodePart`.

I want to be clear that our focus and priority has been on figuring out the technical feasibility of this space. Is it possible for us to design an API that has reasonable performance and replaces the existing JavaScript code that we have in frameworks for rendering and updating rendered content? That's the question we've been building benchmarks for and discussing in depth with browser and v8 engineers. Because without answering that question, any discussion of API shape could be wasted time if we don't properly know what trade-offs from a performance and feasibility perspective we're up against.

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

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