# Motivation

Those familiar with CSS will have heard the term "winning style"; in which CSS rules compete against one another. Importance, specificity and cascade decide which styles win via overrides.

Much of what makes CSS development difficult is ensuring the styles we want, win; and the styles we don’t want, lose. Anytime we edit a CSS file we risk changing the conditions that influence which overrides win. This makes CSS incredibly fragile and unpredictable.

Overrides make CSS **fragile** since what they rely on (importance, specificity, and cascade) are all vulnerable to change. Changes to HTML structure and attributes (classes) can introduce previously non-existent overrides.

Overrides make CSS **unpredictable** because:

1. The global scope permits anyone to override.
2. The side effects aren’t immediately apparent (exaggerated by #1).
3. A lack of encapsulation dampens efforts to protect styles from being overridden.
4. The longevity of an override is unknown. Just because a style wins today doesn’t mean it always will.
5. They obfuscate developer intent. It’s hard to differentiate between an intentional and unintentional override (which is open to interpretation).

Parallels can be drawn between mutable state in programs and overrides in CSS. When a style overrides another it mutates (changes) the value of the original style. Over recent years the front-end community has seen a huge shift towards removing mutable state from how we *build* applications, yet the way we *style* applications has remained the same.

But why should the way we build applications be different to how we style them? We should unite construction with cosmetics. Immutable styles is an attempt to remove mutation (a.k.a overrides) and thus complexity from CSS.

You can read more on this topic in the blog post: [CSS Overrides: Friend or Foe?](http://www.callumhart.com/blog/css-overrides-friend-or-foe)


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://callum-hart.gitbook.io/immutable-styles/motivation.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.