Change 'CSS Modules' name to avoid webdev confusion

[gregwhitworth]

@stubbornella first alerted us to web developers having confusion with CSS Modules and the popular CSS Modules project which helps handle CSS scoping. Since the name CSS Modules is never surfaced within the API and is only used in the specification I think it's safe to change how the specification references it to avoid web developer confusion (heck it will help in SEO too :) ).

Here are some of the options I've heard:

1. Style Modules
2. StyleSheet Modules

Any other suggestions are welcome.

[matthewp]

I disagree, CSS Modules is a generic name that describes the type of module it is. We call JavaScript Modules despite pre-existing types of JavaScript Modules. Style Modules / etc. would be less descriptive about what they are and make it harder to find.

[thepassle]

There was already discussion around this here.

Furthermore I agree with Justin's comment here, and think we should stick with the name 'CSS Modules'.

[gregwhitworth]

I don't necessarily disagree and stated the same thing here on twitter and am honestly not too bullish in one direction or the other. I suspect that Justin is correct that as the issues with scoping are solved then the project CSS Modules will go away. That said, naming them Style or Stylesheet modules within the specification doesn't stop us or the community from referring to them as CSS Modules when the context is known. Similar to how you stated that ECMAScript Modules you use the term JS Modules. At any rate, I'll say that I come down on the side of not changing the name - but I think it's worth considering other options since it's only an editorial change.

[benschwarz]

I disagree, CSS Modules is a generic name that describes the type of module it is

That would be true if there wasn't a very popular project that achieves a similar result with 12,630 stars on GitHub.

CSS Modules is also built into webpack (via the css-loader) and there's also a plugin for post-css. So there could potentially be confusion for developers in respect to tooling.

In fact, CSS Modules is also identified by the State of CSS Survey as one of the most popular (and still rising) css-in-js projects:

I think the surface area of "CSS Modules" is a lot more dramatic than first thought.

Since the name CSS Modules is never surfaced within the API and is only used in the specification

Given the above, what reasons do you have to keep using the same name? Other than "We've already talked about this before"? It seems to me that there's no upsides to keeping the specification title.

[Westbrook]

Being that many of the phase 2+ features I’ve read about people being interested in bring more and more of the things previously known as “CSS Modules” into the browser, doesn’t it make better sense to lean into the confusion than away?

Confusion on differences should drive deeper and broader investment into the spec development process and hopefully a more robust spec shipped to browsers sooner!!

[stubbornella]

I think a new name for a new tech would be better and lead to a lot less confusion. I'd go for "stylesheet modules" but I don't feel strongly between that and "style modules".

In general, it's bad form to take a name that belongs to something else, make it mean something different, and then say "that's ok, we're going to replace your tech in v2 anyway".

Another tactic where you co-design a new tech with the authors of the popular user-space solution would allow more flexibility around using the same names, but even that should be done extremely judiciously. It's not worth the pain for developers trying to disambiguate the two, especially if they are just learning.

[stubbornella]

When you co-design, the popular user-space solution can become the polyfill for the new tech, allowing it to be used more quickly before there is full browser support. The authors can also provide nuanced use cases that might not be obvious at the get-go.

[matthewp]

What exactly do we mean by "name" in this context? There isn't a repo or website called "CSS modules" about this idea. Are we talking about the heading in whichever spec this eventually ends up in? Or something else?

[LarsDenBakker]

They should have expected something like this when they picked such a generic name for a custom project.

[annevk]

@matthewp I'd expect the concept currently called "CSS module script", no?

"CSS style sheet module script" could work, after https://drafts.csswg.org/cssom/#css-style-sheet.

[benschwarz]

They should have expected something like this when they picked such a generic name for a custom project.

This is a really strange comment and the vitriol behind it is concerning tbh

[markcellus]

If we wanna split hairs here, both of the words "CSS" and "Modules" have always been used and driven by the spec, for obvious reasons.

I'm not saying anyone owns the words, but if we're going to be fair, the spec technically used these terms way before the CSS Modules repository came along 🙂 (and just because they put the two words together into a derivative term of "CSS Modules" doesn't make it excusable—especially from an seo perspective)

That being said, I vote that the "CSS Modules" repository maintainers come up with a new name.

[karlhorky]

doesn’t it make better sense to lean into the confusion than away?

@Westbrook I think this is a really dangerous suggestion, and doing this increases the hostility / complexity of the web platform for beginners.

I see first hand with students every day how learning about new web concepts is difficult. Remembering the dizzying amount of new names is hard enough - but if a name can mean two different things, this increases the level of frustration by magnitudes.

[mikesherov]

Here's a naming suggestion if y'all do decide to change it: "Modular CSS"

[Westbrook]

The reason I lean this way @karlhorky is that I’m not sure that it’s the naming that is really going to confuse people. The APIs being 95% the same seems much more trouble some in my experience learning the expansive functionality that is now the web. What’s more when someone learns ES/JS Modules and then JSON Modules and some HTML Modules, then they’ll really be confused when it’s not also CSS module they learn next.are we sure this larger conversation is actually serving the purpose intended in these cases as well?

[karlhorky]

I’m not sure that it’s the naming that is really going to confuse people

What do you base this on? Have you had experience with people saying "oh this thing is named the same thing as this other, different thing - no problem!" or similar?

The APIs being 95% the same

Am I reading this right that you are arguing that the similarity of the APIs is a problem? If so, that's not really the point in this issue here...

when someone learns ES/JS Modules and then JSON Modules and some HTML Modules, then they’ll really be confused when it’s not also CSS module they learn next are we sure this larger conversation is actually serving the purpose intended in these cases as well?

Does this seem like a common learning path to you? It seems a bit contrived... I would expect most module systems to be covered together in one block in most learning materials (if they do get standardized).

---

For the record, I actually agree about consistency being generally a good principle in systems design.

However, my main point is that the drawbacks of confusion outweigh the benefits of consistency.

---

I think that if you would like to continue this discussion, we should continue this on Twitter - we are not adding much more than noise to the other participants here at this point.

I've opened a placeholder tweet in case you do: https://twitter.com/karlhorky/status/1177967760183382018

[kof]

W3C CSS Modules

[justinfagnani]

The feature matters far more than what we call it, so if anything here is a blocker then let's change that.

However, as I said before, I'm not sure what else you would reasonably call this feature. "CSS modules" is not so much a name as simply a description of the feature. It's in line with the other module types, all of which describe what is imported:

• Importing JavaScript = JavaScript modules
• Importing JSON = JSON modules
• Importing WASM = WASM modules
• Importing HTML = HTML modules
• Importing CSS = ??? modules

It's unfortunate that there's a name clash, but I do also think it's unfortunate that the CSS Modules project named itself something so generic that would pretty obviously be used to describe a similar feature natively in the platform. I think it would be similar to a project naming itself "Async Functions" or "Iterables" or a UI library naming itself "Components". Again, "CSS modules" is less of a name and more of a description of the thing, and multiple things could fit that description.

"styles" and "CSS" are somewhat synonymous these days, so I suppose we could call them "style modules", but I think plenty of people will still just call them "CSS modules" - I think it's essentially too obvious and easy not to. I do think that in cases where it's ambiguous that some people will clarify by adding "standard" or "W3C" as @kof suggests.

[calebdwilliams]

Yeah, the CSS Modules library squatted not only on a name, but also on syntax. There's a reason why import is a reserved word and any project squatting on that syntax implicitly accepts that their syntax might interfere with the platform moving forward.

Is it unfortunate? Yes, but then again, I shouldn't create a feature that uses the implements keyword even though it isn't currently used in JS and expect that the implementation details (no pun intended) won't change in the future. The CSS modules library kind of broke the contract. I don't mean that to be vitriolic or disrespectful, I really enjoy using that library, it was just a bad choice of a name.

[brendanfalkowski]

Frontend developer here. I wouldn't mind if native specs actually kept the same naming as a widely used library. Most of the time it's the opposite and the standardized name is worse IRL (sorry, CSS custom properties) but with a really great explanation why.

If we choose to use web components someday and it conflicts with a project that already uses the CSS modules library, then that's ok. There will probably be a way to transpile the old to new code. None of this works without a constantly maintained build + dependencies, but I understand if the standards process requires that no toes are stepped on if it could break the web.

Tough call. I suppose CSS modules could adapt to the spec's use of reserved words if they were engaged (what @stubbornella said).

— — — — — — — — — —

Aside, I've never liked using the terms styles or stylesheets when I had an option to say or write CSS. It reminds me too much of the old majority that viewed CSS developers as decorators.

So a project we inherit components from writes: import styles from './button.css';

And we tend to prefer: import css from './button.css';

If I didn't have to name the import at all (which I wouldn't 99% of the time in a component) then I would prefer it be available as css. Styles would make me die a little inside.

[keithjgrant]

Yeah, the CSS Modules library squatted not only on a name...

They did not "squat" on a name 🙄. They choose a very fitting name for their product—Several years ago, at that. It is now firmly established in the community under that name.

Releasing anything else under that name is going to be supremely confusing. (Not to mention petty)

[tilgovi]

There are two separate issues I'm seeing, if it's useful to have this reflected by an observer:

1. Is the naming confusing?

I believe the answer to this question lies in deciding whether the two approaches are aimed at the same use cases. If so, great! The platform is evolving in the direction people want. If these are wildly different, wholly incompatible, then it may make sense to imagine another name as it would be surprising if the same description applied to two very different things.

2. Are the authors of the existing project aware of and included in this conversation?

This work should be only a positive thing for the authors and maintainers of the CSS Modules project who are now not only responsible for inspiration and prior art, but also on a path towards being able to target a platform that provides out-of-the-box support for some of what they're doing. This can only be a problem if they feel the work here falls short of what they want and that they had no input.

Can anyone speak to these things specifically? Is there (at least a sub-set of) the CSS Modules project that is directly, deliberately, and similarly covered here, such that it really does refer to more or less the same thing? Are the authors and maintainers of the CSS Modules project aware of this work, this thread, our hand-wringing, and do they feel invited, or what can we do to make them feel so?

[dfabulich]

My impression is that the original CSS Modules project is basically finished. There's no reply from the maintainers to this issue on their repo. https://github.com/css-modules/css-modules/issues/329

[markdalgleish]

Hey all. CSS Modules co-creator here.

CSS Modules as a community spec was very deliberately designed to be pretty static, so the activity on the CSS Modules repo is not a good representation of its real world support.

Instead, you should refer to its living implementations which are still actively supported, most notably:

• webpack's css-loader — 5,816,684 weekly downloads
• Create React App — 1,042,267 weekly downloads
• postcss-modules — 179,351 weekly downloads

[benschwarz]

Importing JavaScript = JavaScript modules Importing JSON = JSON modules Importing WASM = WASM modules Importing HTML = HTML modules Importing CSS = ??? modules

[…] I do also think it's unfortunate that the CSS Modules project named itself something so generic that would pretty obviously be used to describe a similar feature natively in the platform.

As far as I'm aware none of these module systems existed when CSS Modules was designed, built or conceived. Questioning them 4 years later why they named it that way is disrespectful.

CSS Modules is an immensely popular project as both @markdalgleish and I have demonstrated.

If you forge on without changing the name, then you'd be willingly ignorant of the future problems you're knowingly creating for developers trying to implement CSS Modules.

IMO, that's worth avoiding.

[justinfagnani]

Questioning them 4 years later why they named it that way is disrespectful

There was no disrespect intended, nor do I think having the opinion that the name choice was unfortunately very generic is in any way disrespectful.

[gregwhitworth]

Ok, I think we've gone full circle at this point and I want to thank you all for the data regarding the CSS Modules project. Ultimately, I think we all want the same thing:

1. A descriptive name of what the API will do
2. Not be too long
3. Limit author confusion

Finally, since the recommendation of a name change is editorial only and has no API implications I recommend changing the name to Stylesheet Modules. If, V2, as noted above can try and help solve scoping issues within CSS utilizing modules then the name can easily change in the future.

I am going to close this issue since the points have been made; but I ask that someone that has the capability - add the "needs consensus" label to this issue and have it discussed at the next WC face-to-face/telecon.

Based on the above comments, even if they were jokes or not here are the naming suggestions:

1. Style Modules
2. StyleSheet Modules
3. CSS Modules
4. W3C CSS Modules
5. Modular CSS
6. CSS style sheet module script

[web-padawan]

There are 2 problems here, IMO:

Term for SEO is needed

Speaking about "CSS with zero tools", as opposed to "CSS produced by tools" (preprocessors / plugins), people usually name it "vanilla CSS", same as we use "vanilla JS" vs frameworks.

So I would recommend to use the following name in blogs, articles etc for SEO:

Vanilla CSS modules

And of course, specification should name the thing what it actually is: "CSS modules".

Library positioning adjustment

I strongly recommend to rename CSS modules to something like "CSS hashes". Also, its positioning should be adjusted so at least this (very questionable) statement

No global scope.

Would be realistically re-phrased as follows:

Global scope with generated CSS class names.

[annevk]

I'm going to reopen this issue as closed issues aren't tracked.

@gregwhitworth note that any name we end up with will end with "script" at least per the last round of discussions around this. It's also "JSON module script", "JavaScript module script", etc. Those are the only terms appearing in the HTML Standard. (There's no dedicated "CSS modules" standard. It's an enum value in the HTML Standard with a processing model for turning a resource into a CSSStyleSheet object.)

[justinfagnani]

In https://github.com/whatwg/html/pull/4898, which is the actual PR that proposes adding this feature, all references except one are to "CSS module script". So, as @annevk points and, as far as I can tell, the feature already isn't called "CSS modules".

Can we either:

1. Change that one reference to be "CSS module script", or
2. Change all references to be "Cascading Style Sheet module script"

As well as update the all references in explainer and all the relevant issues we can find, and move on from this?

[dfabulich]

Big +1 to "CSS module script". I think if anyone tried to formalize it as "Cascading Style Sheet module script," people would naturally just abbreviate it to "CSS module script" anyway.

[gregwhitworth]

feature already isn't called "CSS modules"

This was the point I was trying to make when I said this "since the recommendation of a name change is editorial only and has no API implications"

As well as update the all references in explainer and all the relevant issues we can find, and move on from this?

Yep, yep.

@stubbornella @benschwarz @keithjgrant @markdalgleish @tilgovi @brendanfalkowski @karlhorky @mkay581 @thepassle @matthewp

Mind casting your vote for 1 or 2?

1. CSS module script
2. Cascading Style Sheet module script

[matthewp]

CSS module script

[markcellus]

Sorry, am I missing something? We've gone from discussing the naming to adding "script" to all of the modules? I just think the term "script" is misleading. Importing a css file with contents that are valid css don't scream "script" to me. Does this mean we're going to change ECMAScript modules to "ECMAScript module scripts" now too?

[justinfagnani]

@mkay581 JavaScript modules are already called "JavaScript module scripts" in the HTML spec: https://html.spec.whatwg.org/#module-script

[markcellus]

Yeah but the ECMAScript standard describes them as "modules" (no script). I realize its a different spec but my main point is this:

"Scripts" makes sense if what we're importing is actually a script. But we're talking about css here, right? I admit that I'm not too familiar with the reasoning behind why we've decided to use "script" for everything, but it seems weird to call the css that we're importing into a file a "module script".

I may be derailing from the conversation though so I'll just wait to hear if others want to chime in. But I just don't feel comfortable voting on something that I think will just add to the confusion 😄. Whatever you all decide, we'll all just have to deal with and adjust I guess 🤷‍♂

[dfabulich]

ES modules, JSON modules, and these new CSS module scripts are called "module scripts" because they are a "type of script" in the specification's sense. https://html.spec.whatwg.org/#concept-script

Note that when importing CSS in JS, you get back a scriptable object; the polyfill for CSS module scripts literally transforms the CSS into CSSStyleSheet in JS, and exports the result.

So, yeah, I don't think we would have picked "CSS module scripts" as a name if "CSS modules" hadn't come first, but this is an excellent compromise in light of what came before.

[benschwarz]

I may be derailing from the conversation though so I'll just wait to hear if others want to chime in.

On this point, I feel the same. My role in this was to raise what I realised was a potential clash.

A clash that will result in the CSS Modules community having to deal with a problem, not of their own creation, that could be easily avoided.

I don't want to make suggestions for what you should or shouldn't do with your project… I just want this specification do to the right thing by a very well established open source project.

[gregwhitworth]

We've gone from discussing the naming to adding "script" to all of the modules?

Thank you so much for voicing your opinions. The reason we're trying to get to a conclusion is that historically naming discussions can go on forever and since the goal is to update the specs with a name that removes the naming conflict with CSS Modules project but still represents what the API does.

I may be derailing from the conversation though so I'll just wait to hear if others want to chime in.

@benschwarz @mkay581 nah, don't worry about this - thank you so much for taking the time to chime in.

[karlhorky]

@gregwhitworth fwiw I like your suggestion above "StyleSheet Modules".

Simple, descriptive, to the point, uses existing terms, not ambiguous.

[brendanfalkowski]

@gregwhitworth "CSS module script" seems fine, given this affects the specification only (i.e. docs) and subsequent writing about the spec. I have high confidence that implementors and first-adoptors will write blogs about this with introductions like this — because these people are good citizens and make the web better:

CSS module scripts (inspired by but not to be confused with CSS Modules [link]) are...

I love the name because:

1) It's passably different short-term, while the distinction has to be made.

2) The phrase will absolutely collapse from CSS module scripts to CSS modules long-term, and that feels like the polyfill-to-standard succession we deserve.

Having said that "StyleSheet Modules" would accomplish (1) and (2) also. Maybe better, it would be less confusing short-term. But eventually, I'll just be saying it CSS Modules meaning "the standard".

[stubbornella]

I like your suggestion @gregwhitworth, "StyleSheet Modules".

[cherscarlett]

I like @gregwhitworth's suggestion for "StyleSheet Modules". It makes the most logical sense as that is what it is. C in CSS is for "cascading". It doesn't make a ton of sense to me to keep the C as this is for modularizing the stylesheets to essentially bypass the Cascade. I agree that it would also ensure that it would not be confused with CSS Modules.

[giuseppeg]

My two cents, (reporting what I said to @stubbornella on Twitter)

picking StyleSheet would make the intent more explicit I guess. CSS Modules export references to scoped selectors whereas standard modules would export a constructible stylesheet right?

Otherwise the only reason why the name "CSS Modules" is appealing to me is

1. the name
2. might be more "flexible" and fit new features in the future (e.g. if the w3c implements a standard module system where you can export scoped references)

@cherscarlett fwiw when registered, the stylesheet is a regular stylesheet with CSS and Cascade applies. At the moment the w3c is only proposing a module system to distribute stylesheets, no scoping involved.

[justinfagnani]

@cherscarlett

this is for modularizing the stylesheets to essentially bypass the Cascade

I want to point out that this doesn't effect the cascade in any way. This is just for importing a stylesheet via the module system. Once you apply it it participates in the cascade as any other stylesheet.

[trusktr]

Regarding

"CSS module script"

CSS isn't a script, at least not the way the average web developer thinks of "script". The "module script" terminology can remain in the specs, but outside of the specs I think users need a friendlier more intuitive name like CSS Modules originally was.

What about

[trusktr]

CSS Style Modules

[trusktr]

or

Cascading Style Sheet Modules

[trusktr]

?

I made multiple comments to allow voting per comment.

Both are better for SEO than CSS Modules, and remain close in meaning to the original, without confusing wording like "script".

[franktopel]

From a veteran frontend developer: Honestly I don't care how popular any library is, or for how long it has been sitting on a name. All the alternatives suggested - and how much they suck - clearly show that the library must step back here and rename their project. Standards - and consistent naming in standards - is way more important than any third party stuff, no matter how popular it is.

Anything other than CSS Modules as a name for the W3C Standard seems unacceptable to me.

Remember we're not talking "break the web" like was the case in the Array.prototype.flatten story. We're just asking for a popular library to rename their project. Honestly, I don't even find their name very fitting for what it does (which to my understanding is rather "Scoped CSS" - another very generic name that I wouldn't advise either).