Pen Settings

HTML

CSS

CSS Base

Vendor Prefixing

Add External Stylesheets/Pens

Any URL's added here will be added as <link>s in order, and before the CSS in the editor. If you link to another Pen, it will include the CSS from that Pen. If the preprocessor matches, it will attempt to combine them before processing.

+ add another resource

JavaScript

Babel is required to process package imports. If you need a different preprocessor remove all packages first.

Add External Scripts/Pens

Any URL's added here will be added as <script>s in order, and run before the JavaScript in the editor. You can use the URL of any other Pen and it will include the JavaScript from that Pen.

+ add another resource

Behavior

Save Automatically?

If active, Pens will autosave every 30 seconds after being saved once.

Auto-Updating Preview

If enabled, the preview panel updates automatically as you code. If disabled, use the "Run" button to update.

Format on Save

If enabled, your code will be formatted when you actively save your Pen. Note: your code becomes un-folded during formatting.

Editor Settings

Code Indentation

Want to change your Syntax Highlighting theme, Fonts and more?

Visit your global Editor Settings.

HTML

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

              
            
!

CSS

              
                /* in-practice */
html {
  --btn-bg--theme: rebeccapurple;
  --btn--theme: white;
}

button {
  background: var(--btn-bg--state, var(--btn-bg, var(--btn-bg--type, var(--btn-bg--theme))));
  color: var(--btn--state, var(--btn, var(--btn--type, var(--btn--theme))));
  border: 1px solid currentcolor;
  padding: 0.5em 2em;
}

[disabled] {
  --btn-bg--state: gray;
}

[data-type='warning'] {
  --btn-bg--theme: maroon;
}

/* in-theory: 4*4 property "origins" for color */
/* some day…
@property --color-1-1 {
  syntax: "<color>";
  inherits: false;
} */

* { 
  --color-1-1: initial;
  --color-1-2: initial;
  --color-1-3: initial;
  --color-1-4: initial;
  --color-2-1: initial;
  --color-2-2: initial;
  --color-2-3: initial;
  --color-2-4: initial;
  --color-3-1: initial;
  --color-3-2: initial;
  --color-3-3: initial;
  --color-3-4: initial;
  --color-4-1: initial;
  --color-4-2: initial;
  --color-4-3: initial;
  --color-4-4: initial;
  --color-1: var(--color-1-4, var(--color-1-3, var(--color-1-2, var(--color-1-1))));
  --color-2: var(--color-2-4, var(--color-2-3, var(--color-2-2, var(--color-2-1, var(--color-1)))));
  --color-3: var(--color-3-4, var(--color-3-3, var(--color-3-2, var(--color-3-1, var(--color-2)))));
  --color-4: var(--color-4-4, var(--color-4-3, var(--color-4-2, var(--color-4-1, var(--color-3)))));
  color: var(--color-4, inherit);
}


/* Property "origin" takes precedence over specificity */
#title {
  --color-1-1: maroon;
}

h1 {
  --color-2-1: deeppink;
}


/* specificity still applies when origins match */
#title em {
  --color-1-1: rebeccapurple;
}

h1 em {
  --color-1-1: red;
}


/* Scopes */
article,
form {
  border: 1px solid;
  margin: 0.5em;
  padding: 0.5em;
}

#article {
  --btn-bg: maroon;
}

form {
  --btn-bg: green;
}

/* basic page layout… */
body {
  max-width: 34em;
  padding: 1em;
  margin: 0 auto;
}

code {
  background: #eef;
  display: inline-block;
  padding: 0 0.3em;
  border-radius: 0.1em;
}
              
            
!

JS

              
                
              
            
!
999px

Console