Make your CSS beautiful again
•Download as PPTX, PDF•
1 like•598 views
This is the first of three presentations detailing the front end optimization of goodtoknow.co.uk. Part one describes how we refactored the CSS, part two will address the HTML structure and implementation of Behat tests, and part three will contend with image optimization specifically addressing data URI’s and sprites. Full notes here: http://spannerspace.com/make-your-css-beautiful-again/
More Related Content
What's hot
What's hot (20)
Similar to Make your CSS beautiful again
Similar to Make your CSS beautiful again (20)
Recently uploaded
Recently uploaded (20)
Make your CSS beautiful again
- 1. Make your CSS beautiful again { Refactoring without incurring a testing overhead
- 2. gtkMain.css atoz.css brightcove.css pluck.css galleryCarousel.css atoz.css galleryCarousel.css gtkMain.css galleryCarousel.css pluck.css brightcove.css Goodtoknow has more than 36 stylesheets.
- 3. Each page uses approx. 10 of those stylesheets at a combined weight of around 280k The average page only uses 50% of the CSS served At an average of 1500 CSS rules per page, around 300 are inefficient and 150 are very inefficient. The average page speed score is 82/100
- 4. { Its time to make our CSS beautiful again*
- 5. *without exhausting our test analysts
- 6. You need Cactus! https://github.com/winston/cactus
- 7. CSS tests are simply a baseline representation of your style guide. <shame>Don’t have one? Neither did we!</shame> By writing CSS tests you can refactor with confidence, whilst building & reinforce your style guide
- 8. + =
- 10. Link to jQuery Add the cactus.js file Write some tests
- 11. Cactus.expect(".header", "font-size").toEqual("24px"); Cactus.expect(".header", "font-family").toContain("Helvetica"); Cactus.expect(".header", "color").toEqual("#ff0000"); Cactus.expect(".header").toHaveMargin("10px"); Cactus.expect(".header").toHaveBorderWidth("1px"); Cactus.expect(".header").toHaveBorderColor("#ff000"); Cactus.expect(".header“, “float”).toContain(“left");
- 13. This page needs a screengrab of our yml file
- 14. <p class=“heading”> <h3 class=“smaller”> <h2 class=“bigger”>
- 15. YOU CANNOT BE SERIOUS!
- 16. Why use cactus? Refactor with confidence Ensures code quality Reduce testing overhead Build a style guide Promotes semantic markup Reduce CSS file size Reduce page load times And it can even be automated (but we’re not doing this just yet!)
- 17. More?
- 19. “Sass is an extension of CSS3 which adds nested rules, variables, mixins, selector inheritance, and more. Sass generates well formatted CSS and makes your stylesheets easier to organize and maintain.”
- 20. gem install sass mv style.css style.scss sass --watch web/sass-folder:web/css-folder now write some Sassy CSS…
- 21. SCSS CSS Nesting
- 22. This is the CSS generated by Sass for our nested SCSS 4 out of the 5 rules are inefficient
- 24. :( :) Nesting without creating inefficient selectors
- 25. Sass allows you to declare variables that can be used throughout your stylesheet. Variables begin with $ and are declared just like properties. They can have any value that’s allowed for a CSS property, such as colors, numbers (with units), or text. Variables
- 27. Operations, Functions & Interpolation http://sass-lang.com/docs/yardoc/Sass/Script/Functions.html
- 28. Mixins .pagination .next, .pagination .previous { @include button; }
- 30. example: 450 400 350 300 250 Tabbed box css 200 Channel css 150 Total rules 100 50 0 CSS old SASS CSS new
- 31. Reasons to be cautious : Nesting can create inefficient selectors Generated CSS file can be slightly more inflated if used carelessly Be cautious that you’re not duplicating variables and mixins
- 32. Reasons you love Sass: Build and easily maintain a style guide SCSS file is more concise Variables and mixins prevent careless errors Stacks of great functions available Error handling for poor code Easier to maintain Use the math functions for responsive builds Now your CSS is beautiful again!
- 33. footnotes
Editor's Notes
- We have a yml file which allows us to target modules and verticals separately as we still have many discrepancies across elements that should be styled the same. With the navigation we initially needed a separate test per channel, but now we just need one.Eventually when we have standardised all our styles, we will need fewer test instances as we will have fewer styling discrepancies. Then the styleguide going forward will reduce coding time in future. Styles will be inherited correctly and overwritten correctly.
- And as a little aside… by using a styleguide your HTML will also benefit. There is nothing like a styleguide to encourage semantic markup!
- P class heading should probably be a heading, inheriting a heading style. Here you’ve bastardised your HTML, inflated your CSS and ignored semantics. Your HTML has extra text in for an unnecessary class. Your CSS has extra text in for an unnecessary rule, and the poor screenreader has no idea that this p class heading is any more important than a regular p tag.
- Cactus has allowed us to refactor using Sass to make our stylesheets even more concise and beautiful
- I’ll firstly talk about nesting, which once you start using it, you’ll wonder why it was never introduced into standard CSS. It condenses your code neatly, and partitions it into sections that are clearly related. It also saves on repeating class names over and over. On the left is our standard CSS syntax. On the right you can see how it looks when it is nested. Much neater. However…
- When you look at the CSS generated from the nesting of the previous screengrab, you’ll see it’s very ineffective.4 out of the 5 rules use far too much specificity and so in future we would have to use an equal number of selectors to overwrite any styles applied. Inefficient selectors have a negative effect on your pagespeed score.
- Nesting can be very useful, and a very tidy way of writing code, but you have to cautious of how the CSS will be processed
- Here on the left we have our previous example of nesting, which created all the ineffective selectors, and on the right we have an example of nesting as it should be used. This nesting will be processed to appear exactly how our initial CSS file did.Think about how sass is going to concatenate your selectors, and as soon as you’re going above two selectors you’re probably being too specific and your cascading stylesheets are not going to cascade
- Variables allow you to repeat property values throughout your scss files. Not only are they more human friendly on the eye than something like a hex code, but they reduce the margin of error and maintains our styleguide. Goodtoknow had so many different variations of orange being used for headings and links and buttons – and that was just on recipes – the same issue went across each channel. Using a variable means that you’ll always use the correct color or font size etc. It also means that should it need updating in future you don’t need to run a find and replace, you just need to change the variable itself
- Simply put, this allows one selector to inherit the design properties of its parent. So rather than cluttering your HTML element with another class, you can extend it in the CSS.http://chriseppstein.github.com/blog/2010/08/02/sass-extend-challenge/
- In addition to just using variable values as they’re defined, you can also modify and combine them using math and useful predefined functions. This allows you to compute element sizing and even coloration dynamically.The standard math operations (+, -, *, /, and %) are supported for numbers, even those with units. For colors, there are all sorts of useful functions for changing the lightness, hue, saturation, and more.Variables can be used for more than just property values. You can use #{} to insert them into property names or selectors
- Mixins are one of the most powerful Sass features. They allow re-use of larger chunks of code.If you’re writing standard CSS, each time you want to create new border-radius values you will have to include the vendor prefixes. It’s tedious. That or write each variant once and repeat a class throughout your HTML. Neither is desirable and both are difficult to maintain.
- Sass has error handling on the command line and in the browser. It will tell you where the bad css has been written and what it is failing on. That’s got to be a bonus!
- And so here is an example of some code on goodtoknow. After refactoring the CSS for the tabbed panels I nearly halved the lines of code. It requires two CSS files – one for the base styles and one to add the channel colors.As you can see we have reduced the lines of code by half, and we’ve done the same for the CSS rules.You can also see that when the CSS is generated from the SCSS, it is only minimally inflated from the refactored code. As a general rule, your average stylesheet will increase by ~3k for every 100 lines of uncompressed code. If you’re adhering to best practices, and you’re not too crazy with nested selectors or otherwise overusing Sass features, then file size bloat and selector performance are non-issues.http://www.atomeye.com/accolades/sass/
- Recap