ember-component-css 1.0 game plan

Note: This issue is a WIP, it will be updated over time

---

I wanted to start collecting my thoughts and gather feedback from the community for ember-component-css 1.0.

Here are some of the high level plans:

• Support classic & future modules RFC file structures
• Auto-BEM
• Linting
• Shadow DOM forward compatibility
• JS module API

Support classic & future modules RFC file structures

I think this is self explanatory 😛

Auto-BEM

ember-component-css currently works via automatically nesting your rules underneath a generated class. This was easy implementation wise, but it was never my intent for that to remain the primarily implementation strategy. I instead would like to switch to auto-BEM’ing rules (see http://getbem.com/naming/ for more info). Using BEM naming ensures styles don’t leak outside of the component’s template.

Here’s an example showing input and current / future output.

input:

.foo {}

current output:

.my-component .foo {}

future output:

.my-component--foo {}

(there will probably also be a hash included in the class name)

Linting

We should devise a set of best practices and warn folks when they’ve gone off the happy path. Things that come to mind are using IDs and unsafe descendent selectors.

Shadow DOM forward compatibility

I would like users to be able to turn off auto-BEM’ing if they’re shipping to browsers that support shadow DOM. I would also like to explore being able to generate individualized component CSS builds that can be loaded into component’s shadow roots.

I don’t think I want to polyfill any Shadow DOM functionality, instead I just want to make sure we’re not making any decisions that make it hard to take our styles in the future and use them inside of a shadow root.

JS module API

It would be nice to be able to import CSS files from inside of JS files, ala css-modules. This can be useful for accessing the rewritten/generated class names for usage within JS code.

[buschtoens]

I believe most of the Ember core team believes Sass is the preprocessor we should focus our support on

I would also like to know, why you’ve come to that conclusion. Is it because of the Ruby background? 😛

I would also suggest going for PostCSS, instead of Sass. PostCSS is a JavaScript project. As such, it seems to be more popular in the JS community and it’s easier to extend for the typical frontend developer. Also, if GitHub stars mean anything:

• postcss: 15,523
• sass: 10,190
• libsass: 3,549
• node-sass: 4,069

As far as I’m concerned, PostCSS has full feature parity with Sass. There even are some addons that enable sassy syntax. 🙂

[webark]

@t4t5 ember-component-css has no desire or direction to becoming a sass framework. It in fact uses post-css to do its parsing.

But it also is not a post css plugin, nor does it desire to be, at least at this time.

In the css community there are mixed feelings and attitudes about many things, one being the world of css pre processors and plugin architecture is one of them.

A desire of this addon, at this time at least, is to be convention/preprocessor/plugin agnostic, and be a stepping stone for other solutions to potentially be built off of.

Future (hopeful) support for shadow dom, or even a js module api, would be inline with this desire. Auto BEM support would be something that would live in its own addon (in my opinion).