Skip ⬇

CSS Module Scripts

Facilitator: Daniel Clark

Minutes (including discussions that were not audio-recorded)

Previous: Declarative Shadow DOM All breakouts Next: NativeIO

Skip ⬇

Skip ⬇

Transcript

So hi, everyone.

My name is Dan Clark from the Microsoft Edge team.

In this breakout session on CSS module scripts, this session is slated for open discussion, but I think it would be helpful just to run through a few slides, to like, set the context here.

I think a good goal to get out of this would be to achieve some kind of consensus on a V1 of CSS modules.

To set the stage for that, I'll just do like a quick recap of the feature.

I'll talk about some issues that held us up last year on involving this security issue around involving MIME type and then about @imports, and then we can open it up for discussion and as time permits, we might also be able to talk about some future directions for CSS modules.

Thanks, Dan.

Let me just remind you and everybody that the captionist, as well as others, might appreciate speaking more slowly than normal.

Yes.

Yeah, I'll slow down.

So CSS module scripts is this idea where we could integrate CSS into the ECMAScript module system.

This just means that I should be able to import a style sheet from a CSS file the same way that today I might import from a JavaScript file.

So there are multiple reasons we might like to do this.

We'd like to leverage advantages of the ECMAScript modules system.

With ECMAScript modules, I get elimination of duplicates where we won't process the same resource twice, even if it's pulled in at multiple points.

There's a well-understood order at which our dependencies are evaluated with the ASIS modules, even if they're a mixed JavaScript and CSS dependencies, there would be a clear order at which these are evaluated.

And with modules, we know that when code is executing, when the importing code is executing, at that point, all of that code's dependencies have already been successfully evaluated.

And there's evidence that developers want this, just in terms of all the build tools that are used to achieve this sort of thing today, like there are a number of tools that allow you to require a CSS, import CSS, things such as the version of CSS modules often used with webpack and React, not to be confused with the proposal we're talking about today, as well as tools like LitElement, which follow really similar patterns to what's proposed with this CSS module's syntax.

So there seems to be evidence the developers wanna be able to do this sort of thing.

So where we ran into trouble with this feature last year is this security issue involving MIME type.

So modules, once we have more than one resource type, the MIME type that the service sends over the wire is used to determine what type of module we've got.

So if we get a text/css MIME type with our requested resource, the browser knows that, okay, this is a CS module, so I'm going to parse it as CSS and do the CSS module behavior.

Where this runs into difficulty is the fact that modules can be imported cross-origin, and so if I am writing what I think is just a CSS module, maybe I'm not that careful because I think like it's just CSS.

It's not script, so like, it's safe.

But the problem is if this third party that I'm taking the resource from is, say it's compromised or it turns rogue or whatever, it can respond to my imports with a JavaScript MIME type and a malicious payload, and suddenly I'm executing third-party scripts where I thought I was just getting CSS.

So what we've been doing over the last year is I've been working with some other cochampions in TC39 to advance this proposal called Import Assertions to change the language, add to the import syntax to allow other information to be passed along with a given import.

And what this lets us do is pass along the expected type with an import.

This will be required when you are importing a CSS resource and this type assertion will prevent any surprises where if the MIME type of the fetched resource is not CSS as was expected, then the import will just fail, so there's no possibility for some kind of privilege escalation or type confusion.

Another issue that has sometimes come up with this feature is the question of what did we do about CSS @import rules.

There's kind of two paths to take here.

One path is just don't do anything special with them.

They won't have any effect on the ECMAScript module graph.

The other approach is to actually give them special behavior in CSS modules where a @import rule will actually constitute a CSS module, and then you have non-leaf CSS modules and you can build a complex graph of CSS modules.

There are good arguments on both sides of this question, and we can get into that in more detail later in this session if we want, but I think the best way to actually drive towards a decision here would be to move forward with the V1 that just bans the use of @imports, will fail on the use of @imports, that allows us to not box ourselves into a corner in terms of backwards compatibility.

And then we get this feature being used in production, we build developer excitement around it, and we get a lot more information and feedback from developers about how they wanna use this feature, about how it is used, and that information and experience might help us actually drive towards a decision later on for this.

So with that context set, I think we could move into discussion.

I think the thing to start with might just be like, is there a consensus on the CSS modules V1 with Import Assertions and with no @imports?

Are implementers interested in building this?

Are there objections?

And if we can get somewhere on that, we could dig into this topic that got punted on Monday, adopted style sheets, 'cause there's some issues to resolve around that API, and that's pretty closely related to CSS modules.

And then as time permits, we could talk about some future directions for CSS modules, in terms of a recent proposal from Justin about bundling the multiple style sheets into the same file.

Ideas about adding named exports from CSS modules and maybe spending some more time on this @imports question beyond just banning the feature, as I'm suggesting that we do in this V1.

So with that, I think we can go to the queue.

A good way to start, maybe like any folks that would have concerns or objections to this V1 of CSS modules, be great to hear from you.