# 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`.

<button type="button">default</button>

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

<button type="button" disabled>disabled</button>

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

<button type="button" class="warn">warn</button>
<button type="button" class="go">go</button>
<button type="button" class="warn" disabled>warn disabled</button>
<button type="button" class="go" disabled>go disabled</button>

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

<form>
  
  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.
  
  <button type="button">default</button>
    
  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.
  
  <button type="button" style="--btn-bg: rebeccapurple;">override</button>
  
  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:
  
  <button type="button" style="--btn-bg: rebeccapurple;" disabled>override disabled</button>
</form>