Change 'CSS Modules' name to avoid webdev confusion #843
Comments
|
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. |
|
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. |
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.
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. |
|
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!! |
|
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. |
|
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. |
|
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? |
|
They should have expected something like this when they picked such a generic name for a custom project. |
|
@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. |
This is a really strange comment and the vitriol behind it is concerning tbh |
|
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. |
@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. |
|
Here's a naming suggestion if y'all do decide to change it: "Modular CSS" |
|
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? |
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?
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...
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 |
|
W3C CSS Modules |
|
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:
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. |
|
Yeah, the CSS Modules library squatted not only on a name, but also on syntax. There's a reason why Is it unfortunate? Yes, but then again, I shouldn't create a feature that uses the |
|
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 So a project we inherit components from writes: And we tend to prefer: 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 |
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) |
|
There are two separate issues I'm seeing, if it's useful to have this reflected by an observer:
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.
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? |
|
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. css-modules/css-modules#329 |
|
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: |
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. |
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. |
|
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:
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:
|
|
There are 2 problems here, IMO: Term for SEO is neededSpeaking 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:
And of course, specification should name the thing what it actually is: "CSS modules". Library positioning adjustmentI strongly recommend to rename CSS modules to something like "CSS hashes". Also, its positioning should be adjusted so at least this (very questionable) statement
Would be realistically re-phrased as follows:
|
|
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.) |
|
In whatwg/html#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:
As well as update the all references in explainer and all the relevant issues we can find, and move on from this? |
|
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. |
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"
Yep, yep. @stubbornella @benschwarz @keithjgrant @markdalgleish @tilgovi @brendanfalkowski @karlhorky @mkay581 @thepassle @matthewp Mind casting your vote for 1 or 2?
|
|
CSS module script |
|
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? |
|
@mkay581 JavaScript modules are already called "JavaScript module scripts" in the HTML spec: https://html.spec.whatwg.org/#module-script |
|
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 🤷♂ |
|
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 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. |
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. |
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.
@benschwarz @mkay581 nah, don't worry about this - thank you so much for taking the time to chime in. |
|
@gregwhitworth fwiw I like your suggestion above "StyleSheet Modules". Simple, descriptive, to the point, uses existing terms, not ambiguous. |
|
@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:
I love the name because:
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". |
|
I like your suggestion @gregwhitworth, "StyleSheet Modules". |
|
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. |
|
My two cents, (reporting what I said to @stubbornella on Twitter)
Otherwise the only reason why the name "CSS Modules" is appealing to me is
@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. |
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. |
|
Regarding
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 What about |
|
|
or
|
|
? I made multiple comments to allow voting per comment. Both are better for SEO than |
|
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 |
|
@trusktr and @franktopel - there's no reason to continue to litigate anything here for several reasons:
I just added a suggestion to whatwg/html#4898 to rename the one reference of "CSS modules" to "CSS module scripts". Are there any other outstanding items, or can we close this issue? @annevk |
|
I believe anyone will be referencing it as "CSS modules" anyway, no matter how you name it. |
|
@franktopel If you'd like to ask https://github.com/css-modules/css-modules to rename themselves, feel free; they have an issue tracker. But beware, I believe no one will reply to your suggestion. Skimming through the repo, I don't think project owners have responded to literally any filed issue there in at least a year. (Why would they? What incentive do they have to change?) They don't even close out bogus issues; all of the closed issues are from filers self-closing their own issues. Maybe you could reach out to @markdalgleish on Twitter? |
|
@justinfagnani thanks for connecting all the dots, let's close this. |
and others
@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:
Any other suggestions are welcome.
The text was updated successfully, but these errors were encountered: