Context, not modifier

A look at how my CSS methodology differs from others. Most notably, the concept of context.

5 minute read

I am continuing to examine how I am arriving at my CSS methodology. Having established the direction towards isolation (as opposed to abstraction), how does my approach sit with other approaches that take this path?

BEM #

I stated previously that my approach (which I'm calling C3) maps to an extent to the Block, Element, Modifier (BEM) approach. The significant departure comes at the third 'C' in C3 - Context. As Component and Child take the place of Block and Element, Context is sort of a Modifier replacement.

The BEM modifier is all about appearance. It is where you are permitted to describe appearance in a class name. Having rejected abstraction, I don't see any need to ditch semantics in my approach. Modifier is arguably non-semantic by design. Context is semantic by design.

While you could consider context a semantic only modifier, there is a conceptual shift that should be made. Context is not about modifying a component to extend its use. It is about the component appearing in different contexts, requiring changes to the appearance. You could think of it as reuse, without abstraction. This is a subtle distinction, but it is intended to allow for some pragmatic reuse of components, without wandering down the line between isolation and abstraction.

Context can be broken down into:

While this list is probably not exhaustive, it does hopefully demonstrate the difference to modifiers. BEM modifiers can which can be things like element_large, element_red, which do not fit into the above list.

Modifiers and context are also different in how they are named. Modifiers are coupled with the element they are modifying, they contain the name of that element, in the name of the modifier.

html
<a class="button button_size_l">
css
.button {
  /* make it look like a button */
}
.button_size_l {
  /* make it large */
}

This is in keeping with BEM's low specificity approach. In C3 I allow for some specificity when it comes to context, as I find this to be more flexible; and as Daniel Tonon puts it

Specificity != bad.
Uncontrolled specificity that has run wild = bad.

The C3 equivalent of the above BEM example might be:

html
<a class="call-to-action">
css
.call-to-action {
  /* make it look like a button */
  @nest [data-role="hero"] & {
    /* make it large */
  }
}

In the working style sheet, context is identified by it being nested in a code block. The outputted selector for the large "button" in this example being [data-role="hero"] .call-to-action.

Enduring CSS #

Enduring CSS (ECSS) is the methodology set out in Ben Frain's book of the same name. This book was a big influence on how I write CSS, and so it's method is pretty close to mine. My approach could be seen as a less hardcore (I'd like to think more pragmatic) variation of ECSS in some respects. For example, there isn't the strict name-spacing convention, which I felt could be a bit confusing. Another notable difference comes back to how we modify a component. The absence of a "modifier" in ECSS creates a strict practice of creating a new component for any variation. My concept of context allows for a degree of reuse. It should be noted that in the "The Ten Commandments of Sane Style Sheets" at the end of Enduring CSS, the notion of overrides is introduced. These overrides are mechanically the same as how I handle context. If overrides are intended to be an integral part of ECSS (it was not clear to me), then this would bring it even closer to my methodology.

Maintainable CSS #

Maintainable CSS is a recent book by interaction designer Adam Silver. The approach outlined in this book comes from the same semantic favouring standpoint as my approach; and also uses a BEM-like naming convention. As a result, Adam and myself have arrived at similar methodologies, but again there are some differences. Maintainable CSS retains the modifier notion from BEM. While the use of a modifier is presumably intended to be restricted by the explicit mention of semantics (elsewhere in the book) it feels like a grey area, open to interpretation. More generally, relying on a specific understanding of semantics, in regards to CSS is problematic. I think this is highlighted in a 2012 blog post titled About HTML semantics and front-end architecture, in which Nicolas Gallagher argued that class names "cannot be unsemantic", pointing out that not all semantics need to be content-derived. Rather than try to guide the use of modifiers with a philosophy of semantics, what I am attempting to do with context is narrow the scope so that the (internal) debate about semantics need not occur.

Start a conversation. @ me on Mastodon.