Class- and id- names uniqueness


Hi Gys,

i am new to ember and planning my new app.

what is the best way to deal with stylesheets?

in rails by example you can link the stylesheets to specific views and if the app grows and you have different views with different stylesheets and similar class-names than there is (maybe) the reload between them and you have no conflict.

but, how is that in a single-page-app?

how do you make sure that you do not use a class-name that is already used in a other stylesheet / view?


or a little tool that checks the stylesheets and warns in that case?

Best regards, Christian


Linking stylesheets / best practice
Module-unification / stylesheets location / best practice


i found a similar discussion:

and a nice tool:, it prefixes the class-names. But at the end i don’t want to have any automatism in class-naming.

the best would be if the IDE wold check for CSS-selectors. There is a issue on IntelliJ. You can vote for it, i think it would be a great help.

for me it seems that the next-steps will be:

  1. Having Style-Sheets beside Template / Components (i am working with Module-Unification)
  2. Have a Prefix, by example “pe-” for the people-Template
  3. Name of the Stylesheet is then: “pe-styles.scss”
  4. All the Stylesheets are collected by “@import ‘…/pe-styles.scss’”
  5. All the classes which are defined in “pe-styles.scss” have the prefix “pe-”

=> with that i have a overview for all prefixes in the main-stylesheet, by the import-steps and a manually namespacing.

For the Future i hope that IntelliJ insert the above mentioned inspector.

What do you think?

Best Regards, Christian



So there are lots of approaches to managing CSS, and there’s really no “best way” unfortunately, both in the broader SPA world and in Ember specifically. In my experience managing css is one of the things that is really hard well to do long term. I’m a little cynical about it though. We’ve had a lot of discussion around it recently at my company and mostly it’s just shrugs.

That said there are some great tools in the ember ecosystem so while I can’t point to one specifically I can recommend a few and you can look at them and see what makes the most sense for you. Hopefully others can weigh as well.

There are a couple addons that deal with what I would call “auto scoping” of CSS. ember-component-css is great for components (and only components). Essentially what it does is automagically create unique classes for each component and apply the correct stylesheet, guaranteeing that the styles are scoped only to the component. ember-css-modules allows you to break up your styles to correspond with your js and hbs files, and it also provides the “local-class” mechanism for scoping your css. These save you the trouble of setting up all the sass imports and class prefixes manually (what we do at my company currently) and that helps keep the styles in sync with the other code. I’m not sure what the status of either of these is in terms of module unification though, especially since MU is changing/delayed.

It appears that you’re already using (or planning to use) sass but I’ll go ahead and note that in addition to ember-cli-sass and ember-cli-less and similar libs there’s also an addon for PostCSS which can be really nice for not only preprocessing but adding other plugins like autoprefixer, etc.

One thing which I’ll also pitch to you as a potential option is functional css. If you’re not familiar with it it’s basically “utility class first” CSS meaning instead of having separate stylesheets you just attach a bunch of utility classes to your HTML markup. It’s controversial but a lot of people (myself included) really love it. Tailwind is probably the most popular functional css lib and ember-cli-tailwind is a fantastic ember integration. This is purely anecdotal but IMHO it makes CSS a lot more fun and maintainable long term (removes the need to name things and keep separate stylesheets and so on). I just made a little demo app and slide deck recently to present to our engineering teams which you can take a look at if you’re interested (the slides are in slides.html, may need to clone the repo to see them correctly).

Anyway if you have any questions on any or all of the above let me know, I’d be happy to dive deeper into any of it.



many thanks, dknutsen!

Tailwind sounds interesting. do i understand it right?: you “wrap” parts of css in a kind of a “virtual class” and you do the same in HTML. Then the classes you defined are inside a scope and are valid only within?



Well tailwind works very differently in that sense, it’s almost the opposite extreme as in your classes aren’t scoped at all and your styles are shared EVERYWHERE. Tailwind classes actually look a lot like inline styles (though they’re much better than inline styles for a number of reasons). Here’s an example from the tailwind docs:

There’s no “scoping” in tailwind because it’s a completely different way of writing CSS. It makes the traditional methods of CSS organization and “uniqueness” more or less unnecessary, because you don’t have stylesheets at all. There’s nothing to “scope” or “organize”. You simply attach styles directly to your markup. That said there’s nothing to stop you from using something like ember-component-css and tailwind together. There are times where you might need to add some “traditional” styles to something where Tailwind just won’t suffice, but those times are pretty few and far between in my experience

Anyway then with ember-css-modules and ember-component-css you have mechanisms for enforcing CSS “scope” because you’re managing your CSS in the more traditional way (actually having stylesheets). ember component css works more like how you just described, by generating a “wrapping class” that is unique and then auto-scoping the css. An example from the ember-component-css docs:

And ember-css-modules is pretty similar but uses the “local-class” attribute instead.

Anyway, ember-css-modules is probably most similar to what you were initially going for, and can save a lot of the work of manual sass imports and manual namespacing. I mostly mentioned tailwind as an alternative to the entire approach of traditional css management. There are certainly some caveats to functional css and some people just hate it, but it kinda sidesteps the entire necessity of a css management strategy to begin with. That was .a little rambly but I hope that all makes sense.

1 Like


We’ve had a lot of discussion around it recently at my company and mostly it’s just shrugs.

Hey, don’t give away our trade secrets!