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

More Decks by Harry Roberts

Other Decks in Design


  1. Planning and writing CSS in a way that will allow

    it to scale, similar to how an architect might.
  2. 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.
  3. Failing to plan is planning to fail. — The same

    people who say ‘I told you so’
  4. •Built in months, lasts for years. •Numerous workers with different

    skills. •Built by some, maintained by others. House vs. website
  5. •Foundations: reset, normalize.css •Structure: grid system, layout •Fittings: components, modules

    •Decoration: design, ‘look-and-feel’ •Ornaments: theming, takeovers, skins House vs. website
  6. •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
  7. # Find files in current dir with # png in

    the title and reverse # sort them by month. $ ls | grep "png" | sort -Mr
  8. •Lots of smaller, single instances. •Bits can be added or

    omitted with ease. •Easily combined for different results. LEGOSubwayHouse
  9. •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
  10. •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
  11. •Why are things repeated so much anyway? •DRY out your

    HTML as well as your CSS. 2. DRY your markup
  12. •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…
  13. •Keep it low. •Always. •Classes are ideally suited to the

    granularity of SRP. •No IDs. Specificity
  14. But IDs mean that I can spot unique elements in

    HTML! — A lot of developers, still
  15. •Block: a discrete component •Element: a part of that component

    •Modifier: a variation of that component BEM
  16. <article class="widget"> <div class="media"> <img src alt class="img thumb"> <div

    class="body"> <h1 class="heading"></h1> <p></p> </div> </div> </article>
  17. <article class="widget"> <div class="media"> <img src alt class="media__img widget__thumb"> <div

    class="media__body"> <h1 class="widget__heading"></h1> <p></p> </div> </div> </article>
  18. •Split code into smaller chunks. •Quickly reorder and rejig things.

    •Easily [ex|in]clude things. •Make code DRYer. Preprocessors
  19. •Plenty of them. •Document anything that isn’t obvious from the

    code alone. •Explain what, how and why. Comments
  20. /** * Comment title * * Longer description of the

    * code goes here. * * 1. Contain floats. */ .foo{ overflow:hidden; /* [1] */ }
  21. 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.
  22. 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.
  23. tl;dr •One job, one job only, one well. •Keep specificity

    low. •Run a tight ship. •Keep on keeping on.