Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Architecting Scalable CSS

Harry Roberts
April 24, 2013

Architecting Scalable CSS

Architecting Scalable CSS at Industry Conf, Newcastle. April 2013.

Video: https://vimeo.com/67544231

Harry Roberts

April 24, 2013
Tweet

More Decks by Harry Roberts

Other Decks in Design

Transcript

  1. Architecting
    Scalable CSS
    Harry Roberts
    Industry Conf – April, 2013

    View Slide

  2. View Slide

  3. Planning and writing
    CSS in a way that will
    allow it to scale,
    similar to how an
    architect might.

    View Slide

  4. View Slide

  5. Who?!
    •Harry Roberts
    •Developer, front-end architect
    •Not a police-murdering serial killer
    •@csswizardry
    •csswizardry.com

    View Slide

  6. Seriously.

    View Slide

  7. Who?!
    •Harry Roberts
    •Developer, front-end architect
    •Not a police-murdering serial killer
    •@csswizardry
    •csswizardry.com

    View Slide

  8. View Slide

  9. View Slide

  10. Break it down!

    View Slide

  11. LEGO
    •Break code into the smallest little
    blocks possible.
    •Lots of blocks are far more versatile
    than whole structures.
    •Blocks can be combined with all other
    types of block.

    View Slide

  12. Failing to plan is
    planning to fail.
    — The same people who say ‘I told you so’

    View Slide

  13. The house
    that devs built

    View Slide

  14. •Built in months, lasts for years.
    •Numerous workers with different skills.
    •Built by some, maintained by others.
    House vs. website

    View Slide

  15. •Foundations: reset, normalize.css
    •Structure: grid system, layout
    •Fittings: components, modules
    •Decoration: design, ‘look-and-feel’
    •Ornaments: theming, takeovers, skins
    House vs. website

    View Slide

  16. View Slide

  17. css/
    vars.scss
    aluminium/
    aluminium.scss
    generic/
    base/
    objects/
    gui/
    style.scss

    View Slide

  18. •Jonathan Snook
    •@snookca
    •smacss.com
    •Promo: YOUREAWIZARDHARRY
    SMACSS

    View Slide

  19. View Slide

  20. •Everything should do one thing, one
    thing only, and one thing well.
    •Allows for greater amounts of
    combinations of smaller things.
    •The basis of Unix.
    Single responsibility
    principle

    View Slide

  21. # Find files in current dir with
    # png in the title and reverse
    # sort them by month.
    $ ls | grep "png" | sort -Mr

    View Slide

  22. # List all running processes and
    # search them for "ssh".
    $ ps -ax | grep "ssh"

    View Slide

  23. •Lots of smaller, single instances.
    •Bits can be added or omitted with ease.
    •Easily combined for different results.
    LEGOSubwayHouse

    View Slide

  24. ...
    ...

    View Slide

  25. •If a thing does three separate jobs, it
    needs three separate hooks.
    •Allows you to stay more granular.
    •Build more combinations more quickly.
    •Keeps CSS’ size down.
    More classes

    View Slide

  26. More classes means
    more to maintain.
    — Every developer everywhere ever

    View Slide

  27. About that…

    View Slide

  28. •Changing a dozen classes in your HTML
    is a lot simpler (and nicer) than picking
    apart a tangled stylesheet.
    •Use tools (command line (grep, sed,
    etc.), global find and replace, etc.) to
    help you.
    1. HTML is simple

    View Slide

  29. •Why are things repeated so much
    anyway?
    •DRY out your HTML as well as your CSS.
    2. DRY your markup

    View Slide

  30. 3. It’s your job.

    View Slide

  31. •As a developer you are expected to
    maintain and work with code; why get
    so scared by the idea?
    •Embrace ways to make it easier.
    •Split the load between HTML and CSS.
    It’s your job…

    View Slide

  32. •Keep it low.
    •Always.
    •Classes are ideally suited to the
    granularity of SRP.
    •No IDs.
    Specificity

    View Slide

  33. But IDs mean that
    I can spot unique
    elements in HTML!
    — A lot of developers, still

    View Slide




  34. View Slide

  35. Music is the space
    between the notes.
    — Claude Debussy

    View Slide

  36. CSS is all the same
    .foo{
    float:left;
    color:#BADA55;
    border:0 solid #C0FFEE;
    border-width:1px 0;
    }

    View Slide

  37. }…{

    View Slide

  38. .foo{
    /* Whatever... */
    }
    /* Important bits! */
    .bar{
    /* Booooring! */
    }

    View Slide

  39. •Block: a discrete component
    •Element: a part of that component
    •Modifier: a variation of that component
    BEM

    View Slide

  40. BEM
    .person{}
    .person__hand{}
    .person--female{}

    View Slide










  41. View Slide










  42. View Slide

  43. •Split code into smaller chunks.
    •Quickly reorder and rejig things.
    •Easily [ex|in]clude things.
    •Make code DRYer.
    Preprocessors

    View Slide

  44. •Plenty of them.
    •Document anything that isn’t obvious
    from the code alone.
    •Explain what, how and why.
    Comments

    View Slide

  45. /**
    * Comment title
    *
    * Longer description of the
    * code goes here.
    *
    * 1. Contain floats.
    */
    .foo{
    overflow:hidden; /* [1] */
    }

    View Slide

  46. Clean house,
    clean mind.
    — Mothers

    View Slide

  47. Keeping clean
    •Consistent formatting.
    •Loads of whitespace.
    •Plenty of comments.
    •You can make bad code look good.

    View Slide

  48. .foo{
    color: red; background:green;
    display:block ;
    -webkit-border-radius:4px;
    -moz-border-radius:4px;
    border-radius:4px;
    }

    View Slide

  49. .foo{
    color:red;
    background:green;
    display:block;
    -webkit-border-radius:4px;
    -moz-border-radius:4px;
    border-radius:4px;
    }

    View Slide

  50. Housekeeping
    •Factor in tidy-up and refactor time to
    any feature estimates.
    •Regularly create tech tasks to maintain
    and tidy up your codebase.
    •It’s not just about shipping new code,
    it’s also about looking after the code
    you already have.

    View Slide

  51. shame.css
    •Hacks
    •Short term fixes
    •Tech debt
    •$ git blame shame.css

    View Slide

  52. Don’t stress
    •Nothing is 100% right first time.
    •Things get worse as time progresses.
    •You can’t do better than your best.
    •Stop caring too much; it’s just code.

    View Slide

  53. tl;dr
    •One job, one job only, one well.
    •Keep specificity low.
    •Run a tight ship.
    •Keep on keeping on.

    View Slide

  54. Fin.
    •Harry Roberts
    •smacss.com | bem.info
    •csswizardry.com
    •@csswizardry

    View Slide