Cascading Styles

• We’ve talked about the ordered list
• or cascade of style sheets
• And the way this…

• Inevitably leads to conflicts
• And often, as developers,
• We might think of those as being selector conflicts
• But from the browser perspective,
• It’s the individual declarations that we’re looking at
• The selector is a bit of metadata attached to that declaration

• Before a browser can render the page
• Every CSS property
• on every HTML element
• must have a single value

• There’s 500-some properties
• And every one of them needs a value
• In order to render the element

• Every button needs
• one text color,
• one border-top-left-radius,
• and so on

• What we call ‘the cascade’ now
• is a browser process, an algorithm
• merging our list of stylesheets
• (‘cascading’ them together)
• and resolving any conflicts between declarations
• That process ensures we don’t have extra values

• And then inheritance helps
• Fill in some of the missing values
• We’re not going to set all 500-some properties on every element!
• So good defaults are essential,
• (we’ve already seen some of that)
• But there’s a whole separate step for it…

• After the cascade has finished.
• Both are steps in a larger process called value resolution
• Or value processing…

• Where each step gets us closer
• to that actual rendered style on the page
• Filtering to get all the relevant declarations
• for a specific property on a specific element,
• Cascading to resolve any conflicts between those declarations
• Defaulting to fill in anything that wasn’t declared explicitly
• And then several steps that help us resolve contextual & automatic values

• On the one hand,
• This is all internal logic, right?
• Just an algorithm that browsers use…

• to thunder-dome our declarations
• And find a winner

• Almost like the laws of physics…
• A way of describing the universe around us,
• The way the world works.
• That’s all true, but also…

• tools provided to us, intentionally
• part of the language,
• designed for us to communicate…

• At each step we get tools
• to help us express purpose and priority
• Of our hints and suggestions.

• That starts with filtering our stylesheets
• To get all the relevant declarations
• for a given property on a specific element

(Read it from the specification)

1. In a stylesheet that applies to this document
   • (media attr)
2. Not in a false conditional rule
   • (at-rules - media, supports, preferences, etc)
3. In a selector that matches the HTML Element
4. Is syntactically valid

• Invalid CSS (like HTML) is discarded/ignored
• Called ‘parse time’ validation
• Not everything can be validated at this point
• Useful, because we catch issues early
• Before we discard other declarations

• This is also when we expand shorthand properties
• Elements don’t have a border property
• They have four border properties, and a border-image
• Border is shorthand for setting all of them

• Four sides are also shorthand, including
• The width, style, and color of each
• Shorthands also reset the un-specified values
• Initial value of border-color is currentColor
• (We’ve set that implicitly)
• Also border-image which is reset-only here

• Shorthands are great for starting over
• Reset everything
• Build from the ground up
• But they’re risky if…

• You just want to make small adjustments
• Long-hand properties are more precise
• And leave everything else intact

• Once we have our list of declared values for a property
• We know what conflicts exists
• And we can use the cascade to resolve those conflicts

• Cascade works like a coin sorter
• Instead of measuring the size of a coin
• Measuring the priority of each declaration
• See which ones make it farthest

• All we care about is the coins that made it the furthest
• We can ignore any empty columns
• And discard coins that didn’t make it quite as far
• Those are gone from memory now!
• But we still don’t have a single winner

• So we find another coin sorter, and we do it again
• Over and over, until we have a single coin
• Each time comparing different features
• Not just size, but shape, width, metal, whatever
• Ok, but not coins -

• We’re talking about declarations here…

• And there are seven ‘coin sorters’ that we’ll use
• 7 Questions we can ask to compare and discard declarations
• Until we have a single winner
• Starting with origins & importance, which we’ve discussed
• Who requested it, and how much do they care?
• And we’ve talked about the final step,
• Order of appearance, which was declared ‘last’ in the code?
• Along the way, we also ask:
  1. Does it come from the shadow DOM? (context)
  2. Is it an inline style? (element attached)
  3. What layer is it in? (cascade layers)
  4. How specific is the selector? (specificity!)
  5. (maybe) How close is the scope root? (proximity, new)

• Importance could be split out at the top
• Important styles always win
• Over normal, non-important styles

• But that would miss the point
• This is about collaboration
• And importance is here to help us…

• Balance the power of the various origins…

• So we can override user defaults
• But users can also protect the defaults
• That are most important to them
• We’ll see this importance-reversal behavior again
• in other steps of the cascade
• But technically there are several other origins…

• Officially two
• For ‘intermediate’ or interpolated styles
• Generated by animations & transitions

• Take two colors (HotPink to Teal)
• If we want to move between them,
• The browser has to go through other colors…

• (Depending on the color space we use)
• Maybe we go through this bluish color
• Along the way, that has to _override_both hotPink and teal

• For transitions,
• The start and end values might come from any origin,
• With any importance
• The transition isn’t applied until after the cascade
• So we’ve all had our say
• We agree on the end points,
• And we agree on transitioning between them

• So the intermediate values have to override everything
• Transitions are the most powerful ‘cascade origin’

• Animations are a little different
• Only the animation property is in the cascade
• But keyframe declarations live outside the cascade

• Importance isn’t allowed in keyframes
• will cause the declaration to be ignored

• So we still need a way to override specific parts of an animation
• By slotting animated values just above the normal origins
• Important styles become immune animation

Just to restate:

• We can transition between important styles
• And those transitional values will override everything else
• But we cannot use keyframe animations to change important styles

• And then there’s one… pseudo-origin?
• For non-CSS presentational hints

• This includes presentational HTML attributes like
• width, or height, or hidden
• Or the default styles of the strikethrough element
• Since it’s a presentational element, not a semantic one
• They’re a little weird, and in-between,
• so spec doesn’t list them as their own origin,
• But it does treat them like one

• Those non-CSS styles slot in between
• User and authors styles
• There are no ‘important’ presentational hints.
• Although sometimes…

• There should be one
• Hidden deserves to be important
• And we can make it important in our CSS
• I include this as part of a modern reset in my projects

• Important styles always win,
• But they also split us into two paths
• An important mirror universe…

• We’ve seen that impact origins, reversing their priority
• But they have a similar effect on several other steps as well
• Including the next one,’

• Which is called Context in the cascade
• It’s like a sub-‘origin’, but for shadow DOM styles
• Styles that come from the shadow DOM

• Since we generally can’t select Shadow DOM elements
• From outside the shadow DOM,
• There are only a few places where these conflicts can happen
• Primarily light-DOM host element, exposed parts, and slotted elements
• I’m not an expert with web components so I might have missed something
• But those are the primary cases I know about

• We can think of shadow DOM styles
• As similar to browser defaults, from the user agent origin
• We’re defining ‘custom elements’ and we can give them ‘custom defaults’

• Normal author styles from the page
• will override those default shadow DOM styles
• Unless we add !important to protect essential styles,
• and then (again) the priority is reversed
• Shadow styles can ‘take back’ priority when necessary

• Again, importance is defensive
• Allowing component authors to protect essential styles

(demo if needed)

• Element attached (or inline) styles are next
• They’re an exception to our importance reversal
• They work the same on both tracks…

• Important styles can be used to override inline styles
• But when both styles are normal, or both important
• Then inline styles always win

• Remember, each of these steps is resolved
• Before we move on to the next step
• So if a single declaration wins after comparing
• Origin, importance, context, or element attachment,
• Then we never bother with layers or specificity and so on.

• Cascade Layers are both new
• Proposed at the end of 2019, but also…

• Well supported across browsers, for almost 3 years now

• They give us a way to organize our code
• And help us manage the cascade
• Or maybe more to the point…

• They can help us manage specificity
• Because they come before specificity in the cascade
• So the declaration in the highest layer wins
• Before we bother to compare specificity
• Inside the winning layer

demo:

• Source order is fragile, layers are explicit
• Specificity only matters inside a layer
• Un-layered styles win by default
• Layers stack in order
• Define the order up front

• A layer rule starts with at-layer
• And then brackets
• We can put any CSS inside those brackets…

• And we can optionally give our layers a name
• Almost any name we want
• Avoiding a few reserved names

• And we can put almost anything
• inside each layer block

• We can also import entire stylesheets into a layer,
• Using the keyword (for an anonymous layer)
• Or the layer function if we want to add a name

• Layers stack in the order they are introduced
• The first layer has the lowest priority,
• Building up to the last layer,
• And then un-layered get highest priority

• The great thing about naming layers
• Is that we can reference them again
• And add more styles to them, from anywhere in our document
• The ordering is based on when each layer was first introduced
• So it’s also useful…

• To define an explicit layer order up-front
• There’s a shorthand syntax for that
• We can provide a list of names
• Right at the top of our CSS file

• Or even in our HTML,
• Before we import other stylesheets
• There’s a lot more we can do here,
• but we’ll come back to it when we talk about CSS architecture
• and organizing conventions
• The key for today is that…

• Like origins and context
• Important layers are reversed

• So if we have three layers
• Each one overriding the previous

• And then we add important styles
• Inside each layer

• We now have six layer
• With the important layers reversed

• Again, the goal is balance

• If we just want to override
• Or manage priorities
• That’s what layers are for
• Importance only when essential

• So when I set the hidden attribute to display none
• And add importance,
• I can put that in my lowest layer,
• I’ll call it the reset layer
• And future, more powerful layers
• won’t be able to override this declaration
• It’s important, and so it’s protected.

• While we’ve already covered inline styles,
• And they aren’t technically ‘layers’ in the same way
• It can be useful to understand how these two features of the cascade
• Weave together somewhat,
• With inline styles at the top of both
• The normal and important layer order

• Which brings us to the most discussed
• Maybe the most feared and hated part of the cascade…

• Selector specificity
• This is where we compare
• the selectors used for each declaration

• All simple selectors fall into four ‘categories’
• Each with increasing priority in cascade…

• The universal (star) selector
• Alone in its category…

• Selects all HTML elements
• (but not pseudo-elements like before or after)
• We can use this for extremely generic settings
• Across every element on the page

• Element & pseudo-elements
• Are called ‘type’ selectors

• They are much more targeted, but still fairly broad
• And (until recently) not something we could control
• HTML defines what elements we have available to use
• But still, these selectors can us establish
• More customized defaults,
• Similar to user agent styles

• Attribute selectors
• (which include classes and pseudo-classes)
• Select elements based on any attributes or exposed state
• This is where we have the most control & flexibility

• Great for defining reusable patterns
• So they become the backbone of our design systems

• Finally ID selectors
• Valid ID’s are required to be unique on a page

• Should only ever select one element per page
• Extremely targeted/specific styles

• We can combine these simple parts
• Into compound selectors…

• Where every part referring to the same subject
• Or describe relationships with combinators…

• To form complex selectors

• Where there’s still only one subject (the far right compound)
• But now different parts refer to different elements,
• Providing context.
• This is extremely powerful!
• We can use selectors…

• to express fairly complex ideas
• Read from right to left…
• This selects a div that comes after an h2
• (which has a button child, that is not expanded)
• Look at all that information we’re communicating to the browser!

• But what we’re worried about now
• Is the specificity of a selector in the cascade
• And for this step the browser uses a heuristic
• a practical assumption

• That narrowly targeted selectors like IDs
• are likely more important than broad selectors like element types.
• That makes some sense, right?
• One-offs override reusable patterns,
• which override element defaults,
• which override global initial values?

• To compare, we count up how many terms we used in each selector,
• And which category those terms belong to
• Here the border-color declaration has a selector
• With 1 ID
• 2 Attributes
• 2 Element types
• A specificity of 1, 2, 2

• The total isn’t what matters
• We again compare the columns one at a time

• Like software versions
• We can look at the first number
• That might give us a winner already

• We only have to look at the next column (attributes)
• If there’s a tie in the first

• It’s a good heuristic
• Most of the time
• But heuristics are assumptions, and…

• Assumptions always fail at some point
• So the more code we write,
• (The larger our code base)
• The more likely we are to find those exceptions

• When that happens, when specificity isn’t enough
• We need an escape hatch
• that’s still meaningful and expressive
• That’s why layers were added to the cascade
• We shouldn’t be afraid of specificity
• We should have tools to manage it

• There are also some new selectors
• (and old selector tricks)
• That we can use to manage specificity
• Selector-by-selector

• ID’s are often used in forms, aria-roles, etc
• But sometimes ID specificity is too much for what we’re trying to do
• Remember that IDs are attributes!
• We can use an attribute selector instead,
• Selecting the same element, with lower specificity

• We can also increase the specificity
• Of a class, attribute, or ID by repeating it
• In a compound selectors (all strung together)
• This changes specificity, without changing what we select

• The :is() and :where() selectors
• Can also be used to manipulate specificity
• They always select the same things

• The overlap between what’s outside
• (in this case an anchor tag)
• and what’s inside
• (in this case the active class inside a nav element)
• Both parts have to match the same element

• Both contexts have to be present
• Both subjects have to match

• They select the same elements

• After specificity,
• Another new feature in the cascade

• The final step in the cascade

• Order of appearance
• Guarantees a single answer

• That will come in handy when we talk about resilience
• Old browsers will discard the new syntax
• at parse time, part of the filtering step before we cascade
• That will allow the well-supported value to win
• But browsers that understand oklch() color syntax
• Will keep that second value around, and it will override the first

And that’s the cascade, in 7 steps…

1. Who requested it, and how much do they care?
2. Does it come from the shadow DOM?
3. Is it an inline style?
4. What layer is it in?
5. How specific is the selector?
6. How close is the scope root?
7. And which style was requested ‘last’?

• The input to the cascade
• Was a list of declared values
• (for each property on each element)
• The output now
• Is a single (possibly empty) cascaded value

• Since some values are potentially empty
• We need a process to fill them in!
• We’ll talk about that tomorrow, along with…

• Custom Properties (CSS variables)
• Which can play a unique role in that process
• That will start to move us out of theoretical physics
• Into more applied use-cases and demos

• Hopefully (today) a better understanding of cascade…
• What it is, how it works

• Why it exists (to bring balance)
• Where we fit into the larger process

• And ways we can use it
• To write more expressive style rules

• As part of our style collaboration
• With browsers, users,
• and (hopefully) aliens
• The cascade is what makes all of this possible.