I think you are demonstrating the title of this article. The --color variable is inherited through your style sheet cascade, just like any built-in property would be. In other words, CSS variables are pretty much custom properties.

In the last line of CSS, you went on to equate a built-in property with the value of the variable everywhere. So you’ve essentially made a new “property” that works just like the builtin color property.

(Disclaimer: I’m not an expert in modern CSS, so this could be imprecise.)

    #alert { color: red }
    * { color: blue }

I agree it's messed up but programming examples often are in order to convey some information.

A css property is set at a context, for example

body {color: blue}

div { color: green }

#alert {color: red}

https://codepen.io/bryanrasmussen/pen/PwNQyOm

this would be preferable to what was done variables because it is more straightforward. The dumb example of custom property using you highlight does not help make clearer code, nor does it help make css easier to understand, but I guess they were hoping people would see that custom properties inherit basically the same way that other properties inherit, except that there is this freaky :root context instead of using body.

obviously things can be complicated because only some properties inherit, but the claim holds. CSS properties are set by context.

The <p> tag is red because it is inside of #alert. Anything inside of #alert has the color variable set to red.

Variables don't use specificity like CSS selectors. I prefer to create a few layers for variables; one for color names, one that maps color name variables to global semantic names (i.e. --primary-cta-color: var(--blue-50) or something), and maybe go so far as to add another that maps component-specific semantics to global specific semantics (i.e. --date-picker-hover-color: var(--primary-cta-color)).

That way, you can add something like

    .theme-1 {
        --primary-cta-color: var(--blue-50);
    }

    .theme-2 {
        --primary-cta-color: var(--brown-40);
    }

and / or

    @media (prefers-color-scheme: dark) {
        .theme-1 {
            --primary-color: var(--grey-30);
        }
        .theme-2 {
            --primary-color: var(--brown-10);
        }
    }

as a purely hypothetical example. Slap the class name your user wants on the body tag, and you're good to go.

It's very straightforward. It doesn't matter whether the property name starts with -- or not, it behaves exactly the same way in terms of inheritance.

wow great example - I'm also baffled by this. is this just not a great example because it seems like it's reinventing the wheel

Not by themselves, at least today, as we can't currently modify the value of a custom property by using itself in the calculation. But in the future we will have an `inherit()` functional notation that will unlock this (and at least Chrome implemented it in Canary already — https://blog.kizu.dev/play-with-inherit-function/).

It is possible to use style queries and some hacks (https://kizu.dev/self-modifying-variables/) to achieve this today, but that doesn't bring this closer to production, as Firefox still does not support them (but will be soon).

Variables are defined and cascade the same as any other property. You can define variables and other properties on the third-level x element in your markup like so:

  x > x > x {
    --my-variable: 'my-value';
    display: inline;
    /* etc. */
  }

It would be used by defining the value of another property as the value of the variable. Note the selectors don't have to match; in this case all x elements will have their content properties set to the --my-variable value but only the third-nested x element will have a --my-variable value set.

  x {
    content: var(--my-variable);
  }

Not that this is a particularly coherent example but hopefully you get the idea.

Why so? By adding --foo: bar to a selector, you’re actually adding a new, custom, property named --foo to it, just as the display in display: block would be another property.

It’s not a bad analogy, but how the spec intends it to work.

It is a language, just not a turing complete one.

Pidgen is a type of language, too, but you wouldn't be writing Shakespeare in it.

There's nothing to be pedantic about HTML here, and it just seems so absolutely pointless to me that people try to find a way to be.

I've seen HTML and CSS being denied status as a programming language many, many times. It is a signal that the person making the claim hasn't encountered one of these debates before.

Yes, it is a programming language. And so is HTML, LaTeX, heck even Markup is a programming language. The shapes of discs you put into your 1950s Elna Supermatic sewing machine that alters the stitch, also a programing language.

The only requirements is that it compiles into a set of instructions which computers (or sewing machines, etc.) know how to read and execute into a predictable (preferably desired) outcome.

A programming language does not need to be Turing complete to be a programming language.

It is one...

Then they drag-and-drop the project folder into FileZilla connected to their FTP shared hosting and send the invoice to the client.

Although... while this seems like heaven at first, seeing this being done in practice, it is hell. It's just people don't know they are in hell. They got used to it.

CSS has been steadily improving across browsers, addressing pain points and real world scenarios.

CSS grid and subgrid, nesting, variables, container queries, css layers…

In 2025 it’s a pleasure to work with. Props to the amazing people involved in pushing the standards forward.

No way. There have been so many nice improvements to all of those languages over the last two decades that make development so much safer to implement, faster to code, and easier to test. I personally would lose my mind if I had to go back to the way things were running 20 years ago

Swap PHP with C# and we're in full agreement.

I'm not a CSS expert but being able to do so much with it before having to reach for JS is fantastic.

And with Blazor, some of that JS sprinkle isn't even needed anymore.

Eh. I've found that increasing use of CSS variables / custom properties has made me a much happier developer. Sometimes new things aren't necessarily bad.

the happiest software developers are those who write apps that run in a single command line process on a local linux machine (:

Given the ageist in tech, I would guess most devs actually writing code were still children 20 years ago and some were still babies so I don't think they are used to life before build tool JS. And writing plain js is outrageous like stepping outside in your underwear.

Funnily enough, I did all that.

And it made me want to claw my eyes out.

Browser idiosyncrasies, horrendous security vulnerabilities, the blood sacrifices to do basic things with CSS, trying to debug in IE, the daily “maybe Flash isn’t that bad” introspection.

There are many good things about this world.

2005 web dev is not among them.

[dead]

I'd also say HTML4 is much nicer to write than HTML5. I know it's technically "obsolete", but it was more pleasant to work with (and allows your site to be accessible on almost every browser/version).

"Web Components" is a term I do try to avoid though. "Components" is a word loaded with very specific meaning to a lot of JS folk, and it can be really hard to describe the ways in which a "Web Component" does not behave like a "React Component" for example. "Custom Elements" is meaningfully useful to push for!!

This would make sense if we defined them by inheriting `HTMLComponent` (https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement) and registered them with the DOM using `document.createComponent` (https://developer.mozilla.org/en-US/docs/Web/API/Document/cr...).