
The best CSS styleguide for huge applications - grvcoelho
https://github.com/grvcoelho/css
======
pan69
There seems to be a bit of opinion and a bit of BEM [1] in this style guide.

Personally I have been using BEM for larger projects and in that context it
works quite well.

[1] [https://en.bem.info/articles/why-bem-in-a-
nutshell/](https://en.bem.info/articles/why-bem-in-a-nutshell/)

~~~
grvcoelho
Yep! It's an ~opinionated~ steguide!

But I do cover some other poj ts before BEM ;)

------
meesterdude
I love the crap out of CSS, but a lot of these points are just opinion, and I
would not recommend this guide to anyone who wants to write more maintainable
CSS.

Things like calling it "the best" and having "right" and "wrong" in the
examples are really just arrogant and not grounded in anything solid. In CSS,
there is no right/wrong, thats the point. CSS is not black & white, it's
flexible.

It's not all bad, of course; things like the spacing between the colon of a
definition I thought were self evident.

> CSS rules should be comma separated and leave on a new line

Wat. Ok, sure, you CAN do that. And if you have complex selectors, you should.
but for "a,img" theres no clarity gained by new lining them.

> Rule declarations should have one property per line

Generally yes. But there are times when a one-liner is clearer and easier to
comprehend.

> Do not nest elements.

Do not listen to this! The author is correct that this can lead to over
specificity, and that is certainly something you should be aware of. But it
also lets you do things like not have to put classes on everything, and focus
more on what makes semantic sense in the HTML. Personally, i go two to three
levels; still allows for flexibility (like moving an article to be within a
div) while letting you easily scope out everything having to do with a
particular element and it's children. and code folding!

> You should use single quotes as it is visually clearer that the string is
> not a selector or a style property.

I agree with this; you should, it's clearer, and allows for syntax
highlighting to make it easier to spot.

Anyway, the best CSS is CSS you can understand, refactor, and expand upon.
What CSS and CSS processors allow for is a lot of flexibility that can be
abused if you're not careful, or very powerful if you know what you're doing.
We are all students of CSS, still trying to figure out what is a good idea and
what is not. Take everything with a grain of salt.

Take what is useful from this for you, discard the rest. But don't count it as
gospel. For those of us who've been around CSS, this is probably obvious; but
for people just picking it up, I would discourage latching onto this as
definitive.

If I was the author: i would actually give this a name. like "super totally
awesome CSS" or something. then you can make sweeping right/wrong judgements
and any other style declarations you want, because they are contextual to a
specific philosophy and school of opinion. Like google's material design does.

~~~
grvcoelho
Hello there! Awesome feedback :)

Although perhaps I exaggerated the name of this thread (sorry, I'm new here),
the repository DOES say it's an opinionated guide!

Also, these are not rules, these are my guidelines and recommendations!

When I say right or wrong, I mean based on the styleguide itself!

Tks for the feedback!

------
TheBiv
>>Quotes are optional in CSS. You should use single quotes as it is visually
clearer that the string is not a selector or a style property.

/ * wrong * / .avatar { background-image: url('/img/you.jpg'); font-family:
'Helvetica Neue Light', Helvetica Neue, Helvetica, Arial; }

/ * right * / .avatar { background-image: url(/img/you.jpg); font-family:
Helvetica Neue Light, Helvetica Neue, Helvetica, Arial; }

It looks like their right/wrong answers are opposite

Edit: It has now been changed, thank you OP! Great list!

~~~
grvcoelho
TKS and FIXed

------
juddlyon
This guide is quite good. However I don't see the harm in using nesting and
ampersand selectors when using a preprocessor. I feel like knowing that the
specificity is precise has saved me from worrying about collisions. Extracting
the styles to make them more generic is no big deal, to me it's better than
naming things like my-rad-class_____descendant-----sibling__-attribute.

~~~
grvcoelho
In my experience using the "&" has lead to many mistakes and a difficulty to
mantain things.

------
CM30
Isn't stuff like leaving out comments kind of redundant if you use Sass or
Less?

Just use one of those and have them auto strip out CSS comments. That way, the
developers can figure out how stuff works from the well formatted .scss files
and get the performance benefits from the minified .css ones.

Also, was kind of surprised to see no mention of CSS preprocessors in this
guide.

~~~
grvcoelho
About comments: your CSS shouldn't need it!

About preprocessors: the styleguide was created to be preprocessor-agnostic.
Also, I suggest using Postcss instead.

~~~
CM30
Thanks for the explanation about preprocessors and such.

But CSS not needing comments? That's a nice thought, but it kind of becomes
awkward in a large organisation with a massive development team. Like the kind
you need to develop the large applications mentioned in the post title. I mean
sure, it would be ideal if your CSS was so easy to read that any future
developer could figure out what everything referred to in an instant. But for
something like say, Facebook, or Google, or Amazon, it seems rather unlikely
that someone new to the team can figure out why every single CSS rule was
implemented in the way it was or where each class refers to without some sort
of help. Strip out comments, and what's left? Someone walking them through the
entire CSS structure of the site? A couple of days in the web inspector? An
actual manual?

~~~
grvcoelho
The only case I think it's okay to use comments is for browser-specific hacks
or a set of rules that is hard to understand. But I would avoid these cases if
I could!

------
goodoldboys
This guide is spot on, especially the rule about only nesting pseudo elements.
Don't know how many times I've come across nested sass/less that is just
impossible to navigate...

~~~
grvcoelho
tks! the nesting topic is the most polemic, but also the most important to me
:)

------
gprasanth
Saw this earlier today:
[https://github.com/rstacruz/rscss](https://github.com/rstacruz/rscss)

~~~
grvcoelho
It uses some examples like

.search-form { > .submit {} }

which generates this:

.search-form > .submit {}

which can lead to some performance issues :)

That's why I suggest the non-nesting approach

~~~
taco_emoji
I'm confused... the performance issue is with the > selector, right? What does
nesting have to do with that?

~~~
grvcoelho
[http://stackoverflow.com/questions/5797014/why-do-
browsers-m...](http://stackoverflow.com/questions/5797014/why-do-browsers-
match-css-selectors-from-right-to-left/5813672#5813672)

tl;dr browsers read css property right-to-left. the more specificity a
selector has, the more DOM lookup the browser needs to do.

