Book Image

Enduring CSS

By : Ben Frain
Book Image

Enduring CSS

By: Ben Frain

Overview of this book

Learn with me, Ben Frain, about how to really THINK about CSS and how to use CSS for any size project! I'll show you how to write CSS that endures continual iteration, multiple authors, and yet always produces predictable results. Enduring CSS, often referred to as ECSS, offers you a robust and proven approach to authoring and maintaining style sheets at scale. Enduring CSS is not a book about writing CSS, as in the stuff inside the curly braces. This is a book showing you how to think about CSS, and be a smarter developer with that thinking! It's about the organisation and architecture of CSS—the parts outside the braces. I will help you think about the aspects of CSS development that become the most difficult part of writing CSS in larger projects. You’ll learn about the problems of authoring CSS at scale—including specificity, the cascade and styles intrinsically tied to document structure. I'll introduce you to the ECSS methodology, and show you how to develop consistent and enforceable selector naming conventions. We'll cover how to apply ECSS to your web applications and visual model, and how you can organize your project structure wisely, and handle visual state changes with ARIA, providing greater accessibility considerations. In addition, we'll take a deep look into CSS tooling and process considerations. Finally we will address performance considerations by examining topics such as CSS selector speed with hard data and browser-representative insight.
Table of Contents (17 chapters)
Enduring CSS
Credits
About the Author
Thanks
www.PacktPub.com
Preface
Free Chapter
1
Writing Styles for Rapidly Changing, Long-lived Projects
3
Implementing Received Wisdom

What difference does style bloat make?


Another test (https://benfrain.com/selector-test/2-01.html): I grabbed a big fat style sheet that had absolutely no relevance to the DOM tree. It was about 3000 lines of CSS. All these irrelevant styles were inserted before a final rule that would select our inner a.link node and make it red. I did the same averaging of the results across 5 runs on each browser.

Half those rules were then cut out and the test repeated (https://benfrain.com/selector-test/2-02.html) to give a comparison. Here are the results:

Test

Chrome 34

Firefox 29

Opera 19

IE 19

Android 4

Full bloat

64.4

237.6

74.2

436.8

1714.6

Half bloat

51.6

142.8

65.4

358.6

1412.4

Rules diet

This provides some interesting figures. For example, Firefox was 1.7X slower to complete this test than it was with its slowest selector test (test 6). Android 4.3 was 1.2X slower than its slowest selector test (test 6). Internet Explorer was a whopping 2.5X slower than its slowest selector!

You can see that things dropped down considerably for Firefox when half of the styles were removed (approx 1500 lines). The Android device came down to around the speed of its slowest selector at that point too.

Removing unused styles

Does this kind of horror scenario sound familiar to you? Enormous CSS files with all manner of selectors (often with selectors in that don't even work), heaps of ever more specific selectors seven or more levels deep, non-applicable vendor-prefix's, ID selectors all over the place and file sizes of 50–80 KB (sometimes more).

If you are working on a code base that has a big fat CSS file like this, one that no-one is quite sure what all the styles are actually for, my advice would be to look there for your CSS optimisations before the selectors being employed. Hopefully by this point you will be convinced that an ECSS approach might help in this respect.

Then again, that won't necessarily help with the actual performance of your CSS.