[w3c/webcomponents] Rejecting CSS Modules in Workers (#854)

Regarding [CSS Modules](https://github.com/w3c/webcomponents/blob/gh-pages/proposals/css-modules-v1-explainer.md):

We're currently working on upstreaming the [CSS Modules PR](https://chromium-review.googlesource.com/c/chromium/src/+/1799923).

It has been decided that CSS Modules should be rejected in workers. How exactly to perform that rejection is debatable.

One approach is to perform the rejection as a parse error. The proposal is to add a flag,"allow_document_only_module_type" , to [ModuleScriptFetcher::WasModuleLoadSuccessful](https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/loader/modulescript/module_script_fetcher.cc?q=ModuleScriptFetcher::WasModuleLoadSuccessful&sq=package:chromium&g=0&l=27). If WasModuleLoadSuccessful is called from a document, we will allow the CSS Modules to fetch, otherwise, throw a fetch error.

Another approach is to perform a check on the execution context during [ValueWrapperSyntheticModuleScript::CreateCSSWrapperSyntheticModuleScript](https://chromium-review.googlesource.com/c/chromium/src/+/1799923/15/third_party/blink/renderer/core/script/value_wrapper_synthetic_module_script.cc#25) and throw a parsing error if we're attempting to load the CSS modules from a context other than a document. 

The advantage of failing the fetch() based on MIME type might be that it would be clearer to the developer. The error message would be similar to the one you already get if you try to 'import' something that doesn't have a JS MIME type.

The parse error approach could be preferable architecturally speaking if the fetch() steps don't have to know about the module map's settings object.

Any opinions? @annevk @domenic @hiroshige-g

-- 
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/854