Re: [heycam/webidl] Added a definition of {{StringContext}} extended attribute. (#841)

Thank you, that is very helpful.

So the key is that there is still a concept of "already validated" on the caller side (which was not clear to me from the above) and that we want to only do validation if the thing we have is not already validated.  OK, that makes things much clearer.

> The logic for the sanitization of values is roughly

OK, I see.  One thing that's not entirely clear to me is whether the default policy case should be passed the initial value, or a stringification of the original value, or a stringification with the USVString fixups applied, or whether it doesn't matter much.  But ok, now I understand why you want to at least invoke this algorithm before stringification of the original value.

> In other words, Trusted Type try to prevent the JS code from interacting with risky APIs, not the browser algorithms

OK.  That's a reasonable tradeoff, as long as you make sure that all the relevant boundary bits are annotated.

> Option 2 actually looks OK too. What is exactly the author-observable difference to option 1 + before?

I had been thinking of option 2 as a post-conversion step, so coming at a later point than "option 1 + before".  It looks like you're asking about doing it as a pre-conversion step.

The main observable difference, I guess, is what happens with a union type.  "Option 2" would invoke the sanitization stuff no matter what the value is, and while "option 1 + before" will only invoke it if we determine that we're taking the DOMString branch of the union, right?  Presumably we want the latter behavior, in general?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/heycam/webidl/pull/841#issuecomment-586418661