# Custom Cascades

by defining a cascade of custom properties,
you can determine which intent should take priority --
without worrying about the specificity
of how that value is defined.
in this case, my cascade includes:

- `--btn-bg--state`
- `--btn-bg`
- `--btn-bg--type`
- `--btn-bg--default`

Our default button is falling all the way back
to the `--btn-bg--default` defined on `html` .

Adding the `disabled` attribute
always overrides any other button colors --
no matter where they are defined.

We can create button types using `--btn-bg--type` ,
and it will override the defaults,
but not the state:

## Context & Specificity

We can also set these values contextually,
rather than directly styling the button.
Values can come from anywhere,
and true specificity only resolves conflicts
between the same custom property.

In this case I set all form-buttons to use
`deeppink` as the default, rather than `blue` .
we can make contextual changes at a higher level
of the cascade, if we want --
like "disabling" the entire form.

If we need to change a button based on user-input,
or otherwise set it via html,
we can do that too.
I'm doing that with `--btn-bg`
which comes second in the cascade.

and we avoid the usual danger from inline styles high specificity.
Because `state` is first in the cascade,
it will always override the higher-specificity inline style: