CSS WG resolved to officially work on native custom functions and mixins | Hacker News Reader

CSS WG resolved to officially work on native custom functions and mixins

css.oddbird.net

70 pointsdonohoe62 comments

The link corresponding to the actual submission title (“CSS WG resolved to officially work on native custom functions and mixins”):

https://github.com/w3c/csswg-drafts/issues/9350#issuecomment...

> RESOLVED: Start ED of css-mixins for CSS Custom Functions and Mixins

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.

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.

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

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.

"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.

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

> 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.

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.

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.

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.

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.

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).

> 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.

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

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.

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

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...

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.

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.

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.

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

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

CSS nesting is available in all the important browsers today.

https://caniuse.com/css-nesting

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

> 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.

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.

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

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.

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

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.

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.

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.

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.

Agreed. This is what javascript is for.

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.

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 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.

I don’t follow this logic at all. An idea can be rained by virtue of it first being included in a preprocessor? postcss would like to have a word.

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.

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.

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)

Without proper debugging tools this would be pure hell.

Just look how torturous it is today to work with clac() directives using more than 3 operands.

This seems fine to me. I won't use it much, but it will make CSS "frameworks" a lot more sensible from a dependency perspective (i.e. just a bag of pure CSS functions someone wrote), and people will continue to create abominations of CSS regardless of the available tools.

I see there is a while keyword - doesn’t this make it turing complete? You can now loop, call functions, set variables - you could build a full processor emulator in pure css!

Since CSS tries to stay purely declarative, it would be cool if for the functions they introduced a purely functional language.

But it is going to end up being JS, of course.

They have examples there; it’s just pure CSS, and “declarative” still.

Granted the `@function` and `var(--variable)` syntax is as clunky as ever, but it’s still distinctly not JS in any way.

I see, so far it's simple pure functions.

But I think the vector is towards everything becoming JS anyway.

I'd love to be proven wrong.

Sorry, but with increasing the complexity of CSS aren't we just adding complexity to the web stack ensuring that only Chrome/Firefox/Webkit are the only browsers to ever exist again?

I can't imagine this ever being supported in an ePub reader _not_ based on one of the above.

At this point, why have W3C involved when Apple, Google, and Mozilla could just hash it out amongst themselves?

Yeah, but also you can build browsers that only support portions of the specifications considering standards like CSS are broken up into various modules.

You don't need to build a browser that supports JavaScript, either. You could implement any other language you wanted. Python! C?! Go? Rust?

Writing a toy browser that supports small subsets of web standards is fun, and not too difficult.

You could build that but it won't be able to browse the actual web. You're just building another platform.

> At this point, why have W3C involved when Apple, Google, and Mozilla could just hash it out amongst themselves?

The W3C facilitates that for them sow why reinvent that wheel? The W3C is not meant to be independent of other organizations involved in making the web rather made up by them.

Because the W3C and the IETF should be vendor neutral organizations that serve the broader good and general interoperability. When it's really 2 of the world's largest organisations (we'll see how long Firefox lasts) it's really just rubber stamping their agenda.

Maybe it's naive, but it seems like just yet another betrayal of the open web and HTML as a part of that.

Didn't the w3c make a hash of that when it was mostly true? I'm thinking the XHTML debacle and related dead-ends.

A noble goal but more a wish of what they should offer rather than a view of what they do offer which is why Mozilla/Apple/Google/Microsoft don't feel the need to do things outside of it.

Reply on news.ycombinator.com