Discourse is using sass. So that’s not really CSS at all, it’s SASS that can be compiled to CSS, and you’ll need to read the SASS documentation about how things like @mixin and nested selectors work.
Sass is totally optional for ember apps, you can also pick another preprocessor or none at all. I also like ember-cli-postcss, which lets you author as spec-compliant CSS, but with transpiled support for older browsers.
There are also addons like ember-component-css that let you have separate stylesheets per component.
We also use Sass (SCSS syntax) and I highly recommend this, as it allows you to split your CSS files up into individual files.
In our app, we are using the traditional folder structure, and so all of our SCSS files are in the app/styles folder. We break them down as follows:
app/styles/base/ - base SCSS files like reset/normalize, fonts/typography, colors, etc.
app/styles/components/ - individual component SCSS files, one per component
shared SCSS will be indicated by name, i.e. component-group-shared.scss
app/styles/page-templates/ - styles that live at the page level
We try to avoid styling at this level, but sometimes it happens.
app/styles/partials/ - SCSS files that do not output any CSS (but not part of base)
this includes mixins or other shared SCSS code that doesn't result in CSS styles directly
Then in our app.scss file (the main file), it only imports other SCSS files. We import files from /partials first (these are usually mixins or similar), then /base (in order they should be applied), then from /page-templates (alphabetical order), then from /components (alphabetical order). There should be no styles directly written in app.scss - this just imports other files in the specified order.
Note about alphabetical imports: the page-template and component styles should be completely independent of each other respectively, by include components after templates it allows component styles to be more specific and override page-template styles. Beyond that, there should be no reason styles in one component interact with styles from another component (or page-template to page-template file), and so the order does not matter for the CSS cascade. Because of this, we’ve adopted alphabetical ordering to reduce the chance of merge conflicts when multiple people are working on the project adding new components.
We structure our CSS to be as flat as possible, trying to start to class-based identifiers and 1 to 2 levels whenever possible. (an example of 2 levels would be .link:hover {...} for example. We accomplish this by using something similar to BEM (block element modifier) syntax.