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!!
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.)
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.
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.
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.
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.
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.
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.
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.
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.
> What goes in some people's mind when they come up with these ugly conventions and rules?
The earlier versions of the CSS spec had no double dash prefix sigil for custom properties.
You could just make up a value like: "bigger", "accent", etc...
The problem is that CSS needs to be able to add new properties overtime, and we don't want any name collisions with variable names that web developers have already taken.
So we need a sigil that only custom properties and that regular properties can't use.
- We can't use `$` because that would conflict with SCSS, and we wouldn't be able to use custom properties in the same file as scss variables
- We can't use any of the following symbols because they're already used in CSS itself: !@#.,%^&>~:?\|{}`()+*/"';
- We can't use `<` because it could harm parsing performance.
- We can't prefix with `-`, `_`, or `__` because developers have already used them in their files.
- That seems to leave just: `--` or something even weirder.
So `--` is longer but in the context of not breaking anything, it's the best option on the table.
-------------
Now we're in this unusual spot where custom properties are genuinely more useful then what came before (they're like scss vars but they can update live and cascade too!), but they're a little wordy.
Probably not for long though, the upgraded attr() function will remove a lot of the massive walls of definitions that too many design systems and methodologies are relying on, and the upcoming functions used with the conditionals (if, media, where, not etc...) will take that further.
CSS isn't exactly a clean language. In my experience most projects are write-only... CSS just accumulates. It is rarely refactored or carefully designed. It is only occasionally mass deleted in redesigns and redone. Having a standard namespace pattern eliminates a lot of hierarchical issues, which is a very common issue with CSS.
Utility based libraries tend to avoid this these days and use simpler names, but those are also supposed to be your root libraries, not your custom CSS.
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.
Readit News
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:(I'm not weighing in on the validity of this position, just reporting what I perceive the position itself to be.)
Is preprocessed CSS faster? Yes. Is it meaningfully faster? Probably not.
In the context of animations, I'd intuit the latter but would be open to hearing why.
https://caniuse.com/?search=%40function
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.
Kinda clever, actually.
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.
Of note from 2023: subgrids, :has, container queries, nesting... And in 2022, cascade layers (plus <style scoped>, I mean @scope, I mean :scope).
What goes in some people's mind when they come up with these ugly conventions and rules?
The earlier versions of the CSS spec had no double dash prefix sigil for custom properties.
You could just make up a value like: "bigger", "accent", etc...
The problem is that CSS needs to be able to add new properties overtime, and we don't want any name collisions with variable names that web developers have already taken.
So we need a sigil that only custom properties and that regular properties can't use.
- We can't use `$` because that would conflict with SCSS, and we wouldn't be able to use custom properties in the same file as scss variables
- We can't use any of the following symbols because they're already used in CSS itself: !@#.,%^&>~:?\|{}`()+*/"';
- We can't use `<` because it could harm parsing performance.
- We can't prefix with `-`, `_`, or `__` because developers have already used them in their files.
- That seems to leave just: `--` or something even weirder.
So `--` is longer but in the context of not breaking anything, it's the best option on the table.
-------------
Now we're in this unusual spot where custom properties are genuinely more useful then what came before (they're like scss vars but they can update live and cascade too!), but they're a little wordy.
Probably not for long though, the upgraded attr() function will remove a lot of the massive walls of definitions that too many design systems and methodologies are relying on, and the upcoming functions used with the conditionals (if, media, where, not etc...) will take that further.
Utility based libraries tend to avoid this these days and use simpler names, but those are also supposed to be your root libraries, not your custom CSS.