Namespace all classes defined in the component's styles.css file

[tbck]

Imagine a nested component with an element that shares the class name of an element in it's parent component, or even uses a class that is also defined in the global application styles. These styles would seep in and cause unwanted results due to the descendant selector.

Namespacing the class itself should ensure that there will be no unexpected style leaking.

By this I mean an .avatar selector should likely be output as .componentNamespace-avatar instead of .componentNamespace .avatar.

[ebryn]

Hey @tbck, I'm aware of this and have some code in the https://github.com/ebryn/ember-component-css/tree/class-for-helper branch to do this.

[dfreeman]

Love it.

@ebryn What's currently holding that branch up from being merged in? If there's anything I can do to help out, I'd be happy to lend a hand.

(Edit: oh, the TODOs in the code might have been a good hint, if I'd looked more closely)

[ebryn]

@dfreeman would love some help to drive this to completion. i've just been very busy doing training since EmberConf. I can provide more specifics if you're serious about helping! :)

[dfreeman]

@ebryn For sure! Happy to use this issue as base camp, or if you have a preferred non-Github medium of communication, just let me know :)

[ebryn]

@dfreeman shoot me an IM: [email protected]

[tonycoco]

This could also be solved by doing something similar to what React Native is doing and just inject the styles into the style attributes directly. Any thoughts on that? I was thinking about this same problem, but utilizing a more JS approach, and less CSS/SASS/LESS approach.

[ebryn]

@tonycoco That is a planned mode

[buschtoens]

@tonycoco @ebryn Regarding the style="<css here>" injection: I'm no expert, but it sounds like this would degrade performance. But as long as this is only one possible mode of many, I have no objections.

[tonycoco]

@buschtoens shouldn't be any degradation of performance. In fact, you get the benefit of no separate requests for CSS and remove the need to pack CSS for a page that you haven't browsed to yet. This is Facebook's current approach to CSS slimming and styling on their React applications.

[Dremora]

I guess performance @buschtoens was referring to is the performance of DOM (adding/removing styles for each element). Using classes used to be faster than inline styles, but it has likely changed — does anyone have more information about the current state of things?

[tonycoco]

See: https://twitter.com/paul_irish/status/583754139571593216

[Dremora]

Then it sounds like a good idea. I'm not sure though if this extension is the best playground for its implementation, as most of existing logic (loading CSS files, namespacing class names) seems redundant for a javascript styling approach. Perhaps a separate (more radical) Ember CLI addon?

[tonycoco]

That's what I was thinking too, @Dremora

[ebryn]

@dfreeman @trentmwillis can one of you rebase / cleanup / add basic tests for the class-for-helper branch? :heart:

[dfreeman]

Was actually mulling over how this might work with preprocessors on the train today. Seems like that may get hairy, but in the meantime getting that branch cleaned up and merged in is a good first step. Should have a chance to dive in on that in the next couple days :)

[ebryn]

Here's an HTMLBars AST transform example @mmun put together that shows how we can rewrite the static class names to their auto-generated names: https://github.com/ebryn/ember-component-css/commit/6decd617d946ae567022265d0dab6aa8d29373c9

[daralthus]

Hey guys, is this something that is going to get merged? The {{class-for}} is a killer feature if you want to use ember-wormhole for example.

[mhluska]

@ebryn did this die off? I'd love to be able to control the generated class names for all classes in a module.