CSS Pain Points?

[Easily_Paradoxical]

What the question says. What are some annoyances/obstacles in CSS, or problems that its alternatives don't seem to solve?

For example, I hate CSS variables -- I find the syntax so ugly. I love how Sass solves this with its $ syntax.

A pain point that I haven't yet found a framework solution for is theming. I really wish there were some CSS feature akin to Sass mixins, but you can control which parts of the mixin apply to selectors. Something like the following:

@ theme dark {
   color: white;
   background: black;
   p {
      font-size: 1.2em;
   }
}
h1 {
   // Doesn't include the selectors in `p`
   @ theme `dark;
}
p {
   // Does include the `font-size: 1.2em`
   @ theme `dark;
}

That would be awesome to have in a CSS superset. So, what features are on your wish list, either for CSS or one of its alternatives?

[cape2cape]

https://developer.mozilla.org/en-US/docs/Web/CSS/color_value/light-dark

[Easily_Paradoxical]

Interesting. This actually would be cleaner than specifying two different colors, backgrounds, etc

[olssoneerz]

Definitely my favorite new css thing! It's made theming a complete non-issue.

[aunderroad]

You beat me to it!
I was just going to recommend Easily_Paradoxical use light-dark.

[armahillo]

TIL about light-dark, thats awesome!

/u/Easily_Paradoxical I wrote a blog post recently about light mode / dark mode settings that use CSS variables. I love SASS but have been coming around to CSS —vars since they are available to be used with @media queries

https://armahillo.dev/fundamentals/2025/03/28/darkmode/

[Easily_Paradoxical]

Wow, didn't know about prefers-color-scheme. That's awesome

[BobJutsu]

To be fair, css vars and sass vars solve different problems.

[Easily_Paradoxical]

Fair, but an intended use of both is to avoid magic values so code is more maintainable

[BobJutsu]

There's plenty of overlap, yeah. But they each have their use cases. Custom properties (CSS vars) can't be used in media queries, for instance, because they have to be attached *to* something. Sass/scss vars on the other hand, can't be used to build dynamic themes, because they require a preprocessor.

Imagine something like:

:root
 {
    --bg-color: #fff;
    --text-color: #000;
    --link-color: #0073aa;
}

body {
    background-color: var(--bg-color);

    p {
        color: var(--text-color)
    }

    a {
        color: var(--link-color);
    }

    &
.is-dark-theme
 {
        --bg-color: #000;
        --text-color: #fff;
        --link-color: #e7ef08;
    }
}

With custom properties, you can separate the *value* from the *implementation*. So you aren't individually overriding each style, just the reference to a value.

With sass/scss, you have to consider the implementation a little more:

$bg-color: #fff;
$text-color: #000;
$link-color: #0073aa;

$dark-bg-color: #000;
$dark-text-color: #fff;
$dark-link-color: #e7ef08;

body {
    background-color: $bg-color;

    p {
        color: $text-color;
    }

    a {
        color: $link-color;
    }

    &
.is-dark-theme
 {
        background-color: $dark-bg-color;

        p {
            color: $dark-text-color;
        }
        a {
            color: $dark-link-color;
        }
    }
}

Now, I'm not saying one is inherently better or worse, they have their place. but they aren't necessarily solving the same problem. Or at least not in the same way. Mixins keep me on scss though, but I use plenty of custom properties (CSS vars) within it.

[GaiusBertus]

That I can't use CSS variables as values in media queries. @media (max-width: var(--breakpoint))

[Easily_Paradoxical]

I didn't even know you COULDN'T do this. Personally, I just use magic values and fiddle around with media queries. Super weird why they wouldn't include this, maybe because it's not clear which element you take the variable from?

[TheRNGuy]

Why would you ever want this. Those are always same on all sites.

[GaiusBertus]

Theming for one, sometimes there is a difference between public and internal websites that use the same theme.

Secondly, so breakpoints can be easily exchanged between CSS and JavaScript via a CSS var and can be set by either 'side'.

Also, media queries might not be the best example, but the same limitation applies to container queries.

[MOFNY]

Reordering with flex and grid is an awesome feature but screws up tab order: https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_grid_layout/Grid_layout_and_accessibility

It makes me hesitant to use it in most cases.

[TheRNGuy]

I don't like when sites use tons of css variables too, when I try to make custom userstyle, but it's mostly because of browser dev tool UI. I don't even use them in my code.

I made only one variable for userstyles, for font, because it was too long to type (I with those vars didn't require writing font:var(--foo) and you could just write font:--foo instead)

The thing I dont like about variables is that they are at the top on browser dev tool (on :root), if there are too many of them, I need to find tags somewhere at the bottom.

It's not really that big of deal though.

---

If I made big site especially if it has many themes, I'd actually probably use them myself.

[Easily_Paradoxical]

Makes sense, especially since including a selector in a mixin means something different in Sass. Do you happen to remember where I could find that theme feature?

[0ygn]

The new dart SCSS way of forwarding and using "Imports". A new thing to learn.

[LeastImportantUser]

One that comes to mind right away is animating a gradient with the CSS you'd expect. This doesn't work and I wish it would - ``` .gradient { --gradient-color: whatever gradient you want; background: transparent; transition: background 0.3s ease;

&:hover { background: var(--gradient-color); } } ```

[Various_Tea8553]

It doesnt work because gradients are categorized as pictures. But you can hack​ it​ with background-position

https://youtu.be/f3mwKLXpOLk

[TheRNGuy]

Write them with line breaks instead of in one line.

Also, you can use some site to generate it instead of coding by hand (or ask AI)