Why Hello CSS doesn’t use CSS variables
Written on 12 Feb 2019
When I announced my Hello, CSS! project last week most of the responses were pretty positive. Hurray!
One person did criticize it:
This is pretty bad. Why make up your own variables that require search and replace when you could use native CSS custom properties (vars)? Much of this makes no sense.
Ignoring the choice of language, “why don’t you use CSS variables?” is a good question, and something I spent some time thinking about during development.
Some sort of support to track related values is useful. For example for the page padding:
.page {
padding: 1rem 4rem;
}
figure.full {
margin-left: -4rem;
width: calc(100% + 8rem);
}
Change the 4rem
in .page
and you’ll need to change the figure.full
too,
and some other places as well.
I see four options:
- Do nothing, and hope that people will notice stuff breaks.
- Use a CSS preprocessor, such as SASS, less, etc.
- Use native CSS variables.
- Mark related values with a comment.
Do nothing
“Do nothing” was my first approach; the initial versions had only two related values, and I could mostly get away with it by just putting them next to each other.
As I added some more fixes and features the total number of related values grew to 15, a number which is probably a bit too high for “do nothing” to be feasible (it’s not easy to grep these values, as 4rem may or may not be related to the 4rem of the page, and the 8rem is 2×padding).
CSS preprocessor
Using a CSS preprocessor can be a good option for many projects, but I’m not so sure if it is for Hello CSS.
-
There is no standard CSS preprocessor that’s installed as part of the standard IDE environment (like C’s
cpp
), so users will have to install something on their own. To make this easy for all users across all platforms regardless of skill level is not easy.There’s also no programming environment that is installed by default on all three major platforms. Sure, people can install Python or Ruby or whatnot on Windows, but that’s a lot of effort to just run a simple script maybe once or twice, especially if you’re just looking to make a basic website.
In mu experience it’s hard getting non-programmers – and even programmers who are not familiar with these tools – to install stuff using npm, gem, pip, and such. Joe Armstrong of Erlang fame described his experience installing a “simple” JS program. He gave up. I’d like Hello CSS to be as usable as possible even for casual hobbyists.
There are some GUI frontends (like Koala), but having people download 82MB and familiarize themselves with a UI just to run a search and replace doesn’t strike me as an especially great trade-off.
I’m not even sure what the state of macOS systems is in this regard, as I am not hip enough to own an Apple system.
-
CSS preprocessors will add a lot of syntax and complexity that’s not needed. It will make using, debugging, and understanding everything harder, especially for beginners or people who are not heavily invested in the CSS ecosystem such as a C programmer, a scientist with basic programming skills, or just the casual hobbyists who wants to make a website about their stamp collection. Not everyone is a frontend dev (or indeed, a dev at all).
For example using
calc()
in less is tricky.
The concepts “simple” and “complex” are relative: spending an hour to save a week’s work will probably make things simpler, but spending the same hour to save 15 minutes of work will probably make things more complex.
I’m not against these tools. I’ve used them extensively in the past and will use them again in the future. It’s just not the right tool for the job here. Hello CSS currently sits at 491 lines (294 without comments), has 5 variables, and 15 references to them. It’s a small project.
CSS variables
CSS variables are tempting, except for one problem: your site won’t work for about 13% of your visitors.
Some might simple hand-wave them away as “old browsers” and that “IE sucks” and whatnot. All true. Also all irrelevant. Excluding 13% of visitors is still excluding 13% of visitors, no matter what the underlying reason is, or how stupid you think it is. (General note to the programming community: learn to be professional. Professionals deal with the world as it is to the best of their ability, and don’t refuse to deal with it because they don’t like it.)
For some projects this may be acceptable. This website is mostly visited by programmers since I write mostly about programming. I don’t keep analytics, but I’ll bet that CSS variables are supported by almost all visitors.
But this site is just one application of Hello CSS. I did my best to make it as broadly applicable and accessible by as many people as possible, so it can work well for your stamp collection website too. Completely breaking it for 13% of visitors is not acceptable.[1]
I believe there are some preprocessors to solve this, but this gives us the problems in the previous section.
Comments
This leaves us with the last option: mark related values with a comment, which is what I ended up doing. The above snippet becomes:
.page {
padding: /*pady*/1rem /*padx*/4rem;
}
figure.full {
margin-left: /*padx*/-4rem;
width: calc(100% + /*padx*/8rem);
}
I am not wildly enthusiastic about this solution, but after carefully considering the different solutions this seems to be the best – or rather, least bad – choice for Hello CSS at this time.
This might change in the future: when CSS variables gain broader adoption, or if I find a CSS processor that avoids the problems I outlined.
-
I did use
calc()
in a few places, which is unsupported by 11%. But whencalc()
is unsupported some tables will be slightly less wide than intended. Not great, but the overal design is still in good working condition. Browsers that don’t support CSS variables will have the entire page render completely wrong. ↩