Krzysztof Kotowicz

> Thanks. That seems dismissive of the concerns rather than addressing them. The general `Foo.prototype.method.call(aFooInstance, ...args)` is not the normal way one applies that method to that instance. The typical...

Thanks, @erights, I continued the discussion in #10, as that ticket has the most context.

Hey Ryan, The idea is that the stringification happens in the host, and the (non-stringified) specifier gets passed to the host, which returns a string (or rejects the import). The...

> So far no implementer interest outside of Google, so a progress can happen when something happens there. There is now multi implementor interest: https://github.com/mozilla/standards-positions/issues/20#issuecomment-1853427823, with a Gecko implementation [progressing](https://bugzilla.mozilla.org/show_bug.cgi?id=1508286)....

> When the feature ships, MDN data will be updated and that will be automatically reflected here. Do you mean browser compat data on MDN? I think browser compat data...

Yeah, I encountered the same showstoppeer in Jan :/ I commented, maybe we get get this going...

> @koto can the PR preview please be fixed? The changes themselves are sufficiently complicated, so let's make our life easier by simplifying reviewing. This is done, I'll proceed with...

@lweichselbaum > I guess it would be less of a problem if trusted-types would be capable of guarding eval independently of CSP. I'm not sure I understand this. TT have...

What I meant was that we should not relax the CSP restrictions. The issue is you can create policies (and types through them) even without a TT header, so that...

> * the absence of unsafe-eval means eval(x) fails for all x unless trusted-types is specified and Type(x) is TrustedScript. If we can get it into CSP spec - sure,...