Variables & Value Resolution

• Variables are common in programming
• Capture, store, and access values

• In CSS that has often meant
• Global ‘design tokens’
• brand colors, sizes, fonts, etc

• Don’t have to be global
• Don’t have to be simple

• Broadly any CSS value we want to re-use

• What is this color?
• A mix of darkRed and mediumBlue?
• With variables we can give it
• A meaningful name, based on…

• What it looks like
• (deep raspberry)

• Why we chose it
• (the best color)

• What it signifies
• (action, maybe)

• Where we’ll use it
• (link text and button backgrounds?)

• Or all of the above?
• We can use one variable to name the next
• Creating different layers of meaning

• Like audio patch bays
• Connecting an input to an output
• With a physical cable

• Widely supported since 2016…

• Two names
• These are Custom Properties, that we define
• Which can be used as Cascading Variables
• That’s in some ways a strange combination
• And means they don’t work the same as variables in most languages
• Instead, they act…

• Like any other property in CSS
• They are directly attached to elements,

• We can declare a value in CSS
• Using a normal declaration syntax,
• (property and value)
• But we come up with the property name
• And it has to start with a double-dash

• This is called a ‘dashed ident’ in CSS
• Not only used for custom props
• But anywhere a ‘custom identifier’
• (something we name as authors)
• Might share space with built-in CSS keywords

• In this case, sharing space with built-in properties
• Need to tell the difference
• Avoid conflicts in the future

• The syntax comes from browser prefixes
• Which have (mostly) been phased out
• Remove the browser name, and now it’s ours

• We can attach that declaration to elements
• And it will go through the whole process of cascading and defaulting
• On each element, the same as a built-in property
• Except that it won’t do anything…

• Until we apply it to an actual built-in property…
• That’s the whole point!
• We get to decide where and when to use these values

• Which we access from the var function
• Var, parenthesis, the name of the custom property

• Like the audio signal in these cables,
• We don’t hear any sound
• Until we plug that signal into a speaker of some kind
• An amplifier,
• Something that turns signal into noise

• In CSS
• Normal properties are the amplifier

• Turning silent ‘tokens’ into rendered styles

• But since these are ‘custom’ properties
• They don’t have any initial value
• Except the ‘guaranteed invalid value’ which we’ll discuss

• And since we’re not usually defining them on every element
• We’re often going to rely on inheritance

• It’s very popular to define some or all custom properties
• In one place, on the root element
• And expect them to inherit everywhere.
• So let’s look at inheritance!

• Once the cascade is done filtering out
• Conflicting values…

• The ‘defaulting’ process fills in missing values
• Leaving us exactly one value per property per element
• That’s true for built-in and custom properties…

• But the details
• depend on the specific property in question

• Some properties inherit a value from context
• This is not true for the majority of properties
• To visualize how this works…

• Start with all these nested boxes
• Assume they are un-styled boxed

• Cascade goes first
• Explicit selectors & declarations
• Styles attached to individual elements
• Not everything gets style…

• So after the cascade is complete,
• And only when values are missing,
• Then we can apply inheritance
• Each (un-styled) box looking at it’s parent
• Values can inherit from very high up, the root of the document
• All the way in to an element nested deeply
• But to get there, properties have to inherit one nested element at a time

• Without any cascaded values breaking that lineage
• You don’t inherit a trait from your grandparents,
• Unless your parents inherited that trait from their parents
• So we can always look at the computed value of the direct parent
• To find the value that inherits

• We could say the cascade takes priority over inheritance
• In the same way origins and layers take priority over specificity
• Because the cascade goes first
• So inheritance only fills in what the cascade leaves open
• And values higher up can’t inherit through a cascaded value
• That context is lost and a new context is established

demo:

• Here the color inherits fine on everything, from the root
• But the font (even though it’s important) can’t inherit
• Wherever it is set by the cascade (blockquote, and code)

[demo]:

• cascaded declarations first
• (our element is the subject)
• (sorted by cascade priority)
• inherited declarations
• (our element is a descendant)
• (sorted by inheritance proximity)
• together: all the relevant declarations
• and which one applies!
• computed… still missing values for most props

• So now we have properties
• That can capture the context in one location,
• And carry that context silently to descendants
• Until it’s needed

• Let’s look at a property that doesn’t inherit
• Like the background
• We can either be explicit to target with nested selectors
• Or we can pass the value through a variable!

• Like scope, inheritance rewards proximity
• When we nest, the closer context is what inherits

• We can also use custom properties
• To carry some context past intervening cascade values
• We can use this to revert to context higher up

• So we can ask ourselves
• If I inserted a span in the middle of this paragraph
• What styles would need to inherit
• So that the span doesn’t look different?

[demo]:

• Try all:initial on the span
• Try inheriting different properties

• This is one reason I recommend the simplest box-sizing reset
• We shouldn’t be inheriting layout!
• Especially not as a default!

• Spec here is brief (see next slide)…

[Demo lookup]:

• pick a property (display?)
• Look it up on MDN
• Check ‘formal definition’
• (shows inherited, and initial)
• Link to spec
• (same)

• What happens if we access a property
• That we never defined?

• All custom properties get the same initial value by default
• We call it ‘the guaranteed invalid value’
• No syntax for it, yet (I think we should add one)
• It’s only used in custom properties
• And this will surprise you…
• it’s guaranteed to be invalid on every built-in property

• If it ends up on a property,
• Invalid at computed value time
• Since it’s guaranteed, we know earlier in the process
• Not early enough discard before the cascade…
• We have to finish the cascade and inheritance

• We’ll come back to this idea
• When we talk about progressive enhancement

• But at that point when we are about replace our var function
• with a value we now know is invalid
• We can use a fallback instead

• The fallback comes after the name and a comma

• Everything after that first comma is the fallback value
• Even if it contains more commas
• That way we can fallback to list values

• We can also fallback to other variables
• And those variables can have a fallback
• So we can create chains of fallback options
• By nesting var functions

• This is not validation that the value is allowed on the property
• We only get the fallback
• If our custom property has no value at all
• Or is using the initial guaranteed invalid value

• So it also doesn’t work for legacy support fallbacks

• Here’s a demo if you want to dig into the nuance
• We’ll look at it in more detail
• When we talk about progressive enhancement

• Ok, we’ve almost done it
• Still need to deal with…

• Explicit defaults
• These are the global keywords in CSS
• Which are allowed on every property
• including the all shorthand property

• In fact, these are the only values allowed on all
• Since they are the only values allowed everywhere

• Rarely use these
• Only if you are very sure it’s what you want

• Prefer unset instead
• To get either the initial or inherited value
• Depending on the property

• This is a great option for CSS resets
• When you really want a clean slate.
• Just ‘pretend no one ever defined this property,’
• ‘and see what happens’

• But this still has the problem
• Of mostly returning the initial value,
• Like display:inline
• When it’s more common that we would want…

• Is the browser default styles
• Revert will unset only the author styles
• But keep browser defaults in place
• ‘Pretend We didn’t define this, and see what happens’
• But even this can be more than we want
• Ideally, we could return to our own defaults!
• Not only that, but revert

• Also eliminates presentational hints
• This is the situation where they act like part of the author origin
• And shadow DOM styles
• That’s still pretty destructive if we’re not sure about it
• But we can solve all these issues by using…

• revert-layer
• This is the most chill of the explicit defaults
• It will only unset our current cascade layer
• Leaving everything else in place
• So we can fall back to a lower layer,
• or shadow DOM, or presentational hints, or browser defaults
• or even the initial or inherited value
• If a property isn’t defined in a lower layer

• We usually use unset or one of the revert values

• Global keywords on all properties
• Including custom properties

• No way to pass keywords along as values
• Importance also applies to the variable!

• The next step of value resolution
• Is to get the ‘computed’ value
• making any relative values absolute

• Computed values inherit
• Which might sound backwards, since we already handled inheritance!
• But this whole process happens outside-in
• The parent has to resolve, so children can inherit,
• And then they have to resolve before the next generation can inherit

• This is all starting to sound like genetics
• Or maybe estate law?
• I am not a biologist or a lawyer,
• So don’t take this as legal advice.

• There are exceptions
• CurrentColor inherits as a keyword, which is handy
• It will re-calculate as the color changes

• Value hasn’t been parsed/validated
• Not clear yet what type this is
• Can’t make it absolute without a type
• Or, for relative units like lh knowing what line to measure

• Custom properties don’t resolve before inheriting
• But they do substitute before inheriting
• Not

demo:

• see ‘computed’ panel
• custom properties aren’t resolving?
• only one! let’s look into that…

• We’ve talked about defaults
• But some custom properties dream of becoming more…

• And we can use to the at-property rule
• To define more about them,
• The stuff that usually gets defined in a spec
• For built-in properties
• The syntax, initial value, and if it should inherit or not

• This is finally, recently, supported everywhere!

• Remember, if we don’t register the property
• Inheritance is true by default
• We can override that by defaulting it explicitly everywhere
• That doesn’t turn off inheritance,
• Just ensures we never get around to inheriting
• Because there’s always a declared value

• Definitions are still not
• available at parse time (could be redefined)
• or stable enough to rely on (if new styles load)

demo:

• remove and re-add registration
• inspect computed values
• change to universal syntax (doesn’t compute)
• change to color syntax (invalid)

• There’s a workaround by Jane Ori
• Using trigonometry functions
• If you want to play with it

• initial values equivalent to spec initial
• Not right for every situation,
• But a good fallback
• Declarations on root/* better for dynamic tokens

• All properties that apply
• But some props might not apply
• Because CSS properties are modal!
• (e.g. flex: 1 on a non-flex item)
• (or display:inline any time it’s not in flow)
• Usually the same as ‘computed’ value

• That’s it,
• the entire ‘value resolution’ process

• Any questions on that,
• before we get into
• more variable use-cases?

• These tokens will inherit everywhere

• Either root or html is fine
• In any html document, select the same thing
• Maybe you find it more clear?
• Mostly just increases specificity
• (Element type to Pseudo-Class)

• It’s true!
• But is it actually what you want?

demo:

• just an svg on it’s own
• root styles apply to the svg element

demo:

• same svg in a page
• (styles commented out)
• html styles targeting the root & svg…
• what happens when we uncomment?

• It’s not bad to put vars on root
• But careful about using root
• In nested contexts
• Not every root, only the (outermost) root

• Another global approach
• Select everything
• Rely on cascade, not inheritance

• Not all design tokens need to be global

• Can also define locally
• Specific to a component

• Even variations of a component

• We can combine these approaches
• Define on everything in a certain context

• You don’t need to define anywhere to start
• Sometimes useful to have ‘open’ (undefined) vars…

• Creating a button component
• We can put the default value in a fallback
• And leave the variable open for inheritance
• Then later, we can fill it in…

• Override based on specific locations
• Or based on different variations
• In the component or interaction state

• Great for dynamic changes, like…

• I’ve been updating that to use oklch colors
• With color-scheme and the light-dark function
• But many of those features are still too new
• To rely on without a thoughtful fallback