Re: [w3c/webcomponents] [templates] Parts APIs surface concerns (#680)

Not having the top-level `TemplatePart` interface seems fine.

I do like the idea of being able to iterate over all the parts and just assign `value` however. In fact, I wanted to make `value` setter do the same right thing based on whether it's `true` / `false` instead of having a separate `booleanValue`. I didn't do it simply because there wasn't a way to express it in WebIDL. However, you can't really assign a string to `InnerTemplatePart` anyway, this might be already a moot point. In that world, it's probably better to have an explicit `add/remove` methods on `AttributeTemplatePart` instead.

We're not tied to just having `perviousSibling` or `nextSibling`. It's just that we do need some API to know where those template parts belong, and those two properties felt the simplest one we could add.

My original thought was that we didn't want to use live `NodeList` but in this case, the liveness is cheap (e.g. mutating DOM tree doesn't have to invalidate this list) so we can just use `[SameObject]` instead. Using `FrozenArray<Node>` or `sequence<Node>` would be fine as well. We're not tied to the specifics of this API.

Sure, I think just having `textContent`, `replaceWith`, and `replaceWithHTML` would be good. We don't want to use `innerHTML` since it gets confusing with the semantics of `outerHTML` (the semantics of replaceWithHTML is closer to outerHTML although the template part is never really in a DOM tree).

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