The best CSS styleguide for huge applications | Hacker News Reader

The best CSS styleguide for huge applications

github.com

30 pointsgrvcoelho24 comments

Open articleView on HN

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/

Yep! It's an ~opinionated~ steguide!

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

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.

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!

>>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!

TKS and FIXed

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.

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

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.

About comments: your CSS shouldn't need it!

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

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?

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!

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...

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

Saw this earlier today: https://github.com/rstacruz/rscss

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

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

http://stackoverflow.com/questions/5797014/why-do-browsers-m...

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

Could you explain the performance issue and provide (or point to) an example showing how to do this correctly?

see above :)

I see the issue of specificity, but instead of writing this .search-form { > .submit {} }, wouldn't you write this as .search-form { .submit {} }, and this would compile to .search-form .submit {}? I don't see the issue with nesting itself -- it still seems like the choices of the programmer are at fault in this case?

The problem is not with the ">", but with the specificity in general!

The selector ".search-form .submit" has 2 levels if specificity. What I suggest is using 1 level of specificity like ".search-form__submit"

Nesting is guilty here because of the ease it is to use it wrongly and create selectors with high levels of specificity

Finally, I understand! Thanks!

No probs ;)

Reply on news.ycombinator.com