Re: [w3c/webcomponents] Discussion: Templates that Don't Destroy Element References (#777)

@Lonniebiz 

> The toTemplate() does the same thing that the toDOM() method does, except it returns an inert html `<template>` element where all interpolations/expressions have been replaced with unnamed-TemplateParts.

What does inertness get you here?

Typically, in a template system you want to delay side-effects like network fetches or code loading until render time.

Inertness lets you do that for trusted template elements, but it's unclear to me how that helps fill holes.

For example, in `<template><script>foo()</script><div>{{x}}</div></template>`, if `x` is filled with `<img src=/bogus onerror=alert(window.origin)>` then you delay the call to `foo()` until render time, but you also need to parse `x` in an inert context to delay its side-effects.

So I'm unsure of the value of inertness for trusted template code without inertness for untrusted inputs, and I'm unclear on how the latter kind of inertness falls out of these changes.

----

It's also unclear to me how this helps with untrusted inputs that specify bytes in a language other than HTML, like `javascript:` URLs reaching `href` or `src` attribute values.

Having a DOM structure helps you derive context for holes, but it doesn't help preserve developer intent unless you use that context to reinterpret inputs.  By the time you've parsed inputs to DOM fragments, I worry that it will be too late to reinterpret them.

----

https://github.com/wicg/trusted-types provides a type-safe taxonomy for distinguishing trusted and untrusted inputs in important contexts but depends on delaying parsing.



-- 
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/777#issuecomment-445945669