Topics for today
- Inheritance
- Values & Units
- Shorthands
- DRY
- Pseudo-elements
- Custom properties for cascading variables
The Cascade
CSS
The Cascade is an algorithm that defines how to combine property values originating from different sources and how to resolve conflicts.
Components of the Cascade
- Importance: Does it have
!important? - Origin: User Agent vs User vs Author
- Specificity: Scoring function to calculate which selector is more specific
- Order: All else being equal, last one wins
Related: Inheritance, that we will cover next week
Importance
body {
background: yellow;
}
body {
background: pink !important;
}
Origin
button {
border: none;
}
button {
border: 2px outset #777;
}
- The second tier of the Cascade looks at where the rule was defined.
We have already overridden many User Agent styles and didn't think much of it.
In this case, the cascade follows expectations: author stylesheets (i.e. from websites)
generally have higher priority than User Agent (UA) stylesheets (i.e. from the browser).
- This is by design: UA styles are merely a fallback for pages that have not defined any CSS.
- There is also a third origin: User, for stylesheets defined by the website *visitor*, i.e. the browser user, which sits right between them.
Originally, CSS was envisioned as a way for web users to also customize the websites they visit, and browsers used to provide this functionality out of the box.
Unfortunately, it did not pan out, and browsers removed the UI for this functionality.
It can still be accessed through extensions (e.g. [Stylus](https://chrome.google.com/webstore/detail/stylus/clngdbkpkpeebahjckkjfobafhncgmne?hl=en))
Origin
button {
border: none;
}
button {
border: 2px outset #777 !important;
}
Fun fact: The hierarchy here is actually reversed for `!important` rules, meaning that an `!important` browser default rule wins over an !important website rule, i.e. you can never override it no matter what you try.
Any author styles
on a given element
override any UA styles
(Unless !important is involved)
- What happens when there are conflicting declarations about the same element?
- Here it’s quite obvious, since the selector is the same, so last one wins.
- But what about here?
- Surprised at the result? The reason is that `#container *` has higher *specificity* than `div.box`.
Selector specificity is a heuristic for inferring importance from querying logic
Calculating specificity
- Specificity is a tuple with three elements, (A, B, C)
- A = number of
#idselectors - B = number of
.classes,:pseudo-classes,[attributes] - C = number of element (tag) selectors
- Compare specificities by interpreting the three numbers as digits in a sufficiently large base.
E.g.
(1, 0, 0) > (0, 100000000, 100000000)
- CSS resolves conflicts via selector specificity, not source order.
- Specificity is calculated as follows:
- A = number of ids in the selector
- B = number of classes, attribute selectors, pseudo-classes
- C = number of tag selectors
- Specificities are compared by comparing the three components in order: the specificity with a larger A value is bigger; if the two A values are tied, then the specificity with a larger B value is bigger; if the two B values are also tied, then the specificity with a larger C value is bigger; if all the values are tied, the two specificities are equal.
- If specificity is the same, then the conflict is resolved based on source order.
Specificity: Special cases
| Selector | Specificity |
|---|---|
style="background: red" |
(∞, ∞, ∞) |
:not(em, strong#foo) |
(1, 0, 1) |
:is(em, #foo) |
(1, 0, 0) |
:where(em, #foo) |
(0, 0, 0) |
- Declarations within the `style` attribute have infinite specificity
- Pseudo-classes that take selectors as arguments (e.g. `:not()`, `:is()`) do not count like regular pseudo-classes
- `:where()` has zero specificity regardless of its argument
🤺 Specificity battle! 🤺
Sometimes, specificity "predicts" which selector is more specific accurately, but other times it doesn't.
Take a look at these two selectors.
The first one includes all `<div>` elements on the page *except* the two with `id="foo"` or `id="bar"`.
The second one selects all `<div>` elements with `class="box"` that are descendants of `<main id="container">`.
Which one seems more specific to you?
Selector specificity is a heuristic for inferring importance from querying logic
So what do we do when it’s wrong?
Adjusting specificity
Increasing specificity
- Repetition:
.foo.foo.foo - Negation:
:not(#nonexistent)
Decreasing specificity
#footo[id="foo"]:where()
