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 about JavaScript


However, Whitworth also notes that extra diligence is required when dealing with JavaScript and dynamism in the DOM structure, If you are using JavaScript to add or replace classes on events over and over again you should think about how that will affect the overall web pipeline and the DOM structure of the box you're touching.

This ties in with the earlier comment from Paul Irish (https://www.paulirish.com/). Rapid invalidation of areas of the DOM thanks to class changes can occasionally show up complex selectors. So, maybe we should be worried about selectors?

 

There are exceptions to every rule and there are selectors that are more performant than others but we normally only see these in cases where there are massive DOM trees in tandem with JavaScript anti-patterns that causes DOM thrashing and additional layout or painting to take place

 
 --Whitworth

For more simplistic JavaScript changes, Lewis offers this advice, The solution is normally to target elements as closely as possible, though increasingly Blink is smart about which elements will truly be affected by a change to a parent element. So, practically speaking, if you need to affect a change in a DOM element, add a class directly above it in the DOM tree if possible, rather than up on the body or html node.