Oh No! Spaghetti Code!

https://www.youtube.com/watch?v=k1VOpxdoRIY

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.

Transcript

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 :)