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

@EisenbergEffect 

> 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. 

You're assuming that the user is writing it with an existing templating language and the language is "compiling" it to what I wrote, but that doesn't need the be the case (although a templating *could* do that if it wanted)! The user would just only write the binding in the binding part, and leave the HTML part blank.

I agree though that writing an inline style "binding sheet" would be ugly, so you might want to write it this way instead:

__index.html__

```html
<a data-user-id="1234">...</a>
```

__bindings.css__

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

> It's also not clear how this would target individual text nodes or whole elements (not necessarily an attribute), or handle block scenarios.

You can't target individual text nodes, just like you can't with CSS. As with CSS you use separate `<span>`s if you want to target more than one text part for binding. You might notice that most of my answers to questions are just pointing to how CSS works. That is the intent of this idea.

> 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.

The values are present in the initial HTML, they just aren't present at the HTML insertion point like with templating. They are present in another place and applied. They are applied before paint, so there are no FOUC concerns here.

Think about it like with CSS. If you want some text to be red, you don't have to define it as red in the element's `style` attribute for it to red. It's red because you have a blocking stylesheet or inline stylesheet. The same applies here.

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

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