Cascading Styles

• You don’t need to memorize everything
• Understand the mental model
• Understand what’s possible
• Q&A at end of each day
• Also ok pause and discuss!

• Any questions before we start?
• We’re here to talk about…

• CHSS
• Håkon Lie, 1994
• email, still archived online

• not the only
• not the first
• solves a major problem for the new platform

• not technical
• but philosophical
• political, like all decisions we make
• designing a new platform or interface

• Team at CERN
• first web browser
• Hypermedia WWW Browser and Editor
• NeXt machine
• graphic interface

You can’t make a web that’s world-wide, by saying it works on my machine, and everyone else is an edge-case.

• Nicola Pellow
• Line Mode browser
• text-only
• no install
• any device with an internet connection

• Mission statement of W3C

• includes a range of assistive technologies
• like this braille display
• or ‘screen readers’ which read what’s on the screen

• also devices without any screen involved

• The web is getting everywhere
• And it’s kinda gross

• If we really want this to work
• Everywhere for everyone

• leads to difficult constraints
• documented on the original website
• also still available

• browsers ignore code they don’t understand

[DEMO]

• individual attributes
• entire HTML tags

• the code is optional
• the content is essential
• whatever else happens
• browsers should protect the content
• that’s why…

• we can still see
• first website on modern browsers

• modern website, on the first browser
• (this is an emulator you can play with)
• No css
• No images
• all the text is there

• for graphic design
• limitation is more dramatic
• to be a common language anywhere…

• problem isn’t styles
• early browsers internal stylesheets

• Even text-only browser
• headings, paragraphs, etc
• But the styles are different per browser
• not per website

• not the way print works
• define everything…
• page size (static, forever)
• export to PDF, jpg,
• send it to the printer

• It just sits there
• The same was true for other digital formats at the time…

• PostScript around almost a decade
• page description language
• Like print
• describes a static page
• how big is it? where does each thing go?
• We set fonts, colors, etc.
• We have complete control, but…

• That control comes at a cost
• The page, print or PDF, is a static medium
• can’t adapt to context or preferences
• a limitation of the medium

• web is different
• for everyone, on everything
• sites aren’t static pages
• what we ship is not always what our audience sees
• styles must adapt to situations…

• Not just the width of the viewport

• user needs & preferences

• device interfaces

• changing capabilities over time

• Content that’s always changing

• Under those constraints
• Unknown content, unknown display, unknown overrides
• web design (reasonably) seemed impossible, but…

• No one was happy with that outcome
• When every site looks the same
• That’s boring for both authors and users
• People want visual creativity

• Turning point, 1993
• Mosaic added image tag to HTML
• (Before web standards)
• web styles suddenly possible
• put everything in an image, and it never changes!

• or it doesn’t show up at all
• and we lose everything that makes HTML special
• Can’t protect structured content in an image…
• If it doesn’t load, it’s lost

• A real risk to the platform

• 1993-1994
• a rush of different proposals

• author style hints

• Not rules, but hints and suggestions.
• (phrase shows up over and over)

• Sometimes all-caps
• [slide]

• In Håkon’s proposal…
• authors and publishers have
• stylistic influence
• without resorting to page description languages
• without giving us full control
• Because we’re not alone in this…

• We’re part of an ecosystem
• Our decisions impact other people
• So we don’t get final say

• We’re collaborating with browsers
• (instructed to ignore us)

• Also the people who interact with our sites
• (super cute in their handy tool belts)
• On their chosen devices
• (with varying capabilities)
• And we’re also collaborating with…

• aliens 👽
• Maybe, who knows?
• We should collaborate with them…

• just trying to get home.

The CHSS proposal is explicitly designed around this collaboration

• Designed to soften the tension

• By allowing everyone to contribute styles
• In an orderly fashion
• Using the same language!
• First the browser and user,
• and then the document

• Each of us writing
• our style hints as declarations,
• a property and a value

• In the initial proposal
• We could also add a percentage to every declaration
• How much we care
• Here we’re handing over exactly 36% of the influence
• To our collaborators

• That idea was simplified later
• Into a binary
• Every declaration has either 0% or 100% importance
• But we’ll come back to that

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

• Then 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
• coming from different sources
• likely applying different values
• to the same properties, on the same elements!
• What are we going to do?
• Stack all these background colors on top of each other?
• Create a rainbow gradient?

• Mix them together into a sludge?
• This was the original idea,

• Remember those importance percentages?
• We could use them for mixing!
• But the results aren’t great
• And it’s not clear how you would ‘mix’ something like a font

• Although I wish we had tried harder on that one

• Browsers must resolve conflicts somehow
• Before they can render the page
• Every CSS property
• on every HTML element
• must have a single value

• All 595 distinct properties
• (or at least the long-hands from that list)

• 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
• We’re not going to set all 500 some every time

• Both ‘cascading’ and ‘inheritance’
• Part of a process called value resolution
• A series of steps for converting declarations into a rendered site

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

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

• Each step gets us closer to the actual value
• Applied when rendering an element

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

• to thunder-dome our declarations
• 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 priority
• Of our hints and suggestions.
• Makes the collaboration possible

• We’ll skip filtering for now
• That involves parsing all the CSS
• And narrowing down a list of all the declared values
• That are relevant for styling an element
• Now we know what conflicts exists

• And we can resolve any conflicts between them
• By cascading the declared values together

• Cascade works like a coin sorter
• Measuring the priority of each declaration
• See which ones go farthest

• We do this over and over
• Until we have a single coin
• Each time comparing different aspects
• Not just size, but shape, width, metal, whatever

• At each step
• the coins that made it the farthest move on
• Everything else is discarded…
• We can ignore all but the final column with coins
• Ok, but not coins -

• We’re talking about declarations.
• So what are the things we can measure and compare?

• (any thoughts)?
• There are 7 steps now in the cascade
• And the first step has two parts

1. Who requested it? (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 layer is it in? (cascade layers)
6. How specific is the selector? (specificity!)
7. How close is the scope root? (proximity, new)
8. Which value was declared last? (order, single)

• From the top
• What’s the origin of the declaration?
• Who requested it?

• How much do they care?
• Did they mark this style as important?
• These are directly related, part of the same step

• We could split these
• With importance out in front
• Important styles will always win
• Over normal styles
• But if we stop there, we’re missing the point

• This isn’t a magic trump card
• For stomping around and killing our enemies

• This is about collaboration

• Softening the tension
• Between author and reader
• So we take turns
• By default…

• The user and browser
• Specify initial preferences
• Tend to be global
• Apply to every website we 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…

• Initial values
• Are defined for each property
• The same on all elements
• Always display:inline, even on divs…

• Browsers add display:block
• everywhere we expect it

• They also add things like
• 8px margin on the body
• Link colors and underlines
• Heading styles, large bold text
• Space around paragraphs and lists, etc

• These are the user agent styles
• And they apply to every site on the web
• With only minor differences between browsers

• After browser defaults
• Users apply their preferences

• Originally using CSS syntax as well

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

• Most other browsers have switched
• To providing limited preferences through a graphic interface

• The details are different
• But the results are the same
• Users get to have preferences

• And remember,
• When we talk about ‘users’ or ‘readers’
• on the web…

• That’s all of us
• We’re talking about all of us
• We all use the web

• We’re all allowed to have preferences
• I set a few, and recommend trying it
• Worried as dev “but I’ll see something different”
• That’s the point!
• Remember to check with different settings

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

• We come last, and get highest priority
• We override the user preferences
• Which override the browser defaults

• So we can kinda just do whatever
• Smear our brands all over everything

• But we tend to stomp around
• choking people with our special powers
• So that’s not great

• That’s the tension
• Håkon wanted to soften
• Between authors and readers,
• And he was clear that

• If conflicts arise
• The user should have the last word

• That’s why we have importance

• A way for the other origins
• To take back control when it matters,
• and bring balance to the cascade…
• When anyone adds !important to a declaration…

• It creates a new origin
• One of three important origins
• All higher priority than the normal origins
• But with their 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

• Important origins do always win,
• But the real purpose is to keep us contained,
• stuck there in the middle
• Our normal and important styles next to each other
• Where we can’t cause too much harm

• 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 origin of a style
• And it flips the priority of origins.
• The purpose…

• Is not for fighting amongst ourselves
• To override styles that came before us

• The purpose is for users and browsers
• To protect from future origins
• Styles that might get added by the document author

• We’re the baddies here
• We think we’re the boss of the web,
• but we’re not

• And the fact that our origins
• (Normal and important)
• Are isolated together
• Means we don’t always notice
• 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

• Technically two additional origins
• For ‘intermediate’ styles,
• Generated by animations & transitions

• If we define the two endpoints
• (say HotPink to Teal)
• The browser has to go through other colors…

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

• Because both endpoints of a transition
• Have their own origins and importance…

• Transitioning values have to override everything
• We’ve all had our say by that point

• Animations are different
• Only the animation property cascades
• Keyframes live outside the cascade, disconnected

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

• So we still need a way to override the results of an animation
• Animated styles slot in between normal and important styles

• Important styles always win
• Importance also splits us into a different path
• Changes how every following step works
• For example…
• Light DOM styles override shadow DOM styles
• Unless we add !important, and then it’s reversed

• This is called Context in the cascade
• It’s like ‘origin’
• But for web components

• Web components are designed to act like custom HTML
• So shadow DOM styles act kinda like browser defaults

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

• Element attached (or inline) styles are the exception
• There’s no reversal here
• inline styles win when declarations have the same importance
• But Cascade Layers reverse
• for the same reason origins do

• Layers were proposed at the end of 2019, and already…

• Well supported across browsers
• For almost 3 years

• They give us a way to organize our code
• And help us manage the cascade

• Layers of specificity
• The declaration in the highest layer wins
• Before we bother to compare specificity
• Within the winning layer
• We’ll look at that more when we talk about organizing conventions

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

• 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

• There’s more in here to talk about
• And we’ll come back throughout the workshops
• Get into some of the weeds

• Not just one-offs that we copy-and-paste

• Or static documents that we export once

• And then pass back and forth
• Like a fax machine

• Across different browsers and devices
• Different interfaces
• The needs or preferences of different users

• Our needs
• And our preferences
• All of us

• Because the web is for everyone

• And is designed to work everywhere

• And the cascade is fundamental to that goal
• What makes it possible

• Allowing us to style collaboratively
• With browsers, users,
• (and hopefully aliens)

• By taking into account
• the purpose and priority of each style
• For the browser to use

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 layer is it in? (cascade layers)
6. How specific is the selector? (specificity!)
7. How close is the scope root? (proximity, new)
8. Which value was declared last? (order, single)

• The goal here is unlike any other medium.
• We’re doing [quote]
• It’s absurd, but the cascade helps make it happen
• So long as we follow the most important rule…