Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
I'm requesting a TAG review of:
You should also know that...
Much of the discussion regarding this feature thus far has taken place on this issue thread, also linked above: w3c/webcomponents#759
We'd prefer the TAG provide feedback as (please select one):
Please preview the issue and check that the links work before submitting. In particular, if anything links to a URL which requires authentication (e.g. Google document), please make sure anyone with the link can access the document.
¹ For background, see our explanation of how to write a good explainer.
The documents are currently identical, but https://github.com/w3c/webcomponents/blob/gh-pages/proposals/css-modules-v1-explainer.md should be treated as the primary version going forward. I'll update the other one to point to it. Apologies for the ambiguity.
I'm currently looking at this with @kenchris in a breakout at the TAG meeting.
I think we both think this looks pretty reasonable.
I'm a little concerned about bypassing handling of
It's not clear to me what the benefit of deferring the decision is. Is there particular evidence you're waiting for to settle this? If not, it seems like it might be better to hammer out the decision sooner rather than crippling part of the feature just because of failure to agree on which path to take.
We'd note that there are additional variants of options 2 and 3 that could be considered, in particular:
Along those lines, it might be useful if the explainer says what happens when an
We're also concerned about relying on either the file extension (given that web behavior shouldn't depend on them) or the mime type (given the security issue mentioned above) to determine that it should be CSS, so it seems like there should be some syntax differentiation for stylesheet imports.
We're curious what the status of this is, and whether you have any thoughts on this or the previous comments?
This seems relevant to the discussion: https://github.com/littledan/proposal-module-attributes/ @littledan
I agree that 2a is worth considering. I am a little wary of not failing the module graph if any resource is not found, as that somewhat goes against the expectation that if a module graph is executing, all statically imported resources are present. On the other hand the basic principle of option 2 is that we're not really changing the semantics of
I'm not sure that making the stylesheet OM read-only solves a lot of the issues with option 3; we still have the problem where a stylesheet can have multiple parents if
I'll add a comment in the explainer about the behavior when
Your concerns about relying on file extension or MIME type are widely shared at this point. Issue thread here. We're proposing @littledan and @xtuc's https://github.com/littledan/proposal-module-attributes/ for State 1 to TC39 this week. The ideal outcome is that this will enable us to use the
import styleSheet from "./foo.css" with type: "css";
Yes, it will work with dynamic imports. The returned Promise resolves with the module namespace object, where the