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

Should we worry about CSS selectors?


The question was essentially, Should authors concern themselves with the selectors used in relation to CSS performance?

Let's start at the beginning, where things like the CSSOM and DOM actually get constructed. Paul Lewis (http://aerotwist.com/), Developer Advocate for Chrome Developer Relations explains, Style calculations are affected by two things: selector matching and the size of the invalidation. When you first load a page all the styles need to be calculated for all the elements, and that's a function of tree size and the number of selectors.

For more detail, Lewis quotes Rune Lillesveen (https://docs.google.com/document/d/1vEW86DaeVs4uQzNFI5R-_xS9TcS1Cs_EUsHRSgCHGu8/edit#) on the Opera team (who does a lot of work on Blink's style code):

At the time of writing, roughly 50% of the time used to calculate the computed style for an element is used to match selectors, and the other half of the time is used for constructing the RenderStyle (computed style representation) from the matched rules.

OK, that went a bit science for me so does that mean we need to worry about selectors or not?

Lewis again, Selector matching can affect performance, but in my experience the tree size tends to be the most significant factor.

It stands to reason that if you have an enormous DOM tree, and a whole raft of irrelevant styles, things are going to start chugging. My own bloat test (https://benfrain.com/selector-test/2-01.html) backs this up. Consider this another way. If I give you two piles of 1000 cards, each with different names on except for 5 matching ones, it stands to reason it will take longer to pair those matching names than if there were only 100, or 10 cards. Same principal for the browser.

I think we can all agree that style bloat is a bigger concern than the CSS selector used. Maybe that's one rule we can bank on?

 

For most websites I would posit that selector performance is not the best area to spend your time trying to find performance optimizations. I would highly recommend to focus on what is inside the braces than the selectors outside of them

 
 --Greg Whitworth, Program Manager at Microsoft