
Idiomatic-css - joeyespo
https://github.com/necolas/idiomatic-css
======
mappu
For §4 Format, i'm more a fan of aligning any vendor-prefixed properties by
the colon, i.e.

    
    
        .selector-3 {
            -webkit-box-sizing: border-box;
               -moz-box-sizing: border-box;
                    box-sizing: border-box;
        }
    

Much easier to spot any discrepancies between them.

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

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

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

~~~
pygorex
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?

------
gbog
Where I disagree:

End of line comments are very useful when grepping.

No space inside curlies: {a:b; c:d;}

80 chars is not a sensible width, too short.

------
egonschiele
This is what gists are for: <https://gist.github.com>

