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.
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.
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.
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.
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.
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.
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.
This feels like a particularly bad case of 'every templating system eventually turns into a (bad) programming language'. It appears to have global+local variables, functions, mixins with positional and named arguments, and so on, all mashed together with the existing CSS features like media queries and nested selectors. But some of it isn't meaningful in combination, as the document itself says.
I have two major objections:
- There is no way that people who are currently writing conditional CSS-in-JS would switch to a system with a more obscure syntax, where they can't just use the same variables as their normal code, pull in imports from shared themes and libraries, and so on. This proposal includes basic local scoping rules, but they are a poor imitation of what we know works in real codebases. So the audience is people who use preprocessors, and who get around the lack of e.g. arrays or dictionaries by generating sequential variable names.
- Once you actually add functions and imperative control flow, much of the existing CSS selector machinery becomes obsolete. Why should you wrap things in `@media`, when you could just have a variable or function to query? What is the criterium for determining whether something should be declarative or imperative? Will every feature end up being available in both forms? Why or why not?
I find it particularly funny that one of the examples involves applying a 'clearfix' to an element, which is a technique from the proverbial CSS stone age. That is, they are still inserting invisible pseudo-elements to make the layout behave, which shows markup and styling are tied together anyway.
The main thing CSS-in-JS lets you do is not automate this sort of style hackery, it's to create sensible wrappers and components that actually decouple layout from content in a way that is practical, stacks cleanly, and maps directly to e.g. how a designer does it in Figma.
And instead of adding e.g. endless new color manipulation functions in CSS, you should use a proper library for this. Whatever argument there was for not allowing CSS to call into JS, it starts to look ever less convincing when this is the alternative.
Maybe all we need is a more sensible interface between JS and CSS, perhaps something patterned after declarative frameworks. i.e. They should add a Color type to DOM APIs, instead of adding control flow to CSS.
This is a direction leading to a programming language for css. I like these feature, but is this necessary? There is JavaScript and it has all needed for programming. Wouldn't it be good if we could use JavaScript in the browser for these features?
The market has already spoken: people want a better developer experience with CSS. At this point, if you're working on a non-trivial app, you're either using some CSS-in-JS solution, or using a pre-processor, but you're probably not just writing CSS directly. The specification should include the things we know people already need to work with it.
The question is how will it be implemented. Personally, I always greatly preferred Stylus' approach, and never understood why Sass was so well liked. If the CSS-WG doesn't come up with its own weird syntax, it'll probably be something like Sass, which will be fine I guess.
I think its due to Ruby on Rails, when Ruby SASS was a thing, it was around the same time of "Peak Rails" (mindshare wise certainly) and was used as part of the provided build pipeline.
That, more than anything, popularized SASS in my mind
Yeah! Ruby Sass was my first exposure to CSS preprocessing. Such an improvement at the time. I used it for a decade. Then some intern at a company I was working for said, "y'all tried Stylus?" and within about 10 minutes I was converted. But, not everybody had that experience I guess.
I work on a fairly complex application, and use neither of those.
Besides, why would the specification for CSS take into consideration anything that's not pure CSS. Do JS maintainers take into consideration that people are transpiling javascript from typescript/dart/...?
The ECMAScript standard did consider transpiled languages - for example, by incorporating concepts from CoffeeScript like classes, destructuring, arrow functions. For sure they're considering ideas from TypeScript.
I'd imagine some advances in the CSS specs are influenced by concepts from traspiled languages such as Sass, for example, variables and nested selectors.
was just thinking this. work on a variety of complex webapps across multiple frameworks and you'd never catch me dead using css-in-js or a preprocessor.
This is big. Basic functions are a large reason we've had so much tooling around CSS for a long time. First with preprocessors, then with with CSS-in-JS. Making this native, and able to run at the browser level will solve a large portion of the theming and CSS-at-scale problems that most of us have jumped to extra tooling to solve.
Over the past few years CSS is getting better and better. They're really pushing back on removing reasoning for using anything but the vanilla defaults.
Mixins and functions might be of some use if the end-user (rather than the document author) is able to use them to override the meaning of existing CSS commands. That still isn't the best way of doing such a thing, though; but it would help a bit. (If done well, it might also allow extensions to implement some parts of CSS in CSS, therefore allowing browser writers to omit some stuff.)
(However, it is unfortunate that WWW is so messy that such things are even necessary)
Readit News
https://github.com/w3c/csswg-drafts/issues/9350#issuecomment...
> RESOLVED: Start ED of css-mixins for CSS Custom Functions and Mixins
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.
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...
Deleted Comment
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.
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.
I wish it was also stacked like SCSS. Maybe some day.
https://caniuse.com/css-nesting
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.
Deleted Comment
I have two major objections:
- There is no way that people who are currently writing conditional CSS-in-JS would switch to a system with a more obscure syntax, where they can't just use the same variables as their normal code, pull in imports from shared themes and libraries, and so on. This proposal includes basic local scoping rules, but they are a poor imitation of what we know works in real codebases. So the audience is people who use preprocessors, and who get around the lack of e.g. arrays or dictionaries by generating sequential variable names.
- Once you actually add functions and imperative control flow, much of the existing CSS selector machinery becomes obsolete. Why should you wrap things in `@media`, when you could just have a variable or function to query? What is the criterium for determining whether something should be declarative or imperative? Will every feature end up being available in both forms? Why or why not?
I find it particularly funny that one of the examples involves applying a 'clearfix' to an element, which is a technique from the proverbial CSS stone age. That is, they are still inserting invisible pseudo-elements to make the layout behave, which shows markup and styling are tied together anyway.
The main thing CSS-in-JS lets you do is not automate this sort of style hackery, it's to create sensible wrappers and components that actually decouple layout from content in a way that is practical, stacks cleanly, and maps directly to e.g. how a designer does it in Figma.
And instead of adding e.g. endless new color manipulation functions in CSS, you should use a proper library for this. Whatever argument there was for not allowing CSS to call into JS, it starts to look ever less convincing when this is the alternative.
Maybe all we need is a more sensible interface between JS and CSS, perhaps something patterned after declarative frameworks. i.e. They should add a Color type to DOM APIs, instead of adding control flow to CSS.
The question is how will it be implemented. Personally, I always greatly preferred Stylus' approach, and never understood why Sass was so well liked. If the CSS-WG doesn't come up with its own weird syntax, it'll probably be something like Sass, which will be fine I guess.
That, more than anything, popularized SASS in my mind
Besides, why would the specification for CSS take into consideration anything that's not pure CSS. Do JS maintainers take into consideration that people are transpiling javascript from typescript/dart/...?
I'd imagine some advances in the CSS specs are influenced by concepts from traspiled languages such as Sass, for example, variables and nested selectors.
Deleted Comment
Over the past few years CSS is getting better and better. They're really pushing back on removing reasoning for using anything but the vanilla defaults.
Deleted Comment
(However, it is unfortunate that WWW is so messy that such things are even necessary)