Re: [w3ctag/design-reviews] Trusted Types (#198)

Hey @hadleybeeman, I'm koto, working with Mike on this.

To answer your questions:
> Why is trustedURL not a subclass of URL?
No strong reason, these types originate from Google internal implementation, where that was the case. I'm not opposed to subclassing.
> Example code vs IDL
In fact, we have a polyfill implementation now in the repository, it can be built with:
``
$ npm install
$ npm run build
``
or you could check the  sources.
> es6 template strings
Yes! I proposed something like that in https://github.com/mikewest/trusted-types/pull/26.
> naming
We have reasons why this is named trusted as opposed to e.g. safe, but at this stage names are not that important, though "unserializedTypeForDOMManipulation" will probably not fly ;)
> escaping
We're hoping to come up with an API with safe builders that may make the migration easier, and offering security benefits. This is just an early draft. 
> Concatenation
That is actually expected, by concatenating safe HTMLs with raw strings you may come up with an unsafe construction (if the strings are user-controlled). I hope to address that in https://github.com/mikewest/trusted-types/pull/26, where interpolating user data gets slightly easier, but in general we hope such literal + TrustedHTML contatenations could be automatically refactored, rather than silently accepted at runtime. 


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/198#issuecomment-336125255