Welp, time to make a @function preprocessor. There is no reason for every single client to recalculate things which could have been completely or partially calculated at build time.
I used to share this sentiment (and I’m a web performance consultant by profession so very few people care about performance as much as me!), but when you consider how much calculation we _happily_ let our JS do at runtime, I don’t think forcing CSS to be static/preprocessed is worth it. And that’s not even me taking a swipe at overly-JSsed front-end; I’m talking about any runtime work that JS picks up.
Is preprocessed CSS faster? Yes. Is it meaningfully faster? Probably not.
An optimisation I've always wondered about for transforming/translating/animating elements: is it faster to use JS translations or animation API directly on the element (e.g. style.transform / element.animate), or updating CSS variables with JS to let the CSS engine reposition inheriting elements?
In the context of animations, I'd intuit the latter but would be open to hearing why.
But there are also plenty of use cases where recalculation will be valuable in the client. CSS variables cascade so a preprocessor isn't going to be able to know ahead of time what any given variable value is.
Sure, the new syntax allows doing some nifty stuff with the cascade. In practice, however, I foresee most usage being simple one-time transformations of design tokens. I suppose it is more of a theme architecturing issue.
It's a tradeoff. I expect this to be non-trivial, do nothing in the general case (when referring to runtime CSS vars) and possibly increase your final CSS size for any sufficiently complex codebase when unrolled.
No. The implementation treats the function body as just another CSS rule set, which is applied to some virtual element. The ”result: somevalue;” rule then sets the ”result” style property on that element, and that property value gets plopped onto the call site.
They are not allowed to loop or recurse, so no, by themselves, they are not (unless you accept repeating the function a potentially infinite amount of time).
CSS in general is Turing complete if you allow running multiple frames, although it requires ugly hacks. See e.g. https://codepen.io/propjockey/pen/dywNyBQ, which is quite insane IMO.
CSS Custom Functions are defined in a way they don't add anything over traditional CSS in this regard. I.e. they are just allowed to act as custom functions - not recursion mechanism, jump mechanisms, loop mechanisms, etc.
This may feel true if you've re-engaged with CSS's progression in the last ~5–7 years. In reality, the last big qualitative leap was Grid in 2017.
This project is based on just one new proposed rule which won't be available in all mainstream browsers until 2027-28, and won't be safe for production use until close to the end of the decade.
I'm no expert in this domain, but I suspect it's less "this is a bad problem to solve" and more "every solution to a problem moves farther away from the ideal simplicity of a markup langage."
(I'm not weighing in on the validity of this position, just reporting what I perceive the position itself to be.)
People who don’t understand the problems CSS has to solve are opposed to CSS solving those problems. Sure it can all be stuffed into Tailwind classes!!
It's a post about web development on HN. Half the comments will rag incessantly, half will talk about how the web should go back to being a delivery mechanism for documents only like it's 1995 forever, someone will rant about Google for some reason. It's a neverending nightmare.
As someone who works with both those languages professionally, I’m not sure what you mean by that. CSS applies to a new narrow band of the spectrum of how the web functions.
It would be quite nice to see some more "killer" uses of this new feature that aren't just "we removed some duplication and... saved less than 1% of our loc".
And maybe there are some really compelling ones... I think the only really useful one I see here is `--abs`, which really should just be built-in.
Whoo. I’ll be the first hyper negative prototypical HN commenter.
I’m glad I don’t work on browser engines for a living. CSS is getting more complex and spaghetti-capable by the day.
> Currently only supported in Chrome 141+. The @function rule is going through the W3C standardization process and will be available in other browsers soon.
Also, pretty tired of Chrome effectively front-running standards as a not-so-subtle means of cramming them through.
Web standards are in the same boat as C++. They can never really deprecate anything, but they want shiny new things, so they just add and add on top of the pile.
Every feature sounds great in isolation, but in aggregate they become a moloch.
Then people say “modern CSS is great, you just have to pick the ‘good subset’.”, but then nobody can agree what that subset should be, and everybody else uses a different subset.
LLMs also contribute to this, as 90% of what’s available on the web is considered outdated now, but that is the majority of training data.
One person's front-running is another's reference implementation.
Although, yes, CSS is getting more complex because everything on the web is. What's the last standard feature to really be taken away after actually existing in the wild for a while? XHTML and Flash (effectively a standard if not in reality)?
One problem I think people are going to run into here is loading CSS libraries from the components that use them.
Luckily, CSS Modules are starting to land in multiple browsers. Firefox added support behind a flag, and it might ship in 145.
So you'll be able to import the CSS from your JS modules, and apply it to the document:
Or, if you use shadow DOM:
It is time to reject this ugly double dash prefix kebab-cased variables names. PHP looks better in comparison.
What goes in some people's mind when they come up with these ugly conventions and rules?
A single global namespace makes you start doing interesting and horrible things when you need to divide it.
Not supported by Firefox or Safari
https://caniuse.com/?search=%40function
Yes, @function is still at the "public working draft" stage. https://www.w3.org/TR/css-mixins-1/
Welp, time to make a @function preprocessor. There is no reason for every single client to recalculate things which could have been completely or partially calculated at build time.
I used to share this sentiment (and I’m a web performance consultant by profession so very few people care about performance as much as me!), but when you consider how much calculation we _happily_ let our JS do at runtime, I don’t think forcing CSS to be static/preprocessed is worth it. And that’s not even me taking a swipe at overly-JSsed front-end; I’m talking about any runtime work that JS picks up.
Is preprocessed CSS faster? Yes. Is it meaningfully faster? Probably not.
An optimisation I've always wondered about for transforming/translating/animating elements: is it faster to use JS translations or animation API directly on the element (e.g. style.transform / element.animate), or updating CSS variables with JS to let the CSS engine reposition inheriting elements?
In the context of animations, I'd intuit the latter but would be open to hearing why.
2 replies →
But there are also plenty of use cases where recalculation will be valuable in the client. CSS variables cascade so a preprocessor isn't going to be able to know ahead of time what any given variable value is.
Sure, the new syntax allows doing some nifty stuff with the cascade. In practice, however, I foresee most usage being simple one-time transformations of design tokens. I suppose it is more of a theme architecturing issue.
1 reply →
It's a tradeoff. I expect this to be non-trivial, do nothing in the general case (when referring to runtime CSS vars) and possibly increase your final CSS size for any sufficiently complex codebase when unrolled.
CSS is becoming a programming language and not just a style sheet. Don't worry about performance, soon you'll be able to run assembly in it.
Yet recently I couldn't find a way to count cousin elements using has and nth-of-type. JS still is needed when use case gets a little complex.
1 reply →
Obvious question: are CSS functions Turing complete?
No. The implementation treats the function body as just another CSS rule set, which is applied to some virtual element. The ”result: somevalue;” rule then sets the ”result” style property on that element, and that property value gets plopped onto the call site.
Kinda clever, actually.
They are not allowed to loop or recurse, so no, by themselves, they are not (unless you accept repeating the function a potentially infinite amount of time).
CSS in general is Turing complete if you allow running multiple frames, although it requires ugly hacks. See e.g. https://codepen.io/propjockey/pen/dywNyBQ, which is quite insane IMO.
CSS Custom Functions are defined in a way they don't add anything over traditional CSS in this regard. I.e. they are just allowed to act as custom functions - not recursion mechanism, jump mechanisms, loop mechanisms, etc.
Stupider question: how long until it can run Doom?
I remember there's expression() on IE6.
Way ahead of its time. Unfortunately.
CSS is changing so fast. I guess we will see Doom in CSS shortly
This may feel true if you've re-engaged with CSS's progression in the last ~5–7 years. In reality, the last big qualitative leap was Grid in 2017.
This project is based on just one new proposed rule which won't be available in all mainstream browsers until 2027-28, and won't be safe for production use until close to the end of the decade.
In reality, CSS's big changes are a drumbeat pounding monthly: https://developer.chrome.com/blog/css-wrapped-2023 https://chrome.dev/css-wrapped-2024/
Of note from 2023: subgrids, :has, container queries, nesting... And in 2022, cascade layers (plus <style scoped>, I mean @scope, I mean :scope).
The last big thing was grid? Sorry but there are big things coming to css nearly every month. Container queries, @scope ... and so on
I’m so confused why people are ragging on this. Why is this considered detrimental? Looks pretty good to me…
I'm no expert in this domain, but I suspect it's less "this is a bad problem to solve" and more "every solution to a problem moves farther away from the ideal simplicity of a markup langage."
(I'm not weighing in on the validity of this position, just reporting what I perceive the position itself to be.)
People who don’t understand the problems CSS has to solve are opposed to CSS solving those problems. Sure it can all be stuffed into Tailwind classes!!
¯\\_(ツ)_/¯
It's a post about web development on HN. Half the comments will rag incessantly, half will talk about how the web should go back to being a delivery mechanism for documents only like it's 1995 forever, someone will rant about Google for some reason. It's a neverending nightmare.
Don't forget the people that have to tell us how much they hate JavaScript on every single web dev post too
CSS is becoming the new JavaScript.
As someone who works with both those languages professionally, I’m not sure what you mean by that. CSS applies to a new narrow band of the spectrum of how the web functions.
It would be quite nice to see some more "killer" uses of this new feature that aren't just "we removed some duplication and... saved less than 1% of our loc".
And maybe there are some really compelling ones... I think the only really useful one I see here is `--abs`, which really should just be built-in.
abs() exists with cross-browser support:
https://developer.mozilla.org/en-US/docs/Web/CSS/abs
There are also other non-custom math functions like round() which can be very useful.
Oooh this will not end well.. Also side question, is it really necessary to have this as an npm package ?
> Oooh this will not end well..
On the contrary. CSS functions and mixins may make a lot of current cruft unnecessary.
> is it really necessary to have this as an npm package ?
Is anything really necessary? Not snark: almost nothing is necessary in life but many things are convenient.
Surely a cdn is more convenient. I don't want to install an entire package manager just to 'install' 2 CSS files.
5 replies →
Whoo. I’ll be the first hyper negative prototypical HN commenter.
I’m glad I don’t work on browser engines for a living. CSS is getting more complex and spaghetti-capable by the day.
> Currently only supported in Chrome 141+. The @function rule is going through the W3C standardization process and will be available in other browsers soon.
Also, pretty tired of Chrome effectively front-running standards as a not-so-subtle means of cramming them through.
The standard for this has been developed in the open at the CSSWG with one of the SASS developers:
https://github.com/w3c/csswg-drafts/issues/9350
Web standards are in the same boat as C++. They can never really deprecate anything, but they want shiny new things, so they just add and add on top of the pile.
Every feature sounds great in isolation, but in aggregate they become a moloch.
Then people say “modern CSS is great, you just have to pick the ‘good subset’.”, but then nobody can agree what that subset should be, and everybody else uses a different subset.
LLMs also contribute to this, as 90% of what’s available on the web is considered outdated now, but that is the majority of training data.
One person's front-running is another's reference implementation.
Although, yes, CSS is getting more complex because everything on the web is. What's the last standard feature to really be taken away after actually existing in the wild for a while? XHTML and Flash (effectively a standard if not in reality)?
XHTML (or the XML syntax for HTML) wasn't removed (see: https://html.spec.whatwg.org/multipage/introduction.html#htm...). You may be thinking of XSLT, which may be removed in future.
3 replies →
Shadow DOM v0 was removed from Chromium in 2019 (with a lot of pain involved).