In the last chapter we considered project organisation and how to understand and apply the ECSS class naming conventions. In this chapter we will move our focus to how ECSS deals with active interfaces and how we can facilitate style changes in a rationale and accessible manner.
The majority of web applications need to deal with states.
First let's just crystallise what we mean by states. Consider some examples:
- A user clicks a button
- A value in an interface is updated
- An area of an interface is disabled
- A widget in the interface is busy
- An entered value exceeds allowable values
- A section of the application starts containing live data
All these eventualities can be defined as state changes. State changes that we typically need to communicate to the user. As such they are changes that need to be communicated to the DOM, and subsequently our style sheets need some sane way of catering to these needs.
How can we define these state changes in a consistent and considered manner?
Back in Chapter 3, Implementing Received Wisdom, I related how much I liked the SMACSS approach of communicating state. For example:
.has-MiniCartActive {}
Indicates that on, or somewhere below this node, the mini cart is active.
Another example:
.is-ShowingValue {}
This would communicate that the Component or one within it is showing some value (that was previously hidden).
Historically, that was how I communicated state when applying ECSS. I used a micro-namespaced class, in addition to any existing classes on the node to communicate this state. For example:
.is-Suspended {}
.is-Live {}
.is-Selected {}
.is-Busy {}
A node using these classes in the DOM might look like this:
<button class="co-Button is-Selected">Old Skool Button</button>
Note
Historically, changing a class in the DOM, especially near the root of the DOM has been discouraged. Doing so invalidates the render tree meaning the browser has to perform a whole bunch of re-calculation. However, things are improving. Recent work by Antii Koivisto in WebKit (which powers iOS and Safari browsers) means that such changes are now near optimal. Interested parties can read the WebKit Changeset for class changes here: http://trac.webkit.org/changeset/196383 and attribute selectors, such as aria-* here: http://trac.webkit.org/changeset/196629