> Take time to describe components, how they work, their limitations, and the way they are constructed. Don't leave others in the team guessing as to the purpose of uncommon or non-obvious code.
One rule I really try to enforce: for any CSS declaration with a non-obvious reason ("position: relative", "z-index: 9999", "zoom: 1", "!important", "display: block" together with "float: left", etc.), it MUST have a comment explaining why.
Which absolutely-positioned child led to this "position: relative"? What is this z-index trying to move this object above/below?
Some people say well-written computer code doesn't need commenting. But with CSS this is NEVER the case.
The commentors complaining that their pet style is not included seem to be missing the point of an idiomatic CSS guide. I have seen the one rule per line in the wild, but it is rare. The CSS the author has shown is fairly representative of what I see in production code.
However, the author should have stuck to plain CSS instead of including the syntax favored by SCSS. Some of the syntax is specific to the later. Single line comments are a particularly egregious example; they can appear to work in vanilla CSS, but that's only because they force a syntax error that makes the parser skips the line. Including such syntax defeats the entire purpose of the guide.
I hate one declaration per line. I wrap at 80ish columns. I can then see all of the CSS for a single page at once on my screen, without paging up and down through some ridiculously long file. It bothers me that idiomatic CSS is so wasteful of vertical space.
I have the exact opposite reaction. It's much easier to scan for and read CSS rules on their own - especially when utilizing "wordy" statements like CSS animations, font and background declarations. And for the various vendor-specific prefixes. And for comments.
Here's a real-world example formatted nicely:
#nav .group LI A {
color: #fff;
text-decoration: none;
display: block;
padding: 4px 0px 4px 4px;
border-top: 1px dashed hsla(0, 0%, 100.0000%, 1.0000);
-webkit-background-clip: padding-box; /* for Safari */
background-clip: padding-box; /* for IE9+, Firefox 4+, Opera, Chrome */
-webkit-transition: all 0.25s ease-in-out;
-moz-transition: all 0.25s ease-in-out;
-ms-transition: all 0.25s ease-in-out;
-o-transition: all 0.25s ease-in-out;
transition: all 0.25s ease-in-out;
}
And as one line:
#nav .group LI A {
color: #fff; text-decoration: none; display: block; padding: 4px 0px 4px 4px; border-top: 1px dashed hsla(0, 0%, 100.0000%, 1.0000); -webkit-background-clip: padding-box; /* for Safari */ background-clip: padding-box; /* for IE9+, Firefox 4+, Opera, Chrome */ -webkit-transition: all 0.25s ease-in-out; -moz-transition: all 0.25s ease-in-out; -ms-transition: all 0.25s ease-in-out; -o-transition: all 0.25s ease-in-out; transition: all 0.25s ease-in-out;
}
Let's say you need to change the border from dashed to solid. Which of these formats is easier to scan for border rules and to edit?
I agree. If a selector has enough rulesets to justify a wrap I usually let the first line be positioning rules, second box-model rules and third color rules and so on. I find that I am much more productive this way VS following the guidelines that idiomatic CSS proposes.
