Cascading Styles

• write our hints as declarations,
• a property and a value

• group them into blocks

• attach directly to elements in HTML.

• but that can get repetitive
• if we want to re-use the same styles on multiple elements
• ideally, create design systems

• CSS helps by providing “a simple mapping…”

• Selectors…

• Which we can attach to declaration blocks,
• forming rule-sets.
• The selector maps our rule set…

• … to elements in the document.
• (this is the majority of the CSS we write)
• Then we can…

• Combine our rule sets into style sheets,
• and import them from our document,
• or other style sheets.
• Not just us as document authors…

• Anyone involved can contribute style sheets
• The users interacting with our document,
• and the user agent (or browser) they use.
• This is the initial vision of the web.
• It’s personalized. Users are in control.
• So all these style sheets get merged…

• Into an ordered list (or ‘cascade’) of styles
• that should be applied to the same document.
• Of course, this leads to conflicts!…

• We have any number of declarations
• from a range of different sources
• with selectors that might overlap, applying
• potentially different values
• to the same elements, and the same properties!

• Browsers need to resolve conflicts.
• Every CSS property
• on every HTML element
• must have a single value

• Every button needs
• one text color,
• one padding-left,
• one margin-inline-end, etc.

• what we call ‘the cascade’ now
• is a browser process
• merging all the stylesheets, rules, and declarations
• (‘cascading’ them together)
• and resolving conflicts

• That process ensures
• we don’t have extra values
• And then inheritance helps clean up
• By filling in some of the missing values
• There are over 700 CSS properties,
• and we don’t declare all of them.

• Both ‘cascading’ and ‘inheritance’
• part of a longer process
• value resolution or processing
• A series of steps
• converting declarations into styles

• They’re important parts of the process
• The spec that defines all of this is called
• ‘Cascading & Inheritance’

• We won’t get through all the steps today
• Just filtering and cascading
• Tomorrow we’ll cover defaulting
• (and the rest)

• We start the process with
• a cascade of style sheets
• (input from authors, users, and browsers)

• And at the end of the process
• we need to get back
• exactly one actual value
• (per property, per element)
• Today we’ll get…

• the ‘cascaded’ value
• After defaulting we’ll have a single ‘specified’ value
• And eventually (at the end) an ‘actual’ value
• Rendered on the screen

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

• That the browser uses
• to determine a winner, thunder-dome style
• Two styles enter, one style leaves…

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

• all of us,
• not just as authors,
• but also as users…

• Allowing us to…
• Provide more detail
• About the purpose and importance
• Of our hints and suggestions.
• Express our intent
• Makes the collaboration possible

• Let’s start from the top
• Filtering…

• First thing a browser does
• after parsing our style sheets.
• Go through the HTML
• find all the relevant style declarations
• that map to each DOM element

(Read it from the specification)

1. In a stylesheet that applies to this document
   • (proper media attr)
2. Not in a false conditional rule
   • (proper 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

• Also need to expand shorthand properties
• Elements don’t have a border property
• Els have four border properties, and a border-image
• Border is shorthand for setting all of them

• Not just the four sides, but
• The width, style, and color of each
• Any missing values get filled in
• Initial value of border-color is currentColor
• (We’ve set that implicitly)
• Also border-image which is reset-only

• 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

• The result of filtering,
• A list of declared values
• For each property on each element
• Might be empty, might be multiple
• Now we know what conflicts exists
• And we’re ready to resolve those conflicts

demo (debug mode):

• inspect the first section
• filter properties

• Now that we have a list
• declared values that are relevant
• We move onto the cascade
• Still narrowing down the list…

• Merging the declared values
• Resolving any conflicts
• Find a single winner

• Sort of like a coin sorter
• See which coins (declarations) go farthest

• We can ignore any empty columns
• The coins that made it the farthest move on
• Everything else is discarded…

• We do this over and over
• Until we have a single coin
• Each time, comparing different aspects
• Not just size, but shape, width, metal, etc
• Or to recover from this metaphor,
• and talk about CSS declarations…

1. Who requested the style? (origin)
2. How much do they care? (importance)
3. Does it come from the shadow DOM? (context)
4. Is it an inline style? (element attached)
5. What cascade layer is it in? (fairly new)
6. How specific is the selector? (specificity!)
7. How close is the scope root? (proximity, new)
8. Which value was declared last? (order, single)

• In detail, from the top
• What’s the origin of the declaration?
• Who requested it?

• It could be…
• Us as authors
• Or users
• Or their agent, the browser
• Combined with that…

• How much do they care?
• Did they mark this style as important?
• These are directly related
• In general…

• The user and browser
• Specify initial preferences
• Tend to be global, not site-specific
• Apply to every website you visit

• User agent (browser) goes first
• Providing legible defaults…

demo:

• inspect styles
• none from document, only from browser
• remove: * { all: initial; }
• Without browser styles,
• Unreadable wall of content…

• We’re seeing initial values
• What comes before browser defaults
• Specified for each property, not each element
• Always display:inline, even on divs…

• Browser adds everything else
• 8px margin on the body
• Link colors and underlines
• Heading styles, large bold text
• Space around paragraphs and lists, etc

• This old rule isn’t entirely true
• Elements not ignored, we see them
• But inline & un-styled (initial values)
• To maintain compatibility, CSS ensures…
• un-styled inline boxes should not impact layout

• That’s true for all inline boxes
• Until the browser gets involved
• Providing default styles
• For links, and other inline elements
• In firefox, load in the browser
• Otherwise, find in public source code

• After browser defaults
• Users apply their preferences

• Originally using the same CSS syntax
• To put us all on equal footing

• Safari still supports this option
• In the settings panel
• Upload a stylesheet

• Most other browsers have switched
• To providing limited preferences
• A form where you can set values
• Without learning CSS

• Details are a bit different
• All browsers provide something

• You (yes you) can have preferences too
• I set a few, better fonts and larger text
• Worried as dev “but I’ll see something different”
• That’s the point!
• Remember to check with different settings

• Finally, ‘document’ or ‘author’ styles
• (that’s us)

• We come last
• And kinda just do whatever
• Smear our brands all over everything
• Design

• Those are the normal origins
• First the user agent (browser), providing defaults
• Then the user, setting preferences
• (they override the browser)
• Then we come along at the end…

• And we override everyone
• We have way too much power
• And tend to stomp all over people
• But that doesn’t make sense, right?
• What about lack of control,
• hints and suggestions and all that?

• The proposal is clear,
• If conflicts arise
• The user should have the last word

• So we need a way for the other origins
• To take back control when it matters,
• Something that will bring balance to the cascade…

• That’s why we have importance
• A safety valve for the other origins
• Anyone can add !important to a declaration…

• That declaration moves to a new origin
• One of three important origins
• Higher priority than the normal origins
• With the order reversed…

• It’s a mirror universe
• We all have evil twins with goatees

• In the important origins
• We go first (lowest priority)
• Users override us
• Browsers have final say
• Set the boundaries of what’s allowed

• Important origins always override normal origins
• So we’re really in the middle
• Our normal and important styles, together

• Browsers do use importance
• (demo: find in page)

demo:

• Specificity is contained
• Importance is reversed

• Importance works in Safari user styles
• Firefox provides a checkbox
• Chrome provides a ‘minimum font size’

• Importance doesn’t change specificity
• It changes the origins
• And the priority of origins
• The purpose…

• Is not for fighting each other
• In big teams who can’t agree
• Or angrily trying to override
• Styles we wrote last year

• The purpose is for users and browsers
• To protect style from future origins
• Someone that might come along later…

• And stomp all over their preferences
• We’re the baddies here
• We need to do better at collaborating…

• But the fact that our origins
• (Normal and important)
• Are isolated together
• Means we don’t always interact with
• What’s happening around us

• We start to think
• We’re the center of the universe

• On our own
• Dealing with specificity…

• When we’re really just one
• ‘Pale Blue Dot’
• In the solar system of the cascade
• Fair, it’s what we deal with every day
• But good to have perspective

• Technically two additional origins
• For ‘transitional’ styles,
• Generated by animations & transitions
• Somewhere between two declared values

• Going from HotPink to Teal,
• Have to go through other colors…

• (Depending on the color space we use)
• Maybe rgb(93 138 220)

• In a transition, start & end values cascade
• Already have origins, can have importance
• The transition property also cascades
• So everyone has agreed to the transition before it starts
• Override any of the props to change it

• But the transitional values
• Need to override the start & end, wherever they are
• Transition needs to override everything
• From all other origins
• Transitions get the very top origin

• Animations are different
• Only the animation property itself cascades
• Keyframe declarations are outside the cascade
• Importance isn’t allowed in keyframes

demo:

• !important keyframe declarations are ignored
• the whole declaration is discarded
• External !important will win

• Keyframe styles do not cascade
• Important styles override

• Important styles always win
• Importance splits us into a different path
• Not just for origins, as we’ll see
• The next step in the cascade funnel…

• Context
• Currently ‘shadow DOM’, but might be expanded
• (How many people here are using shadow DOM?)

• Shadow DOM is part of ‘Web Components’
• But also used by some browsers
• To explain complex HTML components, like…

• …Form inputs

demo:

• Dev tools setting: show UA shadow DOM
• Inspect file input

demo:

• Light DOM v Shadow DOM
• Most selectors are limited in scope
• Host, slots, and parts get combined cascade

• Web components are thought of like HTML components
• The styles they provide are defaults
• Only expose the parts they want for more styling
• So they work almost like Browser defaults

• With a lower priority than other document styles
• This is the opposite of framework components

• By default the page (light DOM)
• Overrides Shadow DOM styles
• (where allowed)

• Again, importance is defensive
• Component authors can protect styles
• The priority is reversed

• When comparing important styles
• Shadow DOM wins over light DOM

(demo)

• Again with context
• Priorities are different
• For normal and important styles
• If we still have a tie at this point
• Move on to compare…

• Element attachment
• Some styles are directly attached (inline)
• And some are mapped with selectors

• Here things are different,
• There’s no reversal based on importance…

• Important styles always win over normal styles
• (already enforced by origins/importance)
• But in both normal & important origins
• Attached styles win over selectors.
• The only way for selector styles to win
• Is by using importance, move into a higher origin
• Skip over layers, we’ll come back…

• (time check - take a break?)
• Selectors & Specificity
• This is where we spend most of our time

• Selectors come in a variety of forms
• Starting with what we call ‘simple selectors’
• The Lego parts other selectors are built from

• Simple selectors are grouped
• Into four categories…

• The universal (star) selector
• Alone in its category
• Selects all HTML elements
• (but not pseudo-elements like before or after)

• Element & pseudo-element ‘type’ selectors
• Select specific elements/pseudos

• Attribute selectors
• Include classes and pseudo-classes
• Select elements based on any attributes or states
• Classes are just a special attribute shorthand

• Finally ID selectors
• Valid ID’s are required to be unique on a page
• This should only ever select one element

• Each of these categories
• Has increasing priority in cascade…

• Based on the assumption (or heuristic) that…

• More explicit selector
• are likely
• More important
• Working up from…

• The universal selector
• Which selects basically everything
• (Useful for only a few resets)

• Type selectors
• Help us establish broad defaults

• Attribute selectors
• Where we have the most control & flexibility
• Become the backbone of our design systems
• Defining common patterns

• And finally IDs
• For extremely targeted styles
• One-offs

• And these form the four basic layers
• Specificity
• Universal first, then type, attributes, and IDs at the top
• But we don’t just use simple selectors

• We can combine them into compound selectors
• Directly, without combinators

• So all parts describe the selector subjects
• Target any element
• Which matches all simple parts
• Or we can add combinators…

• Direct child (greater than)
• Next sibling (plus)
• Descendant (white space)
• Subsequent (future)-sibling (tilde)

• Giving us complex selectors
• May contain multiple compound parts
• But now those parts refer to different elements…

• There’s still only one subject
• Always the last compound selector, on the right
• That’s the element we end up styling
• The rest provide context, filtering results
• Target el still matches all simple parts of the subject
• Also has to have matching context

• To target multiple subjects,
• We have to combine selectors into lists

• Like units, selectors are expressive
• Browsers read them right to left
• (and so can we)
• A div that follows an h2
• (which has a button child, not expanded)
• Grammar class all over! Diagramming sentences!

• Every selector-mapped declaration in CSS
• Has a specificity determined
• By adding up the simple selectors used
• In each selector category

• Universal selectors and combinators don’t count
• Here the border-color declaration comes from a selector
• With 1 ID
• 2 Attributes
• 2 Element types

• A specificity of 1, 2, 2
• This is often written with commas
• (and in brackets, but you do you)

• Comparing specificity
• Works a bit like software versions
• 3.10.1 is larger than 3.9.12
• Probably shouldn’t get into double digits
• But if you do, columns don’t roll over

• We compare from the left
• If one has more IDs than the others…

• We have a winner, without going farther

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

• And we’re still only comparing
• One column at a time

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

• Even browsers have some very specific defaults
• Would be an issue, without origins
• It’s good for this declaration to be specific
• But it’s still just a specific default
• (essential the specificity is contained)
• On the other end…

• There are some broadly-defined defaults
• Like display:none on the hidden attribute
• Are really important!
• Don’t want to override setting display to grid.
• It’s a simple selector with broad reach
• But shouldn’t be low priority

• This becomes especially problematic
• Because we only fully control
• One of Four specificity categories
• (Class and attribute selectors)
• All the rest are limited in some way

• So we spend our time
• Arguing over how many classes or attributes to use
• Forcing lower and lower specificity
• Through intricate naming conventions…

• Or carefully organizing our code-base
• (This is Harry Robert’s Inverted Triangle)
• Useful for thinking about the ideal relationship
• Between a selector’s reach and specificity
• From the top, most styles low specificity, broad reach
• Get more explicit, increase specificity, less code

• Useful to think about our styles in layers
• From generic to specific
• Starting with abstract, broad settings and tools
• Through generic elements, objects,
• More specific components
• To very few, narrowly targeted overrides

• Organize codebase low-to-high specificity
• It’s a great system (we’ll talk about it more)
• But it requires careful coordination…

• Which can fall apart
• If someone brings importance
• To a specificity fight…

• Or a third-party tool
• Doesn’t play by the same rules

• This can get frustrating!

• And then people run away
• Looking for alternatives to CSS!
• That’s not good for anyone

• To quote from Ben Myers excellent article…
• When we build with accessible semantics
• We get meaningful style hooks for free

• Converting semantic selectors to single classes is a lossy transform
• Doing the browser’s job, but worse
• Name more things on every project
• Like compressing a photo too far, it’s blurry now
• We’re losing info about intent, and specificity…

• Specificity is useful

demo:

• We want modifiers to override defaults
• Source order is fragile

• When specificity falls short
• We need an escape hatch
• that’s still meaningful and expressive

• That’s why we added Cascade Layers
• Proposed at the end of 2019, and already…

• Well supported across browsers
• For 2 years now

• Added to the cascade before specificity
• Applied first
• More powerful than specificity

• Designed to match this Inverted Triangle idea
• Organizing CSS into layers
• From broad abstractions with lower-priority
• (Resets, defaults, etc)
• To more specific and higher priority details
• (Components and overrides)

• We can take those same layers
• And make them explicit in CSS
• With the at-layer rule
• These provide us with…

• Layers of specificity
• First we choose the declaration
• In the highest layer
• And only if there are multiple from that layer
• Then we compare specificity

• 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
• Any name we want

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

• Generally, imports have to come first
• Layer lists are allowed before imports
• Order matters!

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

• The goal is balance

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

• Reasonable thing to put in a reset
• Reasonable for reset to have low priority
• But we don’t want future layers to override this one declaration

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

• ID’s are often used in forms, aria-roles, etc
• We can also use them in CSS, without the specificity

• Repeated attrs/IDs increase specificity
• Without changing the subject

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

• They select the same elements

• The final step in the cascade
• Order of appearance
• Guarantees a single answer

• If we still have multiple declarations
• Same origin & importance, same context
• Similarly attached or mapped from selectors
• Same layer, specificity, and scope proximity
• Then one has to come last
• No way to get a tie at this point

• This also becomes useful
• When we want to use new features in CSS
• Legacy browsers will throw out the declaration they don’t understand (oklch color)
• But modern browsers will have to choose one
• Put them in order, so most modern wins

• That’s technically the end of the cascade
• No more official steps

• But there are still styles to handle
• And browsers have a choice
• About where to fit them into the cascade
• These are non-CSS ‘presentation hints’
• Provided in HTML…

• Things like width and height on an image
• Or the hidden attribute
• Part of the markup
• But clearly related to the styling,
• Hinting at styles

• Browsers are allowed to add these
• To either the browser origin
• Or a special author-hints origin
• Below our normal author origins
• Either way, CSS always wins over these hints

• 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)
• here we fit into the larger process

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

• Describing the intent of each declaration
• And how it should be merged with other declarations

• As part of our style collaboration
• With browsers, users,
• and (hopefully) aliens
• Most importantly…