
“Variables” in CSS are harmful (2008) - soegaard
https://www.w3.org/People/Bos/CSS-variables
======
Rotten194
The arguments here don't really make sense.

The author says that a constant lookup table is extra implementation
complexity while also saying it's simple and something every programmer should
have done as an educational exercise. Considering the density of browser
specifications, talking about symbolic constants as feature bloat is some
serious windmill-tilting.

They then say that named constants make code harder to understand -- which is
obviously an opinion, but one that goes against almost all standard practice.
The benefits of naming constants and avoiding magic numbers are well
documented, I think. Yes people can go overboard with this, but the solution
isn't to not have named constants as an option at all.

The kicker I think is the sheer popularity of CSS preprocessors. When people
are compiling to something you designed as an end-user interface, you've
failed.

The problem with CSS variables isn't the concept, its that --this-syntax is
ugly and unreadable af (admittedly bikeshedding here).

~~~
bvrmn
> When people are compiling to something you designed as an end-user
> interface, you've failed.

CSS is a good end-user interface for many things without variables.

And people will use preprocessors for CSS no matter how many features it will
have because of many reasons including "ugly and unreadable" syntax.

It's better to leave CSS and HTML as simple primitive bytecode for web UI with
powerful compilers instead of developing epic w3 specs leading to numerous
bugs in browser implementations.

~~~
sethrin
> It's better to leave CSS and HTML as simple primitive bytecode for web UI
> with powerful compilers instead of developing epic w3 specs leading to
> numerous bugs in browser implementations.

Haven't we pretty much already crossed that bridge? I recall quite a few bugs
in CSS specs.

~~~
bvrmn
> Haven't we pretty much already crossed that bridge?

It's because CSS syntax has no changes for almost 20 years and even IE managed
to clean up mess. New syntax -> new bugs in browsers.

------
dkonofalski
I get that this article is 10 years old now but I like the principle of it, to
a certain extent. My biggest gripe with some of the newer usage of CSS
(including BEM and SMACSS) is that it loses the separation of concerns that is
supposed to make HTML/CSS modular. The intent of the web was for content and
we're getting farther and farther away from that to the point where now even
CSS can cause bit-rot. People are using CSS for everything as tightly-packaged
modules that look great when the CSS is loaded correctly but that don't really
function without the CSS/HTML as explicitly paired. I know that's what some
people want now but I can't help but feel like this is contributing to the
mess.

That being said, variables are useful. I have no problem using variables in a
CSS preprocessor and don't really care one way or the other whether it's
included in the CSS spec.

~~~
GuiA
The HTML/CSS/JS split is great ideologically, but have you looked at the
source code of any web app lately? It’s a jumble of all 3, with modern
frameworks like react encouraging you to work with the whole, injecting things
as needed here and there.

I remember learning CSS in the early 2000s, with the book showing how one
could have separate stylesheets for on screen display vs printing. You’d think
this approach would have aged nicely, now that websites need to render on a
large variety of screen densities/sizes/aspect ratios/etc. Well no, now we
have huge bloated CSS files full of media queries and weird things that are
impossible to make sense of unless you’ve spent a few weeks in the codebase.

So yes, nice in theory but completely outdated in practice given the horrible
Beast DOM has become.

Perhaps that approach was too idealistic all along, and only sort of worked in
the beginning, when the web was really basic and most people were on a
1024x768 display. The form is the function and also the medium and the
message, and it’s impossible to place abstract boundaries on where the content
vs presentation vs interaction lie.

~~~
meesterdude
I work with rails basically every day, and your experience does not match
mine. In the codebases I've worked with, almost all of them are cleanly and
clearly separated. HTML is in one directory, css and js in another. It's true
react has a... different approach, but it's certainly not the only way to do
it.

~~~
ralfn
"separations of concerns" is not about putting things in different folders or
files.

It is about those things not being entangled as spaghetti with each other.

Reacts Philosophy is that everybody's css/js/html is tightly coupled and
therefor using different languages with different semantics and scoping rules
increase the cognitive complexity without providing any advantage.

Can I break your app by just touching the CSS? Does any cosmetic change at any
point require that I touch the html? Can I write a new style sheet for your
app without knowing the JS or HTML? Can I plug in a new style sheet of one
application into another? Can people work on the JS/HTML/CSS separately and
independently?

Putting your spaghetti in separate folders doesn't make it less spaghetti.

And the market knows it's tightly coupled spaghetti for everyone. Thats why
you don't see different job adverts for your three different folders.

The goal was to have a world where the designer would know CSS but zero
JavaScript and zero HTML. This goal has completely failed.

~~~
dkonofalski
I think web apps are a little unique because there's huge parts of them that
are not content and that's where the separation of concerns originally came to
be. I vehemently disagree with you that all of these things _have_ to be
entangled and tightly coupled. I think they just end up that way because it's
the easy way to get through a problem and people who do things like that are,
generally, lazy or on a tight deadline (for no reason that to have a deadline)
or stressed or any number of things. Unfortunately, if all you're given is
noodles, sauce, and meatballs, you're probably going to make spaghetti.

------
thedz
This is an article from _2008_.

I'd take most arguments in this with a grain of salt, as it predates much of
the progress that CSS (and things like Sass/Less/PostCSS) have made over the
past decade.

------
dang
The article fared little better at the time:
[https://news.ycombinator.com/item?id=267223](https://news.ycombinator.com/item?id=267223).

------
dsego
> On the other hand, CSS style sheets are short. They are not much bigger than
> one editor window. Very few people (only professional designers, it seems)
> write style sheets longer than a hundred lines.

Even for 2008 this is just wrong. Very few people write any kind of CSS at
all. But those who do surely write more.

~~~
dbbk
I'm quite baffled by this... I'm presuming this was in the context of the time
when tables were used for layout everywhere

~~~
bryanrasmussen
in my experience tables were hardly used anywhere for layout in 2008.

~~~
zimpenfish
A single example, sure, but quite a high profile site: news.bbc.co.uk was
using tables for layout in 2008 -

[https://web.archive.org/web/20080306220511/http://news.bbc.c...](https://web.archive.org/web/20080306220511/http://news.bbc.co.uk/)

~~~
bryanrasmussen
Ok maybe I was just lucky in where I worked.

------
dsego
In 2018 we write our CSS in JS. We also write HTML in JS. Then we wrap it in a
browser and download as a standalone app.

------
aalleavitch
I love that this highly opinionated article about the correct way to write css
is styled just hideously.

------
phyller
CSS is getting variables: [https://developer.mozilla.org/en-
US/docs/Web/CSS/Using_CSS_v...](https://developer.mozilla.org/en-
US/docs/Web/CSS/Using_CSS_variables) and I cannot wait to use them. This is
the main reason I will be pushing to stop supporting all versions of IE. If
you don't like them, you don't have to use them. But I'll give an example of
why they are super super handy and long overdue.

Let's say I want to enforce a color palette across my app. I define color
variables, and only use those predefined color variables. If the palette
changes, I just change the variable, and everything changes. Great, an easy
way to have simple and consistent colors on a large project with multiple
devs. Even better, I can do this now, with prepocessors like SCSS. After years
of using it in an increasingly large project I have zero regrets, I only wish
we did it sooner.

But think of this further use case: we want to have different color palettes
based on different situations. For the same markup. We want the user to be
able to toggle between dark mode and light mode. We want to change the colors
when the user is printing something (especially in dark mode). I can't do this
in SCSS directly without native CSS variables. I have to compile multiple CSS
files from our source ahead of time, and dynamically switch between them,
which feels like a hack and causes a lag while the files are fetched.

With CSS variables, I can change the variable to another value inside a
certain class. So to toggle between light or dark mode I can just add a class
to the body element on the page. I can use the print @media rule to change the
variable values when printing. I can do the same with sizes based on the
screen dimensions.

This is so simple and clear. When devs are maintaining or adding code they
don't need to think about it. Just use the right variable and everything will
work out. The alternative to using variables (the new CSS ones or by
generating multiple stylesheets using CSS preprocessor variables) is to
redefine _all_ the styling that you need to change under a new class. So I
have a stylesheet for a feature, then a smaller one that changes all the
colors for that feature when the "dark-mode" class is on the body tag, and
another for @media print. And then every dev needs to be aware of that and
maintain and check all 3 versions whenever they make a change.

Needless to say, I entirely disagree with this article :) I don't think I am
the only one who has struggled to understand why CSS is so difficult to use.
We've had a few decades to refine it, we should be in a better place by now.

~~~
dbbk
You can use them now with PostCSS if you don't mind restricting your variables
to the root level (it can't polyfill the cascading nature).

You could also use them natively if you don't care about IE, which is becoming
more and more reasonable.

------
kenning
CSS variables are useful if you're a professional web developer. But I would
say websites are excessively designed now, especially the kind of ones I visit
(other than this).

It's pretty incredible just what an arms race web design is. Web browsers
should really not be chugging, ever, in 2018.

------
Shorel
This is just an example of NIH syndrome.

And not having variables in CSS is more harmful than having them. In the form
of a dozen preprocessors and alternative CSS languages that compile to CSS.

~~~
trevorstarick
Except CSS variables have existed nativity for a while now:
[https://developer.mozilla.org/en-
US/docs/Web/CSS/Using_CSS_v...](https://developer.mozilla.org/en-
US/docs/Web/CSS/Using_CSS_variables)

------
Nickersf
I like reading opinions and ideas on programming from the past and contrasting
them to the current state of things. I wonder how the author sees things 10
years later.

------
zeveb
I think he's wrong here: requiring that folks preprocess some CSS-variant-
with-constants into CSS-without-constants just multiplies the number of
entities (by however many CSS variants are then introduced). CSS's lack of
constants is a _glaring_ design error.

If we want to reduce the total number of entities, then we should examine
unifying HTML, CSS & scripting. As I've indicated elsewhere, I think that
something like this would be awesome:

    
    
        ;; adapted from https://www.w3schools.com/howto/howto_css_modals.asp
        
        (html
         (head
          (title "modal-box-example")
          (style
            ;; The Modal (background)
           (.modal
            ;; Hidden by default
            (display none)
            ;; Stay in place
            (position fixed)
            ;; Sit on top
            (z-index 1)
            (left 0)
            (top 0)
            ;; Full width
            (width "100%")
            ;; Full height
            (height "100%")
            ;; Enable scroll if needed
            (overflow: auto)
            ;; Fallback color
            (background-color (rgb 0 0 0))
            ;; Black w/ opacity
            (background-color (rgba 0 0 0 0.4)))
        
           ;; Modal Content/Box
           (.modal-content
            (background-color #x"fefefe")
            ;; 15% from the top and centered
            (margin "15%" auto)
            (padding 20px)
            (border 1px solid #x"888")
            ;; Could be more or less, depending on screen size
            (width "80%"))
        
           ;; The Close Button
           (.close
            (color #aaa)
            (float right)
            (font-size 28px)
            (font-weight bold))
        
           ((.close:hover .close:focus)
            (color black)
            (text-decoration none)
            (cursor pointer)))
        
          (script
           (with-elements-by-id
            ((modal "myModal") (btn "myBtn")) document
            (let ((span (aref (get-elements-by-class-name document "close") 0)))
              (setf (on-click btn) (lambda () (setf (display (style modal)) "block"))
                    (on-click span) (lambda () (setf (display (style modal)) "none"))
                    (on-click window) (lambda (event)
                                        (declare (ignorable event))
                                        (setf (display (style modal)) "none")))))))
         (body
           ;; Trigger/Open The Modal
          ((button id "myBtn") "Open Modal")
        
          ;; The Modal
          ((div id "myModal" class "modal")
        
           ;; Modal content
           ((div class "modal-content")
            ((span class "close") ×)
            (p "Some text in the Modal..")))))

~~~
dkonofalski
I especially dislike this type of pairing because it makes it an explicit
requirement for the content and presentation to be together. I prefer content
to be separate from styling, as intended by CSS, simply because we can't
predict what the future will bring. Content will always remain content when
it's semantic but presentation can and will change as time goes on.

~~~
_yawn
Content and presentation both change, and together. That's how it's always
been for every type of media. How much space you have on the newspaper
determines what your article's title is, but what the title is also determines
how much space you have.

~~~
dkonofalski
No they don't. I can write a paper or a thesis without any worry about how
it's going to look visually to the person consuming it. I can post a video of
something without any kind of concern for what size, container, or surrounding
content might accompany it.

Content is content. Presentation is how that content is displayed. While they
can work together, the content is the most important thing and presentation
should always be secondary to it.

------
disconnected
Worth noting that this document is ~10 years old.

~~~
raldi
Mods, please add "(2008)" to the title.

~~~
dang
At your service.

------
dmitri1981
It’s hard to take an article with this kind of background seriously

~~~
Manfred
Thankfully it's also a great example of how to write good markup so the page
is perfectly usable and readable with styles turned off.

~~~
galonk
I would say __only__ usable and readable with styles turned off.

------
pleasecalllater
Yea... and the background is so professionally readable. I suppose the
arguments are as well, but I cannot read it. My eyes are bleeding.

------
cantrip
Really missed an opportunity for the "considered harmful" trope.

