DEV Community

Future of CSS: Functions and Mixins

Andrew Bone on February 15, 2024

Today we're going to look at something that hasn't yet been incorporated into the official CSS specification but could change the way we write CSS....

Read full post

Bernd Wechner • Feb 16 '24

Can't wait to see the end of preprocessors.

Andrew Bone • Feb 16 '24

As CSS gets more and more features pre-processors seem less and less necessary, I imagine they'll hang around for a few years yet, even if they're no longer required.

Andrew Bone • Feb 16 '24

@afif I can already picture the day you start sharing your code, like you amazing triangles in this format 😅

@function --gradient(--radius: 0px) {
  --gradient-part: calc(tan(60deg)*var(--radius)) top var(--radius), #000 98%, #0000 101%;

  @return 
    conic-gradient(from 150deg at 50% calc(3*var(--radius)/2 - 100%), #000 60deg, #0000 0) 0 0/100% calc(100% - 3*var(--radius)/2) no-repeat,
    radial-gradient(var(--radius) at 50% calc(100% - 2*var(--radius)), #000 98%, #0000 101%),
    radial-gradient(var(--radius) at left var(--gradient-part)),
    radial-gradient(var(--radius) at right var(--gradient-part));
}

@mixin --triangle(--radius: 0px, --width: 100px) {
  width: var(--width);
  aspect-ratio: 1/cos(30deg);
  -webkit-mask: --gradient(var(--radius));
  clip-path: polygon(50% 100%, 100% 0, 0 0);
  background: linear-gradient(45deg, #FA6900, #C02942);
}

.triangle {
  @apply --triangle(20px, 180px)
}

Stop using obsolete methods to create CSS Triangles! ⚠️

Temani Afif ・ Feb 13

#css #webdev #beginners #html

Temani Afif • Feb 16 '24

Not only for a specific shape but it would be a function that can return most of the shapes.

Something like @mixin --triangle(--type: 1,--radius: 0px, --size: 100px) where type will define the nature of the triangle 😉

Andrew Bone • Feb 16 '24

Honestly I'm excited to see how far you can take it 😲

cScarlson • Feb 16 '24

You know that trick where you overlay a checkbox or radio button over a button's display so that the user interacts with the input instead of the button?... And how I have to recreate them all the time or use a JS component just to have one that's reusable?... Yeah, can't wait for mixins... This is going to be awesome!!!

chovy • Feb 17 '24

we'll be using this asap at Profullstack and Primatejs

Andrew Bone • Feb 17 '24

Awesome! Now that all the browsers are evergreen adopting new features like this is so convenient.

Andrew Bone • Feb 15 '24

Can you think of any more powerful examples of how to use CSS functions?

Eckehard • Feb 16 '24 • Edited

Rerferring to this source, W3Schools listed 228 CSS properties in 2020, some people counted 584, but the trend seems to be further upwards.

Adding functions and mixins will make CSS more flexible, but seems to establish a second programming language in the browser. And you probably will still need some javascript too, as not all transitions refer to styling. Think of a content, that needs to change in sync with the styles.

I´m not sure we should be too happy about this trend. Javascript has already more than enough (some people say: too many) features. Often you have far more than one way to do the same thing, which can be pretty confusing. Now we get more options to do the same things in CSS, that could been done in JS before. This blows up the whole balloon again...

When will it burst?

Andrew Bone • Feb 16 '24

A valid concern, where CSS has JS beat is with optimisations. Browser makers can take the strain of doing calculations off the developers hands and allow the calculations to be done off main thread.

This can, of course, be abused and used wrong but less JS is always a good thing in my mind.

Eckehard • Feb 16 '24

So we add functions and mixins to CSS to avoid Javascript? This is a strange logic. Balancing a tower of different and mostly incompatible tools certainly doesn't make things any easier.

Temani Afif • Feb 16 '24

Why don't you see the problem differently like JavaScript developers using JS to emulate native CSS feature? This is not something new, it's like that since years. I cannot count the number of JS library used to animate stuff where a simple CSS keyframe will do the job.

We don't want to avoid JS but we want JS developer to not avoid CSS and consider all the native feature that are already implemented instead of reinventing the wheel with a complex JS code.

As side note, you don't need to know all the 584 CSS properties. No one need to know them. The fact that CSS is adding new features doesn't oblige you to use them.

Eckehard • Feb 16 '24 • Edited

Inventing a new language for every sentence you want to speak is not a good Idea...

We see an inflation of new tools, each providing a "new syntax" as if there had been no other programming language before (See my post about the different ways to write loops). And often, this "new" approaches are created with a limited target in mind and a fairly limited syntax, so they limit what you can do.

Languages like C++, Pascal or Javascript are "general purpose" languages, they give you a small set of rules with which you can formulate all kinds of tasks. And they have a consistent syntax which is kind of battle tested.

We have seen this so many times, an all the time it is claimed to make things "easier" for developers. Angular uses JSX, which is more or less simply HTML syntax, so, there is no option to write loops. So, Angular introduced a new command: ng-for

<ul>
    <li *ngFor="let item of stuff">
      {{item.title}}
    </li>
</ul>

The syntax is driven by what HTML provides, but it is far from "consistent". It is more a "dirty hack". This is not HTML, it is not Javascript, it is not a programming language at all. It is not even a template literal, which would be the common form to include variables into JSX. It is absolutely no wonder that you find thousands of pages just explaining how to use ng-for. I don´t think this is "easy" in any way.

And what does ng-for provide? You just can loop through simple flat arrays, nothing else. What if you want to display every second element, reverse the order, your array is nested or whatever may happen to you? Come on, let introduce some new properties to handle all this special cases?

It is true: Nobody needs 584 CSS properties. But If I have a special task, I need to find the right property. Nobody can remember 584 CSS properties, so it will take some time to find the right one. What if there are 5.840 CSS properties or 58.400?

There is an infinite number of things people may want to do on a website. If we create a new property for every possible situation, we will need an infinite number of properties. I would prefer a "general purpose" language to do this job. And as browsers already understand Javascript, why use something else?

András Tóth • Feb 17 '24

I partially agree with you. On ngFor and Angular absolutely. React version of JSX made a lot of sense instead, it is just better design. Same thing is true with yaml and helm: horrible new, mini languages, instead of supporting a couple of solid languages and passing your own JS object for example. You know what nobody considers mini programming languages? God damned command line interfaces, where there's an absolute chaos on if you just write -auth or -a or simply auth? Is -f file or is it force?

So I get why exactly you are angry about it and why you are defensive.

However, however! Mixins are amazing for composing reusable blocks of CSS. You can reduce the bundle one needs to download and also you can make things DRY by defining it once.

I personally use mixins to describe the things that are not obvious in CSS.

But where I disagree:

unlike my example with yaml kubernetes and infrastructure, in the browser it does matter when and how things are optimized. It means you won't be able ever to beat pure CSS and pure GPU acceleration. You just can't do it in JS.
therefore it makes sense for CSS to be able to do very limited things like variables, very simple input-output functions, very simple calculations
CSS is optimized also for bundle size as it is an exception-based language: meaning you have the most out of it if you create a terse set of core defaults and override those defaults when they are needed
there are excellent new courses in CSS that makes you familiar with the small subset of the right tools: I have read through this and got mostly enlightened: every-layout.dev/rudiments/boxes/ You also need to do an advanced CSS course somewhere and you will be top-notch (it is true that there are too many bad advice, bad documentation is out there)

Where it sucks though: when you have variable and values YOU MUST PROVIDE ERROR MESSAGES the very least. With CSS variables I struggled with this. It must be solved.

Finally, I think the whole things is a false-dichotomy and we don't look at the real problem:
We clearly have a need for a unified, well-designed and performant language for the browser, essentially turning it into a sandboxed virtual machine. We can't have it because of Browser Wars.

Tab Atkins Jr. • Mar 26 '25

I was surprised to click into this topic and see it was talking about Sass functions/mixins, and not the native CSS ones in drafts.csswg.org/css-mixins/. (Currently only Functions, we're still thinking about mixins.) Chrome's implementation is nearly ready!

Tab Atkins Jr. • Mar 26 '25

Oh lolllll I misread the dates, this post was last year, so the lack of CSS Custom Functions is completely understandable since the spec didn't exist back then. ^_^

Andrew Bone • Mar 27 '25

This post was originally a look at what they were and a nod to the fact there were some early discussions about adding them to the spec. I'm planning on doing a revisited post when the spec is finialised and both functions and mixins are shipped in at least one browser.

I noticed Adam Argyle did a post yesterday talking about mixins being added to canary behind a flag so we're almost there!

Some comments have been hidden by the post's author - find out more