Architecting Scalable CSS

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

Video: https://vimeo.com/67544231

Transcript

1. Architecting Scalable CSS Harry Roberts Industry Conf – April, 2013
3. Planning and writing CSS in a way that will allow it to scale, similar to how an architect might.
5. Who?! •Harry Roberts •Developer, front-end architect •Not a police-murdering serial killer •@csswizardry •csswizardry.com
6. Seriously.
7. Who?! •Harry Roberts •Developer, front-end architect •Not a police-murdering serial killer •@csswizardry •csswizardry.com
10. Break it down!
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.
12. Failing to plan is planning to fail. — The same people who say ‘I told you so’
13. The house that devs built
14. •Built in months, lasts for years. •Numerous workers with different skills. •Built by some, maintained by others. House vs. website
15. •Foundations: reset, normalize.css •Structure: grid system, layout •Fittings: components, modules •Decoration: design, ‘look-and-feel’ •Ornaments: theming, takeovers, skins House vs. website
17. css/ vars.scss aluminium/ aluminium.scss generic/ base/ objects/ gui/ style.scss
18. •Jonathan Snook •@snookca •smacss.com •Promo: YOUREAWIZARDHARRY SMACSS
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
21. # Find files in current dir with # png in the title and reverse # sort them by month. $ ls | grep "png" | sort -Mr
22. # List all running processes and # search them for "ssh". $ ps -ax | grep "ssh"
23. •Lots of smaller, single instances. •Bits can be added or omitted with ease. •Easily combined for different results. LEGOSubwayHouse
24. <ul class="list products special-offers is-sortable is- sorted">...</ul> <ul class="list stores by- proximity is-sortable">...</ul>
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
26. More classes means more to maintain. — Every developer everywhere ever
27. About that…
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
29. •Why are things repeated so much anyway? •DRY out your HTML as well as your CSS. 2. DRY your markup
30. 3. It’s your job.
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…
32. •Keep it low. •Always. •Classes are ideally suited to the granularity of SRP. •No IDs. Specificity
33. But IDs mean that I can spot unique elements in HTML! — A lot of developers, still
34. <div class="#site-header"> <ul class="nav #main-nav"> <article class="box #post">
35. Music is the space between the notes. — Claude Debussy
36. CSS is all the same .foo{ float:left; color:#BADA55; border:0 solid #C0FFEE; border-width:1px 0; }
37. }…{
38. .foo{ /* Whatever... */ } /* Important bits! */ .bar{ /* Booooring! */ }
39. •Block: a discrete component •Element: a part of that component •Modifier: a variation of that component BEM
40. BEM .person{} .person__hand{} .person--female{}
41. <article class="widget"> <div class="media"> <img src alt class="img thumb"> <div class="body"> <h1 class="heading"></h1> <p></p> </div> </div> </article>
42. <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>
43. •Split code into smaller chunks. •Quickly reorder and rejig things. •Easily [ex|in]clude things. •Make code DRYer. Preprocessors
44. •Plenty of them. •Document anything that isn’t obvious from the code alone. •Explain what, how and why. Comments
45. /** * Comment title * * Longer description of the * code goes here. * * 1. Contain floats. */ .foo{ overflow:hidden; /* [1] */ }
46. Clean house, clean mind. — Mothers
47. Keeping clean •Consistent formatting. •Loads of whitespace. •Plenty of comments. •You can make bad code look good.
48. .foo{ color: red; background:green; display:block ; -webkit-border-radius:4px; -moz-border-radius:4px; border-radius:4px; }
49. .foo{ color:red; background:green; display:block; -webkit-border-radius:4px; -moz-border-radius:4px; border-radius:4px; }
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.
51. shame.css •Hacks •Short term fixes •Tech debt •$ git blame shame.css
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.
53. tl;dr •One job, one job only, one well. •Keep specificity low. •Run a tight ship. •Keep on keeping on.
54. Fin. •Harry Roberts •smacss.com | bem.info •csswizardry.com •@csswizardry