CSS Styleguide

[dereklieu]

We adhere to a styleguide for writing javascript - do we want to adhere to one for writing CSS?

There are a few competing philosophies right now regarding CSS naming conventions. For example: block element modifier, or BEM.

These are all kind of hard to digest or even read. I do recommend reading the trello css guide though.

Overall I think the current Devseed state of the CSS, as far as I've seen, is pretty good in that we're breaking out stylesheets into modules and using preprocessors. I do think there is a good argument against nesting classes, and I often use non-class selectors. I also like the convention of prefixing javascript-specific classes with js- and utility classes with u-.

Would love to hear people's thoughts on this, especially if you write a lot of CSS.

@developmentseed/development-seed

[danielfdsilva]

We used BEM on climatescope and if I recall correctly it was an interesting approach but had some quirks. @ricardomestre can shed some more light on that.

Nesting classes is one of the more powerful features of preprocessors as it allows you to neatly organize and group your code. Of course, you need some common sense and not do .something .like .this .with .lots .of .classes, and avoid stuff like .class #id.

Regarding the js specific classes, I agree with the prefix js- and I've used it before, however I changed to the data-hook attribute.

Quick example:

<a href="#" data-hook="click">Click me</a>

var btn = document.querySelectorAll('[data-hook="click"]');

You can even have multiple actions, just separate them with space.

<a href="#" data-hook="click stick">Will stick</a>
<a href="#" data-hook="click">Will not stick</a>

var btn = document.querySelectorAll('[data-hook~="stick"]');

With this you don't mix styling with interactivity.

My two cents :)

[drewbo]

:+1: to this whole conversation and also data-hooks. I'll read through the rest of the materials you sent, @dereklieu

[anandthakker]

Also wanna :+1: to the conversation overall (thanks for starting it @dereklieu). I don't have particularly strong opinions on any one issue here, but I do think that if we're gonna do this, we should back it up with linter tooling that breaks the build when we fail to conform--and, of course, with editor tooling (for at least vim and atom?)

On Tue, Aug 4, 2015 at 10:40 AM Drew Bollinger notifications@github.com wrote:

[image: :+1:] to this whole conversation and also data-hooks. I'll read through the rest of the materials you sent, @dereklieu https://github.com/dereklieu

— Reply to this email directly or view it on GitHub https://github.com/developmentseed/project-seed/issues/30#issuecomment-127635902 .

[dereklieu]

A quick google search propped up this scss linter which seems to have some options. Downside is that it's a ruby gem, which might be annoying to include in our build process.

I'll keep looking around. For anyone else doing reading into this, I should mention that the other competing style-guides are object-oriented (OOCSS) and SMACSS. Again, these are not necessarily fun reads :zap: but worth looking into when you have a moment.

[drewbo]

Ping. Anyone still have any interest in this?

[dereklieu]

I know @ricardomestre has been thinking a lot about this, or at least about things tangential to this.