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

Defining the problem


Enduring CSS was born from my own need to define a rational approach to writing CSS on large scale web applications.

The definition of what makes something a web application as opposed to merely a web page can be divisive so let's put that aside for now. Let's simply consider the scenario in which a new approach to writing CSS was needed.

Consider an interface that was, by necessity, densely populated with visual components; sliders, buttons, input fields etc.

In addition, consider that this interface was (and is) constantly evolving and needed to be changed rapidly. Furthermore, any changes might be made by any number of different style sheet authors.

Without a clearly defined CSS writing methodology, through the many iterations, the CSS was always out of hand. The style sheets were in a perpetual state of entropy as a result of mixed approaches, different levels of technical understanding between authors and code documentation that varied greatly in quality.

So the result was CSS that was difficult to iterate upon, hard to reason about and nobody was ever quite sure where redundancy lay. Worse still, style sheet authors lacked the confidence to remove code for fear of inadvertently effecting other parts of the application.

If you've ever inherited or worked in a team on a large CSS codebase, I'm sure some of what I'm describing will sound familiar.

Therefore, at the outset of my journey, I defined some basic needs. More simply, these were the problems that any new CSS authoring approach had to solve. Here is the list of those needs:

  • To allow the easy maintenance of a large CSS codebase over time

  • To allow portions of CSS code to be removed from the codebase without effecting the remaining styles

  • To make it possible to rapidly iterate on any new designs

  • Changing the properties and values that applied to one visual element should not unintentionally effect others

  • Any solution should require minimal tooling and workflow changes to implement

  • Where possible, W3C standards such as ARIA should be used to communicate state change within the user interface

In the next chapter we are going to look more specifically at these problems. However, first, an important cautionary note.