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

Oh No! Spaghetti Code!

7d86093feb64d21538561ea2c071a89e?s=47 Fiona Chan
October 24, 2013

Oh No! Spaghetti Code!


Remember the (painful) times when you had to use !important just so you could quickly override some styles you inherited? Or the times you stared at a giant stylesheet and couldn’t figure out where everything is? Large, unmaintainable CSS code is a common problem for many websites. It is often neglected because things can still somehow work even when the CSS is really bad! But not only does this slow down performance, it also inhibits developers from producing quality code. But if you start your site with a solid foundation, developing a large scale website with maintainable CSS is actually not so hard. In this talk, I’ll share with you some of the lessons I’ve learnt from building and maintaining large CSS files, and how Sass has helped to make that job easier.

This talk was presented at Web Directions South 13.


Fiona Chan

October 24, 2013


  1. http://www.flickr.com/photos/scotthamlin/6333578940/ @mobywhale Fiona Chan Oh No! Spaghetti Code! How not

    to get yourself into a spaghetti code mess in your CSS.
  2. Raise your hand if... Quick survey..

  3. ...you’ve had to write !important to override another !important

  4. ...modifying some CSS makes your palms sweat because sh*t might

    break! I raised my hand twice as I have been in these situations more times than I’d really like.
  5. • Painful and dissatisfying when dealing with messy CSS •

    Small part of me dies a little everytime I have to use an !important to force some CSS to work
  6. Messy code inhibits developers from producing quality code No matter

    how good you are, if you have to constantly battle with messy code, it is extremely hard to produce quality code. Maybe you still can, but it will take a lot longer.
  7. Re-usable, robust components One of the key things of having

    more maintainable code is
  8. I’m going to use CNN as an example.

  9. Boxes • In particular -> box component -> some of

    the steps I follow when creating a reusable component, • referring to some of the concepts from OOCSS and also talk about how Sass helps.. to an extend
  10. Build the simple components • Because you can combine them

    to create more complex ones.
  11. Spot the pattern

  12. Create base component b b b box box box box

    • All boxes have common padding • Base called box -> contains the common styling between the four boxes
  13. .box { padding: 10px; } .insideNews { box-shadow: 0 0

    3px #ccc; } <div class="box insideNews"> .... </div> b • Add a skin class that applies styles specific to the box • Avoid duplication, can make maintenance easier, lighter code
  14. Naming your component - Next thing to consider is naming

    your component - It is probably one of the hardest things to do.
  15. b .insideNews { box-shadow: 0 0 3px #ccc; } •

    content specific class • as soon as your class is used with other content, then it doesn’t make sense anymore • Sometimes i would get a design and I’ll see a particular component being used in this one instance only and I’d think “oh it’s only used here, it won’t get reused” and I’d create something that’s very particular to this one instance. Almost all of the time, the designer would give a new design down the track with the component being used in another context and i’d think “Ah crap. Why didn’t I abstract it?”
  16. Be abstract • good idea to be abstract from the

    start, and always think it can be reused. • a lot of people say “class name shouldn’t tie to content” or “it shouldn’t tie to styles”
  17. .box1 { box-shadow: 0 0 3px #ccc; } • So

    I’ve done things like being super abstract, and named things like .box1, .box2 etc. • It made it very difficult understand what this module is for when I had to maintain it
  18. .boxFeature { box-shadow: 0 0 3px #ccc; } • Something

    a bit better would be to call it boxFeature • You can argue boxFeature is still tied to the styles
  19. Things can’t be one-sided

  20. Find the middle ground Find the middle group between something

    that makes sense, and something that’s abstract
  21. Make components just work • What I mean -> everyone

    on the team will have different level of understanding of css. • When they use a component on a page, we don’t have them to have to worry about how the CSS behind it works. • work as intended
  22. .clearfix • clearfix is one of those things we don’t

    want people to be worrying about • don’t want people to have to add a clearfix everytime they float something inside a component because things will bound to get missed
  23. <div class="box boxFeature clearfix"> .... </div> • Because boxes are

    so commonly used, it’s very likely there’ll elements floated inside • So adding a clearfix to it preemptively is probably a good idea
  24. @extend Allows you to inherit the styles of another selector

    • So this is when Sass has a very useful function called “extend” • What it does.. • We’ll look at 2 ways you can do this
  25. @extend selector .clearfix { &:before, &:after { content: " ";

    display: table; } &:after { clear: both; } } _clearfix.scss .box { @extend .clearfix; padding: 10px; } _box.scss .clearfix:before, .box:before, .clearfix:after, .box:after { content: " "; display: table; } .clearfix:after, .box:after { clear: both; } output.css • extend selector • have a class that does the micro clearfix • box that extends clearfix class • output -> box now has the micro clearfix by default • grouped together with clearfix class -> you just have on set of micro clearfix styles in your CSS
  26. %placeholder %clearfix { &:before, &:after { content: " "; display:

    table; } &:after { clear: both; } } _clearfix.scss • Another way of doing this is using Sass’s placeholder selector where the styles won’t get compiled until you extend. • Cos we want want to build in clearfix as part of the component -> rather than outputting the class as well, just use placeholder selector
  27. %placeholder .box { @extend %clearfix; padding: 10px; } _box.scss .box:before,

    .box:after { content: " "; display: table; } .box:after { clear: both; } output.css • then in your component -> @extend %clearfix, you’ll see the clearfix class doesn’t get outputted
  28. %placeholder %baseSpacing { margin: 15px 0; } _spacing.scss .box, .tabs

    { margin: 15px 0; } output.css .box { @extend %baseSpacing; padding: 10px; } _box.scss .tabs { @extend %baseSpacing; } _tabs.scs • In OOCSS, another place where the placeholder selector is used is for the base spacing. • It’s a good idea to set a default top and bottom spacing for most of your components • Rather than using an actual class to do that, or repeat the base spacing all over your CSS, you can just use a placeholder selector and have your components extend it, then you won’t get the duplication
  29. BUT... • With great power comes great responsibilities. • extend

    in Sass is very useful and can definitely help eliminating repeated CSS, but it’s got its downsides
  30. .box { @extend %baseSpacing; padding: 10px; } _box.scss .boxFeature {

    @extend .box; box-shadow: 0 0 3px #ccc; } .boxBasic { @extend .box; border: 1px solid #ccc; } • Base box component extends the base spacing • We want the two skin classes to have the same styling as the box component so we extend class box
  31. .tabs { .box { background: #ccc; } } .dropdownMenu {

    .box { background: #999; } } _tabs.scss _dropdown.scss - Then we want to use the box component in the tabs and dropdown menu component and style it differently.
  32. Yikes!!! .tabs .box, .tabs .boxFeature, .tabs .boxBasic { background: #ccc;

    } .dropdownMenu .box, .dropdownMenu .boxFeature, .dropdownMenu .boxBasic { background: #ccc; } .tabs .box, .tabs .boxFeature, .tabs .boxBasic { background: #ccc; } .dropdownMenu .box, .dropdownMenu .boxFeature, .dropdownMenu .boxBasic { background: #ccc; } 1. Output tab boxFeature, tab boxbasic, all these unwanted classes. 2. Downside of @extend -> it’ll extend all the places where you’ve used that class you’ve extended 3.Important to always check your output and be really careful when you use extend, otherwise..
  33. ZOMG!

  34. Namespacing When we’re naming our classes, namespacing them can have

    a lot of benefits
  35. b .header .heading • If we just give it a

    generic class name like header or heading...
  36. .boxFeature { .header { padding-bottom: 10px; border-bottom: 1px solid #ccc;

    .heading{ color: #000; } } } .boxFeature .header { padding-bottom: 10px; border-bottom: 1px solid #ccc; } .boxFeature .heading{ color: #000; } _box.scss output.scss • Then in our sass we’ll need to nest it within the component in case we’ve used the same class name in another component
  37. .boxFeature { box-shadow: 0 0 3px #ccc; } .boxHeader {

    padding-bottom: 10px; border-bottom: 1px solid #ccc; } .boxHeading { color: #000; } .boxFeature { box-shadow: 0 0 3px #ccc; } .boxHeader { padding-bottom: 10px; border-bottom: 1px solid #ccc; } .boxHeading { color: #000; } output.css _box.scss • But if you name space you class by prefixing your inner elements with the name of the component, then you can avoid your styles being overriden by other components and you won’t need to nest the class within the component class • -> this will lower specificity and creates a lot less bloat in your css as your components grow
  38. Just because you can nest...

  39. ...doesn’t mean you should. • Last thing, non-technical but it’s

    critical thing in making sure your code doesn’t turn into spaghetti code
  40. Communication

  41. Code standard - Key thing to have within the team

    is written code standard - agreed on by the team and communicated to everyone - otherwise everyone will write in the same way and you won’t get this jumble of styles
  42. Living styleguide • Important to create a living styleguide ->

    one that uses real code, rather than done in a pdf • critical in documenting both your design and code • it’s one place the whole team can refer to, to see what components have been built, how everything looks
  43. Collaboration < > • Important to work with designers •

    If we can avoid creating new css by using something that exists on the site and does 80-90% of the job -> communicate back to design and ask if we can just re-use what exists and explain that it’ll mean less code and easier for maintenance. • Not saying we shouldn’t follow design, just saying there needs to be a balance between UX, design and code.
  44. http://www.youtube.com/watch?v=ldx4ZFxMEeo&hd=1

  45. OOCSS https://github.com/stubbornella/oocss/ Code standard • https://github.com/csswizardry/CSS-Guidelines • https://github.com/necolas/idiomatic-css Styleguide tool

    • http://jacobrask.github.io/styledocco/ • https://github.com/kneath/kss
  46. Happy coding :)

  47. Happy coding :)