[lycos]

This looks terrible. Is this really necessary?

I feel like purists who write CSS by hand don't want this kind of stuff, because otherwise they'd have switched to one of thousands of preprocessors. And people who use preprocessors and/or elaborate styling systems that take care of this stuff already.

Maybe I am getting too old and out of touch though.

[JoshTriplett]

Among many other reasons people have given (including eliminating the need for preprocessors): building this into the browser also allows for optimization, compared to expanding into a huge amount of CSS. If people can send one mixin and twenty invocations of it, rather than 20x the amount of CSS, then that doesn't just save bytes, it potentially allows the browser to directly generate its internal data structures and whatever caches/etc it needs, rather than parsing more textual CSS.

[wrs]

This will eliminate the need for CSS preprocessors about as much as each annual edition of JavaScript eliminates the need for JS preprocessors.

[SahAssar]

There is only one major JS feature that is missing from modern browsers IMO: type annotations (like https://github.com/tc39/proposal-type-annotations/ or similar) since most people don't want to use JSDoc-based ones. Some people will want JSX too.

After those the major use-case for JS preprocessors will for most use-cases only be bundling and minification.

[wrs]

Good to know we have completely run out of ideas and TC39 can disband as soon as they get through with that proposal! /s

[SahAssar]

New features will come, but my point is that the major non-standard features most people use that is not implemented in most browsers are better support for types and JSX.

Just look at the history of 6to5, babel, pony/polyfills, different build systems, different module systems, multiple different syntaxes like coffeescript, multiple different type systems. IMO we are much closer to the browser now and hopefully close to getting "normal developers" to write code that runs verbatim in a "normal browser". The outliers will always be there (Svelte, elm, etc.) but for mainstream code I hope to get back to shipping the code you wrote.

I hope that we get more features from TC39 after that. I think generators and asyncIterators are underused currently. Things like pattern matching sounds interesting to get into the JS ecosystem.

[jszymborski]

I no longer need a framework or build systems for my websites because all the features I used in jQuery are part of Javascript today.

I wouldn't need Sass if mixins were implemented in CSS.

It might not eliminate it for everyone, but it will for those who care.

[mattrick]

If this feature were added, I’d see very little need to use CSS preprocessors - at least for me. We already have variables, nesting, and color functions. Throw in mixins and user defined functions and that pretty much covers 90% of what I’d usually do in Sass.

Maybe you still use PostCSS for some auto prefixing/ backwards compat stuff but the need for that should go away as the usage numbers for unsupported browsers go down.

[tacone]

The preprocessors are here to stay though. They have been instrumental to build consensus about which new features are the right ones to incorporate. For what it concerns the JS/CSS/HTML the (good) outcomes are hard to deny.

[mminer237]

I feel like eliminating the compilation step adds more client-side processing. Instead of knowing this element gets this rule with this color, it has to do so many function calls just to find out what elements a rule styles, then it has to do all the math to compute all the colors needed just to get to where they're starting right now. Instead of the publisher doing the compilation once as part of its build step, this offloads that compilation to every single visitor.

[art0rz]

The benefit of this is that it runs in the browser. E.g. you can change a CSS variable and the change would propagate to wherever it's being used.

[nine_k]

Also, the downside of it is that it runs in the browser.

The more universally executable code you have to run in a low-trust environment which is a WWW document, the more interesting vulnerabilities can creep in.

It's too late though: https://portswigger.net/research/ublock-i-exfiltrate-exploit...

[lycos]

Yeah but only in evergreen browsers once they implement it.. plus now you are making the browser do more work compared to just having simple CSS files that don't have to do complicated things.

[micromacrofoot]

"CSS doesn't have to do complicated things" is already a thing of the past. There are plenty of pseudo selectors and custom properties now that can be quite complex.

[JoshTriplett]

> Yeah but only in evergreen browsers

Which browsers that matter aren't evergreen at this point?

EDIT: got an answer downthread, apparently at least some sites have to deal with old versions of the mobile Safari engine because of old iPhones/iPads that can't be updated and can't run other browser engines. Another good reason to wish that iPhones/iPads permitted other browsers.

[no_wizard]

The real question is: how many of your users allow the browser to auto update?

This is the most important question nowadays. there are still organizations where this is tightly controlled, they use LTS releases that don't always get the updates as fast or the same etc.

[SahAssar]

Even LTS releases get much more rapid updates than the upgrade cycle for browsers used to be. I remember stuff getting released in IE8/IE9 and thinking it'd be 10 years before I could properly use it on large customer projects (and I was right pretty much right).

[lycos]

There is no definitive way to answer your question. It depends entirely on your target audience and how much effort your company is willing to put towards support a, I will admit, likely minority. Some of us need to.

[JoshTriplett]

I'm genuinely curious to hear which non-evergreen browsers people are having to support. Niche mobile browsers from ancient Android phones? Some of the more obscure mobile browsers from https://caniuse.com/ciu/comparison , or even more obscure ones that aren't listed there?

To what extent are those platforms unable to support a better browser? For instance, Firefox works all the way back to Android 5.0.

[reaperducer]

I'm genuinely curious to hear which non-evergreen browsers people are having to support.

Browsers on devices (sometimes iPads, sometimes Android) that are inside touch-screen kiosks.

Some of the ones I work with are in places so remote, it would take me three or four days to reach them if a software update goes wrong. Then another three or four days to get back to the office.

[realusername]

> Which browsers that matter aren't evergreen at this point?

Safari on iOS, which is still tied to the OS version and not evergreen yet.

[robertoandred]

Except the OS updates automatically so it's effectively evergreen.

[realusername]

While iOS has a quicker update scheme as Android, it's nowhere near as fast as an evergreen browser.

If I look at https://iosref.com/ios-usage there's only half of the users on last year update and 15% of users lagging behind on a 2+ year old browser version.

So expect your average users to have a new Safari version ~1.5 year after it's been out. So the answer to that is no, it's not fast enough to be considered evergreen.

[kevingadd]

Parsing a ton of CSS expansions from a preprocessor is likely more expensive in both CPU and RAM than evaluating simple functions.

[no_wizard]

Speed can be optimized over time, particularly as they collect huge real world usage and can optimize for common patterns. That's one unspoken benefit of having features in the browser vs pushing them to build tools.

Its not always appropriate but I feel CSS benefits more often than not for this

[est]

Who else remembers the expression() from IE5.5 ?

[micromacrofoot]

I write a lot of CSS and I'd prefer not to use a preprocessor at all, SASS is great for what it is, but "one less dependency" sounds wonderful.

[dimal]

I've been hoping for something like this. One of the remaining problems with CSS is that the only native way to reuse any complex functionality is with a class. Classes are applied in the DOM. This is how we end up with utility classes, but utility classes don't mesh well with component based styling, where all your styles for a component live in a file alongside the JS.

So I use mixins for style reuse so that I can always look at the component CSS (and follow any explicit imports) to see what styles are applied. If you have some styles from utility classes and some from component-level styles, there's always increased cognitive load because when you're looking at the component CSS you often don't realize that the utility class is there.

I get the sense that this is one of the reasons why people like Tailwind. Then there's no confusion - everything is in utility classes, in one place. But I can't read that mess. I need line breaks and separation of concerns. That's just me.

This proposal kind of scratches my itch, but from what I can tell, these functions and mixins are still globally defined, so while they're better than utility classes, they still leave a bit to be desired for me. I'd like CSS to behave like any reasonable language and use explicit imports. But I'm sure that getting imports right and avoiding blocking is not an easy problem.

[troupo]

I use preprocessors, and I want this in regular CSS precisely because I don't want to run a preprocessor (as it is a yet another tool that I have to set up, configure, update, maintain etc.)

SASS is 16 years now. Less is 15. PostCSS is 10. That it took CSS WG this long to adopt useful features from those tools reflects quite poorly on the browsers.

[wccrawford]

When I think of those pre-processors as if they're jQuery, I can see the value of just having this in the browser instead.

I wish it was also stacked like SCSS. Maybe some day.

[lycos]

You mean nesting like this proposal? https://www.w3.org/TR/css-nesting-1/

[wccrawford]

Yeah, that's the word I was looking for. :)

[uallo]

CSS nesting is available in all the important browsers today.

https://caniuse.com/css-nesting

[wccrawford]

Wow. I've been living under a rock. Thanks!

[lelanthran]

> Is this really necessary?

Yes, because the fewer things you depend on outside of the standard, the better.

I like standards, but my recent foray into FE development showed me that FE is an unmitigated disaster. Standardising helps that.

[assimpleaspossi]

Agreed. This is what javascript is for.