Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CSS Modules #405

Closed
2 of 4 tasks
dandclark opened this issue Aug 8, 2019 · 15 comments
Closed
2 of 4 tasks

CSS Modules #405

dandclark opened this issue Aug 8, 2019 · 15 comments
Assignees
Labels
Pre-spec review Progress: review complete Resolution: satisfied The TAG is satisfied with this design Review type: CG early review An early review of general direction from a Community Group tag-tracker Group bringing to attention of the TAG, or tracked by the TAG but not needing response. Topic: components Topic: CSS Topic: modules

Comments

@dandclark
Copy link

dandclark commented Aug 8, 2019

こんにちはTAG!

I'm requesting a TAG review of:

Further details:

  • Relevant time constraints or deadlines: None, though we're ready to move forward with an implementation in Blink.
  • I have read and filled out the Self-Review Questionnare on Security and Privacy. There are no new security/privacy concerns, as this proposal follows JavaScript/JSON modules with respect to the usage of fetch.
  • I have reviewed the TAG's API Design Principles

You should also know that...

Much of the discussion regarding this feature thus far has taken place on this issue thread, also linked above: WICG/webcomponents#759

We'd prefer the TAG provide feedback as (please select one):

  • open issues in our GitHub repo for each point of feedback
  • open a single issue in our GitHub repo for the entire review
  • [ x ] leave review feedback as a comment in this issue and @-notify @dandclark

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.

@dandclark
Copy link
Author

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.

@travisleithead
Copy link
Contributor

travisleithead commented Aug 16, 2019 via email

@dbaron
Copy link
Member

dbaron commented Sep 11, 2019

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.

@annevk
Copy link
Member

annevk commented Sep 26, 2019

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.

@annevk

This comment has been minimized.

@plinss plinss added Progress: pending external feedback The TAG is waiting on response to comments/questions asked by the TAG during the review and removed Progress: in progress labels Oct 2, 2019
@dbaron
Copy link
Member

dbaron commented Dec 3, 2019

@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?

@plinss
Copy link
Member

plinss commented Dec 3, 2019

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

@kenchris
Copy link

kenchris commented Dec 4, 2019

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

@dandclark
Copy link
Author

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.

@torgo torgo removed the Progress: pending external feedback The TAG is waiting on response to comments/questions asked by the TAG during the review label Jan 27, 2020
@cynthia
Copy link
Member

cynthia commented Mar 2, 2020

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?

@dbaron
Copy link
Member

dbaron commented Mar 2, 2020

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.

@torgo torgo added Progress: in progress and removed Progress: propose closing we think it should be closed but are waiting on some feedback or consensus labels Mar 11, 2020
@torgo torgo added this to the 2020-03-16-week milestone Mar 11, 2020
@torgo torgo added Progress: propose closing we think it should be closed but are waiting on some feedback or consensus Progress: pending external feedback The TAG is waiting on response to comments/questions asked by the TAG during the review and removed Progress: in progress labels Mar 16, 2020
@dbaron
Copy link
Member

dbaron commented Apr 20, 2020

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

@plinss plinss added the tag-tracker Group bringing to attention of the TAG, or tracked by the TAG but not needing response. label Apr 20, 2020
@torgo torgo added the Resolution: satisfied The TAG is satisfied with this design label Apr 22, 2020
@plinss
Copy link
Member

plinss commented Apr 22, 2020

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

@plinss plinss closed this as completed Apr 22, 2020
@plinss plinss added Progress: review complete and removed Progress: pending external feedback The TAG is waiting on response to comments/questions asked by the TAG during the review Progress: propose closing we think it should be closed but are waiting on some feedback or consensus labels Apr 22, 2020
@hober hober mentioned this issue Aug 5, 2020
1 task
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Pre-spec review Progress: review complete Resolution: satisfied The TAG is satisfied with this design Review type: CG early review An early review of general direction from a Community Group tag-tracker Group bringing to attention of the TAG, or tracked by the TAG but not needing response. Topic: components Topic: CSS Topic: modules
Projects
None yet
Development

No branches or pull requests