$30 off During Our Annual Pro Sale. View Details »

@mdo-ular CSS

@mdo-ular CSS

Ten guidelines for how and why I write CSS the way I do with practical examples. Presented March 6th at jQuery UK.

Also presented at The MIxin meetup in San Francisco on June 3rd.

Mark Otto

March 06, 2015
Tweet

More Decks by Mark Otto

Other Decks in Technology

Transcript

  1. @mdo-ular CSS
    Ten guidelines for how I write CSS

    View Slide

  2. Simple class structure
    I.

    View Slide

  3. • Classes over everything else
    • Dashes separate important keywords
    • Obvious, not clever
    • No chaining

    View Slide

  4. // Basic class structure
    .component {}
    .component-modifier {}
    .component-subcomponent {}
    .component-subcomponent-modifier {}

    View Slide

  5. // In practice…
    .btn {}
    .btn-lg {}
    .btn-primary {}
    .tabs {}
    .tabs-link {}

    View Slide



  6. ...


    ...

    View Slide

  7. Identifiable classes
    II.

    View Slide

  8. • Avoid common keywords
    • Abbreviate, but don’t create a new language
    • Balance search-ability and readability

    View Slide

  9. // Not so good
    .button {}
    .header {}
    // Better
    .btn {}
    .site-header {}

    View Slide

  10. Base classes & prefixes
    III.

    View Slide

  11. • Isolates common styles
    • Prefixes and modifiers handle variance
    • Avoids collisions with similar components

    View Slide

  12. // Specific use cases
    // Not so good
    .danger {}
    .btn.danger {}
    // Better
    .text-danger {}
    .btn-danger {}

    View Slide

  13. // Suite of classes
    // Shared styles
    .btn {}
    // Variations
    .btn-primary {}
    .btn-danger {}

    View Slide

  14. Minimize overrides
    IV.

    View Slide

  15. • Avoid shorthand
    • Rely on those modifier classes
    • Build for re-use

    View Slide

  16. // Not as good
    .element {
    margin: 20px 0;
    }
    // Better
    .element {
    margin-top: 20px;
    margin-bottom: 20px;
    }

    View Slide

  17. Keep it CSS-y
    V.

    View Slide

  18. • CSS isn’t a programming language
    • Preprocessing clouds vision
    • Stick to variables, nesting, and mixins

    View Slide

  19. // Consider this…
    .custom-btn {
    @extend .btn;
    margin: 20px auto;
    .container & {
    padding: 10px 20px;
    }
    }

    View Slide

  20. // Requires .btn base class
    .custom-btn {
    margin: 20px auto;
    }
    // Large buttons for landing pages
    .custom-btn-lg {
    padding: 10px 20px;
    }

    View Slide

  21. Minimize nesting
    VI.

    View Slide

  22. • Usually unnecessary
    • Mostly used for increasing specificity
    • Makes code more fragile

    View Slide

  23. // Good nesting
    .btn {
    &:hover {}
    &:active {}
    }
    // Bad nesting
    .parent {
    .child {
    .element & {}
    }
    }

    View Slide

  24. Formatting matters
    VII.

    View Slide

  25. Every line of code should appear to be written by a
    single person, no matter the number of contributors.

    View Slide

  26. // Property order
    // http://codeguide.co
    .element {
    // 1. Positioning
    // 2. Box model (display, float, width, etc)
    // 3. Typography (font, line-height, text-*)
    // 4. Visuals (background, border, opacity)
    // 5. Misc (CSS3 properties)
    }

    View Slide

  27. // Not so good
    .selector,.another-selector {
    padding:15px;
    margin:0px 0px 15px;
    background-color:rgba(0,0,0,.5);
    box-shadow:0px 1px 2px #CCC,inset 0 1px
    0 #FFFFFF;
    }

    View Slide

  28. // Better
    .selector,
    .another-selector {
    padding: 15px;
    margin-bottom: 15px;
    background-color: rgba(0,0,0,0.5);
    box-shadow: 0 1px 2px #ccc,
    inset 0 1px 0 #fff;
    }

    View Slide

  29. Document guidelines
    VIII.

    View Slide

  30. View Slide

  31. View Slide

  32. View Slide

  33. Embrace utility classes
    IX.

    View Slide

  34. • Single purpose
    • Immutable declarations and values
    • Obvious nomenclature

    View Slide

  35. .left { float: left; }
    .right { float: right; }
    .text-danger { color: red; }
    .text-success { color: green; }
    .text-warning { color: orange; }

    View Slide

  36. .muted-link {
    color: #777;
    &:hover {
    color: #4183c4;
    text-decoration: none;
    }
    }

    View Slide

  37. [hidden] {
    display: none !important;
    }

    View Slide

  38. Automate and track CSS
    X.

    View Slide

  39. • Linters and validators
    • CI tools with GitHub
    • Grunt and Gulp
    • Stats and reporting

    View Slide

  40. × Failed — 1 failed and 3 successful checks

    View Slide

  41. $ rake assets:stats
    +-----------------------+-----------+---------------+-------------+
    | Bundle Stats |
    +-----------------------+-----------+---------------+-------------+
    | name | selectors | minified | +gzip |
    +-----------------------+-----------+---------------+-------------+
    | frameworks.js | 24 | 743.39 KB | 189.10 KB |
    | github.js | 636 | 562.11 KB | 127.63 KB |
    | github2.css | 3232 | 293.85 KB | 48.26 KB |
    | github.css | 2872 | 250.29 KB | 44.42 KB |
    | mobile.js | 40 | 125.94 KB | 37.32 KB |
    | mobile.css | 1336 | 106.14 KB | 19.26 KB |
    +-----------------------+-----------+---------------+-------------+

    View Slide

  42. # Parker Report
    - Total Stylesheet Size: 3.0598kb
    - Total Media Queries: 1
    - Total Rules: 403
    - Total Selectors: 581
    - Total Declarations: 999
    - Total Unique Colors: 79
    https://github.com/katiefenn/parker

    View Slide

  43. View Slide

  44. Bottom line?

    View Slide

  45. • Simplicity conquers all
    • Focus on what’s between the curly braces
    • Document and evolve guidelines with your team

    View Slide

  46. Thanks, nerds!

    View Slide