Cascading Styles

• ‘Branded’ conventions
• Built up over 20 years of CSS

• What I call the ‘branded’ conventions
• BEM, SMACSS, etc
• These are systems that someone is marketing to us
• And they can be useful as a point of reference
• But it’s also important to remember…

• No single solution will fit every project
• Or every team
• We’re all working under different constraints…

• Different team structures
• Different budgets & priorities
• And those differences matter…

• All just conventions
• A set of guidelines someone found useful
• In their org, their team, their code
• Your mileage will vary

• Just because instaSalesFace did it
• Doesn’t mean it will help anyone else
• In fact, the tools people use at that scale
• Are often absurdly overblown for the rest of us
• They’re trying to solve problems most developers don’t have
• So there’s not a single correct approach

• I tend to agree with Chris Coyier
• They’re all pretty neat…

• Important to say up-front, there’s no miracle cure
• If we refuse to weed the garden over time
• Then the garden will have weeds
• That work doesn’t go away because we switch to utility classes,
• Or move our styles into Javascript

• Maintaining a convention, like weeding, is a process
• Not a technical problem to ‘solve’ and move on

• I’d say we do the same at OddBird
• But I’m going to flesh that out a bit more today
• And talk about the decisions we’re making
• And how we think about ‘the selector we need’

• Both are steps in a larger process called value resolution
• Or value processing…

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

• Each step here 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
• Whenever a property is set more than once
• We need to 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.

• The cascade itself has a 7 steps to it
• 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?

• We can think of each layer here as 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 -

• Order of appearance
• Guarantees a single answer

• If we set the same property multiple times
• Only one can apply,

• And ‘last one wins’ will always give us
• that single answer

• Since later styles override earlier styles
• We want to start with our broad brush strokes

• Something they all share
• Working from the macro to the micro
• Broad strokes, before minute details

• Overall structure & individual components
• These are distinct, and separate

• Nicole Sullivan’s OOCSS
• (came out around the same time)
• Highlights similar ideas

• Objects are not just components, because
• Not just components are reusable…

• But the patterns that we use
• across components

• Which leads us into selectors and specificity
• Maybe the most feared and hated part of the cascade…

• to express fairly complex ideas
• Read from right to left in phrases…
• 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!

• We can reference els & attrs in selectors
• Also have access to pseudo-classes & pseudo-elements
• Extended with ARIA attributes as needed
• Selectors help enforce/encourage semantic HTML patterns
• When we reduce this to a class-name string,
• We lose all the meaningful built-in associations

• There’s so much we can do
• Without ever coming up with our own names

• Selector combinators let us expand on that
• Defining relationships

• 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?

• So simple selectors…
• (the bits that we build into complex and compound 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

• 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

• 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

• 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 relatively new, but
• 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

• So define the order up front
• Generally, imports have to come first
• Layer lists are allowed before imports
• Order matters!

• Add your own sub-layer to an imported layer!

• Like resets, design systems, component libraries
• Anything not project-specific

• 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.

• 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

• 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

• With context, we’re mostly talking about shadow DOM
• And like origins & layers,
• We’re back to importance reversing things

• 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
• We’ll see this importance-reversal behavior again
• in other steps of the cascade

(demo if needed)

• So let’s keep going through them
• We talked a bit about origins
• But you can see there are a few we left out

• 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

• 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, usually

• 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!
• That will mean inheritance for some properties
• And the initial value for others

• 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.