Should we be looking at https://github.com/w3c/webcomponents/blob/gh-pages/proposals/css-modules-v1-explainer.md rather than https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/master/CSSModules/v1Explainer.md ?

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.

Thanks for doing that! (Sorry, I forgot to put the in-document notice after I updated the readme page on github...)

From: Dan Clark notifications@github.com Sent: Tuesday, August 13, 2019 9:36 AM To: w3ctag/design-reviews design-reviews@noreply.github.com Cc: Travis Leithead travis.leithead@microsoft.com; Mention mention@noreply.github.com Subject: Re: [w3ctag/design-reviews] CSS Modules (#405)

The documents are currently identical, but https://github.com/w3c/webcomponents/blob/gh-pages/proposals/css-modules-v1-explainer.mdhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3c%2Fwebcomponents%2Fblob%2Fgh-pages%2Fproposals%2Fcss-modules-v1-explainer.md&data=02%7C01%7Ctravis.leithead%40microsoft.com%7Cf0be592e61f845695f4008d7200c5bf6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637013109761276995&sdata=mPaDUI56ae%2BiqRH8jVocVpMe6bsCfeei8q0Rj1vJTcY%3D&reserved=0 should be treated as the primary version going forward. I'll update the other one to point to it. Apologies for the ambiguity.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3ctag%2Fdesign-reviews%2Fissues%2F405%3Femail_source%3Dnotifications%26email_token%3DAAQNR6DV7QETXEOXLKVVBHDQELPH5A5CNFSM4IKOSOZ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4GHOXQ%23issuecomment-520910686&data=02%7C01%7Ctravis.leithead%40microsoft.com%7Cf0be592e61f845695f4008d7200c5bf6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637013109761286991&sdata=IdD6aOKppzmTJNqNLcWy8IgkRU61hMsd%2BA4CAZNh%2BnA%3D&reserved=0, or mute the threadhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAAQNR6CAMI6JZQOBXJNBIJDQELPH5ANCNFSM4IKOSOZQ&data=02%7C01%7Ctravis.leithead%40microsoft.com%7Cf0be592e61f845695f4008d7200c5bf6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637013109761286991&sdata=OKCVo3etKewUoblteAslPNt%2B5piueQmTZIHOtvhXI%2Fg%3D&reserved=0.

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 @import for now -- worried that people will be disturbed by this feature not working. I'd note that at least some (maybe all?) browser CSS implementations use copy-on-write sharing for stylesheets that are @imported multiple times (whose CSSOM representation start off as thin wrappers until they're accessed). So that might argue for just continuing to use that model. On the other hand, the desire to handle @imports in a way that allows the CSSOM to modify all the instances at once seems like a reasonable desire as well -- and it seems reasonable to do CSS modules such that @imports share the CSSStyleSheet objects, they're all part of the module graph, and any stylesheet that's part of the module graph just has a null parent style sheet even if it's actually imported in one or more places. It's a slightly bigger change to the model, but it does have benefits.

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.

Apple raised a security issue with JSON modules that also applies here. The importer cannot enforce that the result is actually a CSS module (or at least something that does not execute script), meaning that if the distributor went rogue or got compromised they could execute JavaScript/Wasm in your origin.

Maybe, this is probably not the place to do design work. I mainly wanted to highlight the security issue so the TAG can take that into consideration when reviewing other work.

@plinss and I are discussing this again in a breakout in Cupertino.

We'd note that there are additional variants of options 2 and 3 that could be considered, in particular:

• an option 2a that treats a failed @import as just something that gets dropped like in the rest of CSS, rather than causing the module to fail
• an option 3a that makes the CSSOM for such stylesheets readonly (although neither of us really like that)

Along those lines, it might be useful if the explainer says what happens when an import fails, for readers who aren't familiar enough with ES modules. (I'm not!)

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?

I presume this also works with dynamic imports? In that case is the module returned simply the CSSStyleSheet?

This seems relevant to the discussion: https://github.com/littledan/proposal-module-attributes/ @littledan

Re: @dbaron

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 @import so perhaps just benignly dropping the missing @import to be consistent with the current CSS behavior makes sense. I'll update the explainer to list this possibility as well.

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 @imported from multiple sheets, and we would still need to decide the right way to reflect that in a read-only OM. Furthermore, the main motivating scenario for option 3 is that dynamic changes to a particular stylesheet can be reflected in multiple importers. If the OM is read-only this capability would be limited.

I'll add a comment in the explainer about the behavior when import fails (the module graph doesn't execute; same as with the failed import of a JavaScript module).

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 syntax to specify the module type, e.g.

import styleSheet from "./foo.css" with type: "css";

Re @plinss:

I presume this also works with dynamic imports? In that case is the module returned simply the CSSStyleSheet?

Yes, it will work with dynamic imports. The returned Promise resolves with the module namespace object, where the default property is the CSSStyleSheet. More discussion on this here. That thread is about JSON modules but the ideas are the same. Justin's comment here notes that this keeps open the future possibility of things like exporting named CSS selector references.

OK, it's good to hear that you're considering that feedback. I don't think the TAG intends to be particularly pushy about this feedback, but we're happy to hear you're looking into it.

(The one note about the 3a readonly option is it's reflecting that many (maybe even all?) implementations use shared stylesheet inners and copy-on-write cloning when stylesheets are linked from multiple places.)

I think (although I don't want to speak for others on the TAG) that we can probably consider closing this issue at some point soon, since I'm not aware of additional feedback that we're expecting to provide.

The ideal outcome is that this will enable us to use the import syntax to specify the module type

Given that the plumbing is in place, would this be mandated? If not, what is the intended behavior without the directive, given the file swap security concerns noted above?

We (me, @plinss, @sangwhan, @ylafon) are looking at this again at our Wellington Face-to-Face. We're still concerned about this @import issue getting punted. It feels like the mechanisms for adding @import rules in dynamic situations already exist in the platform, though they may not be specified clearly; we just filed w3c/csswg-drafts#4821 on that.

We'd like to continue to leave this open to monitor what's going on with handling of @import rules.

Worth noting that the other related issue (not directly mentioned) was w3c/webcomponents#870.

We're happy with the direction this is taking, will continue to monitor the open issues.