What does a little convention get you? A lot, as it turns out.

When following the conventions listed below, the Optimizing CSS Compiler will be able to aggressively optimize, compile and minify your CSS by taking the following steps:

• builds a broccoli tree of handlebars templates and styles
• constructs a graph of all possible style paths in your CSS files
• constructs a new graph of all used style paths in your handlebars files
• compiles css down to the smallest possible set of rules.
• applies those rules to the templates, removing any existing classes
• writes a style sheet containing the rules

• Don't expect this to work (because it doesn't yet)
• Do contribute if you find this neat, ask in #dev-html-next in the Ember Slack
• Componetize your CSS
• Use & for the component root element
• Tag dynamic selectors (things to leave alone) with @dynamic or /* @dynamic */
• Do assume your CSS is scoped by template context (route or component hbs file)

• Everything! (but the basic cases are getting close to working)
• media-queries and breakpoints
• CSS preprocessors
• class names within component.js files (yet! a subset of usage in this pattern will eventually be allowed)
• !important` (it'll still work, you just shouldn't)
• global CSS
• ::pseudo-element and :pseudo-class selectors

• use mixins, not global selectors
• no attr selectors
• no sibling selectors
• no ID selectors
• classed and elements only

Existing scoped and inline style solutions lead to selector bloat and limited style reusability. While the scoping and isolation is a great mental model, it's not as great for the browser, which can better optimize styles it has already seen.

The approach here allows us to write CSS as if it were scoped, and have it behave scoped at runtime as well. But unlike other solutions, you will ship the smallest possible CSS file with the fewest possible selectors.

This has the double effect of reducing the size of your template files by eliminating long and multiple class names in favor of short "sha" based selectors.

This also has the ability to alert you to unused styles in your stylesheet, and to "tree-shake" your dead CSS.

In dev mode, we'll keep your selectors scoped but expanded so you can see quickly what has been applied, while in production we will aggressively minimize and combine your selectors as much as possible.

Not at all. Here's a quick (and contrived) example. Imagine this were ths sum total of the CSS and html in your app:

h1 {
  font-size: 1rem;
  display: block;
  width: 100px;
  height: 50px;
  margin: 0;
  padding: 0;
}

.foo {
  font-size: 1rem;
  width: 100px;
  height: 50px;
  margin: 5px;
}

.bar {
  box-sizing: border-box;
  width: 100%;
  height: auto;
  margin: 5px;
  padding: 5px;
}

.baz {
  color: #f00;
}

<h1 class="foo bar">Hello World</h1>

Looking at this example, we can see that many of our CSS rules are either overridden or redundant.

Given the contrived nature of our example, we also see that we have 3 selectors matching the html in our "app" when we could have used 1. We also have one selector that goes completely unused.

For this example, the optimizing compiler would instead produce the following CSS and DOM.

.s0 {
  display: block;
  font-size: 1rem;
  box-sizing: border-box;
  width: 100%;
  height: auto;
  margin: 5px;
  padding: 5px;
}

<h1 class="s0">Hello World</h1>

No. In addition to referring to the ability to simplify the combined rules for a single DOM element, "optimizing" refers to the ability to intelligently produce the smallest selector graph it can based on the actual usage of various rules in your app.

A contrived example of this extends the above example.

If any other elements use the same "rule set" as s0, they will also use s0.

For the case where another element is just one style prop different from s0, a clustering algorithm based on app usage is used to build a primary selector group, and a modified selector group.

For an example in which one group differs only by a different value for padding-top, something like the following would be produced:

.s0 {
  display: block;
  font-size: 1rem;
  box-sizing: border-box;
  width: 100%;
  height: auto;
  margin: 5px;
  padding: 5px;
}

.s1 {
  padding-top: 10px;
}

The following links are some prior art we should investigate the usefulness of:

• https://github.com/prototypal-io/prius
• https://github.com/prototypal-io/cascada-es6
• https://github.com/prototypal-io/cascada

• git clone <repository-url> this repository
• cd optimizing-css-compiler
• npm install
• bower install

• ember serve
• Visit your app at http://localhost:4200.

• npm test (Runs ember try:each to test your addon against multiple Ember versions)
• ember test
• ember test --server

• ember build

For more information on using ember-cli, visit https://ember-cli.com/.