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
   

   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