Inline ES Modules
valentinium at gmail.com
Tue Jun 19 23:56:47 UTC 2018
Andrea: That is a really interesting approach. I would point out that using
data URIs for js means the `data:` scheme has to be a permitted source for
script-src. This allowance has roughly the same security implications as
permitting `unsafe-eval`. I know most people aren’t using CSPs yet, but
personally I’d be wary of a solution that makes it harder to adopt a strong
A super dorky/tangential aside that probably doesn’t matter at all but ...
contradiction between the IANA media type registry and the HTML 5 spec with
regard to the "correct" media type to use for JS. RFC 4329 says
sure though) that this is because it’s the most backwards-compatible value.
Given that the media types registry seems to be basically dead to web
standards (if we follow the registry we can’t serve or post a bunch of
media types acknowledged or defined by web standards at all, including
image/webp, application/csp-report, etc) and the code has to run in a
browser, I’d tend to think HTML is the better spec to follow ... though I
guess when two specs contradict each other it’s hard to make an objective
case for one being more authoritative. (I’d be curious if there’s a
specific reason you know of to prefer to RFC definition though. When
standards don’t align it breaks my tiny heart.)
On Tue, Jun 19, 2018 at 4:09 PM Andrea Giammarchi <
andrea.giammarchi at gmail.com> wrote:
> sorry, I meant:
> On Tue, Jun 19, 2018 at 10:09 PM, Andrea Giammarchi <
> andrea.giammarchi at gmail.com> wrote:
>> I think these are all nice to have features, but I also think we have all
>>> the primitives we need to make it happen via pre-processing.
>> I meant even synchronously, with a pre-processor that replace the
>> imported module with
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss