It is ok to say "CSS variables" instead of "custom properties"
61 points
2 hours ago
| 7 comments
| blog.kizu.dev
| HN
trvz
1 hour ago
[-]
The happiest software developers are those who write HTML, CSS, PHP, and just a sprinkle of JS like they used to do 20 years ago.
reply
mystifyingpoi
1 hour ago
[-]
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.

reply
bigbuppo
21 minutes ago
[-]
Hell is being the sys admin at a web hosting company.

You can either pay a web developer to update your fully static site once a year, or you can pay them five times a year to clean up your Wordpress install when it inevitably gets popped because that one mailback form plugin you demanded... you know the one that has never received a single non-spam submission... hasn't been updated in ten years... and also you're too cheap to pay someone to maintain your Wordpress site because "why would I do that the site is finished?"

reply
elaus
1 hour ago
[-]
My job requires the whole modern pipeline with Vue front ends, Quarkus services and k8s deployments and it's suitable for what we do in our teams.

But I have dozens of websites I built and am still building today in the way described and it works just as well for me. As a single developer with "simple" websites it's just great to have so little mental load when fixing some small things.

Admittedly I have a small script to upload stuff via ftp (if ssh/rsync is not available), so no FileZilla anymore :)

reply
serial_dev
20 minutes ago
[-]
I, too, settled on a minimalist process for deploying my blog, just build it with a Hugo, copy the files over to a cheap server, and there you go, deployed. It's the right tool for the job (for me).
reply
velcrovan
55 minutes ago
[-]
I still think about the person on Mastodon I saw months ago: "My deployment pipeline is to click FILE->SAVE"
reply
Gud
15 minutes ago
[-]
A workflow that sounds a lot better than 99% of what I read goes on in modern web development from comments on HN.
reply
forgetfulness
40 minutes ago
[-]
Never a git history rewrite after a declined pull request, pure “index.html_previous_3” bliss
reply
andrei_says_
1 hour ago
[-]
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.

reply
ayaros
1 hour ago
[-]
I can't argue with this.

Then again, writing stylesheets is still one of those things where, if you're not careful, everything spirals out of control. Often I'll make changes and wonder why nothing's happening and realize something was overridden by another rule somewhere, or I was mixing up two properties, or some other silly thing...

I also find it's a bit awkward to write var(--foo) every time... I wish I could just write --foo... I suppose there's a grammar issue somewhere, or maybe it would have increased the complexity of implementations of CSS.

reply
brazukadev
1 hour ago
[-]
I dont mind the var(--foo) but I wish I could do var(attr(foo)) to use a var defined in the attribute foo.
reply
Latty
8 minutes ago
[-]
`attr()` is being updated to basically do that, the modern spec lets you specify a datatype and access any attribute (with some exceptions, you can't get URL types for security reasons), then use it generally.

E.g: aspect-ratio: attr(width px) / attr(height px);

reply
interstice
23 minutes ago
[-]
To a large degree yes, but it blows my mind how complex some of the new features are when what seems like basics are still nonexistent. Root level variables for example (think media queries).
reply
JacobThreeThree
1 hour ago
[-]
Totally agree. There's no real complaints, and the coalescing around the Chrome layout engine means far less compatibility issues in general.
reply
GaryBluto
40 minutes ago
[-]
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).
reply
foldr
22 minutes ago
[-]
There must be some confusion here. HTML 5 simplified doctypes, codified rules for interpreting malformed HTML, and added some new tags. Unless you’re using some crazy deprecated tags, you should just be able to write HTML4 and update the doctype.
reply
GaryBluto
11 minutes ago
[-]
By HTML4 I mean non-use of HTML5/CSS3 features. I'd also add that, while still supported by browsers, HTML5 deprecated lots of elements and parameters that I find handy.
reply
Minor49er
50 minutes ago
[-]
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
reply
zem
1 hour ago
[-]
the happiest software developers are those who write apps that run in a single command line process on a local linux machine (:
reply
bragr
1 hour ago
[-]
Have you ever actually met backend Linux engineers? They are, typically anyways, a very salty and unhappy bunch. I definitely include myself in that lot as something I'm working on.
reply
zem
1 hour ago
[-]
yeah, I work on commandline based compilers and code analysis tools and I'm very happy doing it! apart from the work itself being interesting, I find it really nice to just have to care about stdin, stdout, and filesystem access. I enjoy working on desktop gui apps too, but at least to my mind IPC and networking add a layer of unpleasantly error-prone concerns to deal with, and web apps dial that up to eleven.
reply
afavour
1 hour ago
[-]
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.
reply
graemep
1 hour ago
[-]
I would say that is all the more reason for writing HTML and CSS with a sprinkling of JS - you need less JS for the same result, you need CSS frameworks less.

I am not so sure about PHP, but I think the intent is more "do it in the backend where possible" which i agree with.

reply
ayaros
1 hour ago
[-]
Because you can actually parameterize things. It's wonderful!
reply
nashashmi
58 minutes ago
[-]
Looking at example 5:

  :root { --color: blue; }
  div { --color: green; }
  #alert { --color: red; }
  * { color: var(--color); }

  <p>I inherited blue from the root element!</p>
  <div>I got green set directly on me!</div>
  <div id='alert'>
    While I got red set directly on me!
    <p>I’m red too, because of inheritance!</p>
  </div>
Excuse my negativity, but this is messed up. I am trying to rationalize whyyyy???.

It seems every object is given variables (--abc). And then there are global variables and local variables. I guess this is the "cascading" feature. var is a function computed at the time of instantiation. And refers to local variables first. Then looks at global variable. Inheritance comes from ?? The p tag seems it is not root so therefore it is not blue.

Having explained it, I think about it better, but this really messes up how I thought of CSS. CSS is where the second stanza overwrites the first stanza. Yet global and local variables really hurts my head. A few complex CSS files later, it is bound to be unusable to determine result without getting a computer program to help.

reply
zdragnar
19 minutes ago
[-]
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.
reply
wrs
38 minutes ago
[-]
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.)

reply
zdragnar
16 minutes ago
[-]
In OP's example, the <p> would be colored blue, because the * selector directly targets it, taking priority over the inherited value from the #alert parent element if the CSS had been normal assignment:

    #alert { color: red }
    * { color: blue }
Variables behave slightly differently, in that they don't follow specificity rules. The definition of the variable / property behaves like a scope, and affects everything within it, hence the <p> being colored red instead of blue.
reply
LudwigNagasena
22 minutes ago
[-]
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.
reply
dimitropoulos
15 minutes ago
[-]
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
reply
ayaros
1 hour ago
[-]
I've just been calling them that anyway since I found out they existed.

Also, this guy is calling HTML a programming language. Make of that what you will...

reply
dentemple
1 hour ago
[-]
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.

reply
wk_end
1 hour ago
[-]
It's not that it's not a language, it's that it's not a programming language. You don't write programs in it.
reply
lcnPylGDnU4H9OF
10 minutes ago
[-]
This topic always tickles the pedantic part of my brain. If I may assume that the reader would agree that JS is a programming language, what makes it a programming language and not HTML? What makes a static .js file a program and a static .html file not a program?
reply
ayaros
1 hour ago
[-]
That's where I'm coming from.
reply
nashashmi
40 minutes ago
[-]
It is just a syntax language, used in programming web pages. that would be a better descriptor
reply
ajkjk
58 minutes ago
[-]
It is one...
reply
marcosdumay
32 minutes ago
[-]
The idea of naming the stuff you use with a "var" keyword as "properties" is really bad.
reply
cantSpellSober
40 minutes ago
[-]
and the name of the function we use to access them is var()! Not customProperty().
reply
afavour
1 hour ago
[-]
CSS variables = custom properties

Web components = custom elements

:shrug:

reply
graypegg
1 hour ago
[-]
"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!!
reply
brazukadev
1 hour ago
[-]
The same for Web Components (in place of Custom Elements).
reply
lcnPylGDnU4H9OF
7 minutes ago
[-]
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...).
reply