<h1 id="title" class="in-theory">Custom (<em>Property</em>) Cascades</h1>

<h2>"Custom Origins"</h2>
<p>
  I often use short variable stacks
  to create a property-specific "cascade"
  based on different "origins" of a style:
  user, theme, component patterns, states, etc.
  For these buttons,
  I used state > 'btn' > type > theme, 
  where 'btn' allows explicit one-off settings.
</p>

<button>theme default</button>
<button disabled>disabled theme</button> <br>
<button data-type="warning">warning type</button>
<button disabled data-type="warning">disabled warning</button> <br>
<button style="--btn-bg: green">green btn</button>
<button disabled style="--btn-bg: green">disabled green</button>

<p>
  No matter where these variables are defined,
  they will always stack in the same order.
  Since btn "state" is given top priority,
  it will always override theme and type --
  even "btn" colors that are set with the inline style attribute.
  Specificity only matters when
  <em>the same variable</em>
  is being set in two places.
</p>

<p>
  I noticed recently that <em>in theory</em>
  this creates a rough approximation
  of "<a href="https://github.com/w3c/csswg-drafts/issues/4470">Custom Origins</a>" --
  a proposed spec that I'm working on
  with the W3C.
</p>

<p>
  The cascade works by accepting multiple versions
  of a property declaration,
  and then choosing between them
  based on a set of filtering criteria:
</p>

<ol>
  <li>
    <strong>origin</strong> and <strong>importance</strong></li>
  <li>
    <strong>specificity</strong>
    <ol>
      <li>ids</li>
      <li>classes & attributes</li>
      <li>types</li>
    </ol>
  </li>
  <li><strong>source order</strong></li>
</ol>

<p>
  Specificity is only considered
  when there are multiple values
  from the highest-weight origin --
  and source-order is only considered
  if origins, importance, ids, attributes, and types
  all fail to filter out a winner.
</p>

<p>
  The idea of a "custom origin"
  is that it provides a layer between
  existing origin/importance rules,
  and specificity.
</p>

<ol>
  <li>origin and importance</li>
  <li>
    <strong>custom origins???</strong>
    <ol>
      <li>custom origin 1</li>
      <li>custom origin 2</li>
      <li>etc…</li>
    </ol>
  </li>
  <li>
    specificity
    <ol>
      <li>ids</li>
      <li>classes & attributes</li>
      <li>types</li>
    </ol>
  </li>
  <li>source order</li>
</ol>

<p>
  Given the right setup,
  custom property stacks can achieve the same goal --
  and even be nested for more complex layering within origins.
  While I use small, selective "stacks"
  (like the button example in production,
  it can be taken much farther.
  Let's do that!
</p>

<p>
  Here I've established four variable "origins"
  on the `color` property 
  (<code>--color-[1-4]</code>), 
  each with four sub-origins 
  (<code>--color-[1-4]-[1-4]</code>).
  These variables are applied to every element
  with the universal selctor.
</p>

<p>
  We do that to avoid inheritance of the 
  <em>origin variables</em> themselves,
  and only inherit 
  the <code>color</code> property results.
  That matches the normal cascade,
  where specificiy overrides inheritance.
  Eachvalue
  can be re-specified on
  any element from any origin --
  without needing to override
  higher-origin settings on an ancestor.
</p>

<p>
  You can see this applied to the
  <code>h1#title</code>
  headline of this page.
  The <code>title</code> ID has a color of 
  <code>maroon</code> set on the lowest
  <code>--color-1-1</code> color origin.
  The <code>h1</code> tag is lower specificity,
  but applies <code>deeppink</code>
  to a higher origin (<code>--color-2-1</code>) --
  which takes precedence.
</p>

<p>
  That's not to say specificity is ignored.
  As with the normal cascade,
  we move to the next layer in case of a tie.
  The <code>em</code> tag has a color of <code>red</code>
  set on the <code>h1 em { --color-1-1 }</code>.
  It also has a color of <code>rebeccapurple</code>
  set on the same origin,
  but at a higher specificity:
  <code>#title em { --color-1-1 }</code>.
</p>

<p>
  This example is extreme,
  and I don't recommend taking it this far in production --
  but I think it's a decent mental model
  for understanding the feature,
  and how you might use it in more targeted
  real-life situations.
</p>

<h2>"Custom Scopes"</h2>

<p>
  "Scopes" get a lot of attention these days,
  especially in the world of JS frameworks.
  There's an existing
  <a href="https://drafts.csswg.org/css-cascade-4/#cascade-scope">specification</a>,
  though implementation is not clear.
  The primary access point was meant to be
  "scoped style sheets" --
  but those have been abandoned.
</p>

<p>
  Like "origins", 
  a "scope" should be able to override specificity --
  but the goal is based more on "proximity"
  rather than layers of "intent".
  A button component has narrow scope,
  inside a broader form component,
  inside a layout.
</p>

<p>
  Specificity is <em>meant</em> to handle something like this,
  where the more "specific" selector
  overrides the less specific.
  That's a useful and related concept 
  but weights "uniqueness" over "proximity".
  The only CSS tool that gives proximity weight
  is <em>inheritance</em>.
</p>

<p>
  Again, 
  custom properties can help us 
  aproximate the idea.
  This time we only need a single variable,
  with inheritance intact.
  We're going to take advantage
  of the fact that custom properties:
</p>

<ul>
  <li>
    inherit like any other property,
    giving us <strong>proximity</strong>
  </li>
  <li>
    don't need to render 
    on the element that defines them
  </li>
</ul>

<p>
  I'll use the same
  <code>var(--btn)</code> and <code>var(--btn-bg)</code>
  That I defined earlier
  for a button's
  <code>color</code> and <code>background</code>
  properties.
  We can ignore the rest of the "origin"
  stack here.
</p>

<p>
  Now, if we set those variables
  on any "component" with a button,
  we can see that the
  most "proximate" (nearest ancestor)
  component take precedence --
  no matter what selectors are used
</p>

<button>button</button>
<article id="article">
  <button>button in article</button>
  <form>
    <p>nested form</p>
    <button>button in form</button>
  </form>
</article>