This is exactly the sort of propaganda which encourages making sites that don't work in any browser but Google's. If web developers would just focus on making simple and widely-accessible sites instead of churnful trendchasing, the browser monopoly wouldn't exist.
Bramus is a frontend web developer from Belgium, working as a Chrome Developer Relations Engineer at Google.
I agree Google has too much market share and sway over plenty of browser features.
However… CSS features are a W3C specification and are an early stage [1]. It’s a process that vendors draft and agree on and can terminate.
On top of that I wouldn’t characterise improving css with functions isn’t a _churnful trendchasing_. If anything this will improve accessibility because it’ll be easier to manage size, colour, and motion preferences with better abstractions than media queries everywhere.
Too many on HN seem to forget that Safari exists and has a large market share. If you break Safari then no one on an iPhone or iPad can use your site. That's an unacceptable level of breakage for almost every site, and is enough to ensure that if Apple doesn't implement it it won't be used.
Ironically, Apple's walled garden is the last thing standing between Google and total web dominance.
Sorry, this is a ridiculous claim. This spec has been worked on for years in the CSSWG with participation from multiple browser implementers, Igalia, and other community members.
Custom functions have been a huge web developer request for a long, long time and is one of the remaining gaps between standard CSS and Sass/LESS, after variables and nesting shipped. Mixins are next, and they'll be good too.
Not every advancement in the web platform needs to be some kind of conspiracy.
Either it will be popular enough that other browsers will implement the open standard, or it will not be popular and no one will implement it in other browsers and few sites will use it.
Mozilla has a revenue of like $600M. They should have no problem keeping up with popular w3c standards. Hell, even opera, with only a tiny fraction of users can keep up.
Looks decent to me, I understand they have to stay within the normal look of CSS. That function, other than nesting, could every well be parsed by a 20-year-old parser.
This is it. This is all I’ve wanted in CSS for the last decade. In fact, I just wanted basic mixins without function-like behavior, but this gets me there.
The comments here indicate that the article doesn’t do much to explain what this does or why you’d want it, but basically this gives you a way to reuse blocks of styles without needing to resort to e.g. utility classes or other hacks that get around specificity issues. The syntax doesn’t help explain that.
Shame about the syntax, but I’m used to it at this point.
Can you expand with some examples of pressing use cases? To me, great complexity should bring even greater utility. I have no use for this, and I’m not sure who it’s for. Can we get rid of tailwind? Polyfills? Any UI libs?
It’s hard to explain because most web development solves these problems with CSS in JS with JS runtimes. One use case I have is what I call “responsive variants”; basically a way to apply a variant’s styles on a component instance (speaking abstractly here; could be react, vue, whatever) within any arbitrary styling context without duplicating CSS or resorting to something that applies CSS with a JS runtime.
I work on a web development platform for a living and this is the sort of thing that would be good for us; if you don’t want your website to wait for JS to render content correctly and you want to keep your CSS bundle small, there aren’t many good options.
These are not mutually exclusive proposals. Houdini provides a way to extend e.g. CSS with arbitrary JS. This is merely a new abstraction for code-reuse in CSS. It’s inspired by the same concept from Sass, but doesn’t need to be compiled and thus won’t bloat your CSS bundle.
Oh man, and I thought the current JS status-quo was already full of vulnerabilities and privacy risks.
If I had mind-boggling amounts of money, one of the things I would do is start an organization to name and shame and give anti-awards to websites that most abuse javascript and whatever-this-will-be. Or a dang mutual fund: "Like an index fund except we don't support companies with websites that require a ridiculous amount of control over the client computer."
Wait, who am I kidding: A real activist tycoon would probably just become a shareholder and make demands.
Okay you had your FUD, now for the just desserts: This is actually a feature that is likely to reduce the amount of JS that needs to run on the web. It allows for common component-oriented styling patterns to be employed without bloating CSS bundles or using runtime CSS-in-JS functionality to accomplish it. Source: I work on a web development platform (booo, hisss)
I'm confused at all the negativity? I am personally very excited for this feature, it's going to enable one to use less JavaScript,and CSS to accomplish things that should be easy.
I do think it's strange that using a wrapper like var() wasn't required here. Like func() or such. I'd actually rather that var() hadn't existed to begin with, but it should be consistent, at least.
I don't know how the web does it. There are so many cool things being added. How do they keep the spec manageable? What if someone wanted to build a compliant web browser from the ground up?
That's not a concern of the people writing the spec, but Ladybird is making an admirable go of it. You can shed a lot of complexity by only focusing on the modern standards, and Ladybird has helped fix several bugs in the standards themselves.
Why not just use CSS-in-JS at this point? With functions and if statements, you now have two full Turing-complete programming languages in the browser.
Why? If the problem is JS bundle parse time, couldn't you just have a special kind of <script> tag that opts out of compilation and runs in interpreted mode only, and stick your layout JS in there? Having two entirely separate languages seems like such a waste of effort both on the platform side, and on the web developer side having to learn so many things.
It absolutely has breaking changes! But most developers will never notice. I work on a complex browser based web development platform and we’ve had certain specs change under our feet leading to incidents that required us to disable features until major browser vendors reverted things. I do not envy spec authors. Huge respect for their patience.
No worries, the web is already went wrong from the original purpose. Google is outdated itself. Better they update their own blog spot site layouts/functions before touching the web.
These aren't functions in the traditional programming sense. Looking at examples in the spec, they're mostly a way to do conditional logic around which properties to apply when (desperately needed in CSS as the only way to do this now—if at all—is with media queries, funky selectors, or as a last resort, JavaScript).
Just finished work on a new CSS framework and would have loved to have stuff like this. If it lands with baseline support, I'd be able to save a lot of footprint using these.
Taking bets now on how long after release it takes to end up with someone making a "JS in CSS" framework, but with the added wrinkle that they have to be serious about it, not just doing it as a joke.
So taking the article seriously and not just being glib:
This feels like a misunderstanding of how to write good CSS. Good CSS is a lot like SQL, which shouldn't be a surprise since it's centered around selectors. CSS is a set-based language. Adding general purpose functions that seem to abuse rule precedence to make conditional statements feels like a dirty hack to force CSS into an imperative model.
Now, maybe there is something to be said for the idea that, here we are, 30 years into having CSS, and people are still bad at set-description operations. Maybe there should be an imperative styling language. But it's a mistake to overload CSS to do it.
You have a (very common) mistaken view of what the W3C is and how it works. It is NOT an independent standards body that tells browser makers what to do! In fact, it's the exact opposite: the browser makers (and Google is a big one) tell the W3C what to do.
This makes perfect sense if you think about it, because the browser makers ultimately decide what goes into the browser. If the W3C was "in charge" and tried to make Google (or another browser maker) do anything, Google could simply ignore them. That system wouldn't last.
It has to work this way ... and Google (along with Apple, Microsoft, etc.) have decided this syntax is best for them (and possibly their users).
While I think this particular idea is bad, Google is following the W3C process for proposing new features. This is what browser vendors are supposed to do: develop the feature, document it so other vendors can implement/compete it, see if there's enough early-adopter developer interest to bother standardizing.
... no, you're still not understanding the nature of the W3C.
The W3C is descriptive, not prescriptive. It doesn't have any regulatory power, so it can't make design decisions or value judgements of any kind. It isn't even a separate group from the browser vendors; while individuals may join, the vast majority of active members are the developers working on the browsers.
The teeth come from the other browser vendors. They make pledges to each other to implement each other's features. They collaborate through the W3C to come to a consensus on feature designs, because a feature can't get standardized if it's not implemented by more than one vendor and it won't get implemented if the vendors can't come to a consensus.
Anything the W3C says is not how browsers should work, it's how they already work.
This is exactly the sort of propaganda which encourages making sites that don't work in any browser but Google's. If web developers would just focus on making simple and widely-accessible sites instead of churnful trendchasing, the browser monopoly wouldn't exist.
Bramus is a frontend web developer from Belgium, working as a Chrome Developer Relations Engineer at Google.
Exactly.
I agree Google has too much market share and sway over plenty of browser features.
However… CSS features are a W3C specification and are an early stage [1]. It’s a process that vendors draft and agree on and can terminate.
On top of that I wouldn’t characterise improving css with functions isn’t a _churnful trendchasing_. If anything this will improve accessibility because it’ll be easier to manage size, colour, and motion preferences with better abstractions than media queries everywhere.
[1] https://drafts.csswg.org/css-mixins/
At this point the W3C is basically under control of Google anyway.
Non sense. Read the reply: this is a feature that is coming to all major browsers
coming to all major browsers
Chrome, Chrome, Chrome, and Chrome?
Too many on HN seem to forget that Safari exists and has a large market share. If you break Safari then no one on an iPhone or iPad can use your site. That's an unacceptable level of breakage for almost every site, and is enough to ensure that if Apple doesn't implement it it won't be used.
Ironically, Apple's walled garden is the last thing standing between Google and total web dominance.
- Developers: Ask for something for decades
- Google: It's implemented
- People: Screw Google and their monopolistic tactics
> If web developers would just focus on making simple
That boat is long gone. The people with money don't want that, they want a platform on which to shove ads down your throat. It's successful.
Sorry, this is a ridiculous claim. This spec has been worked on for years in the CSSWG with participation from multiple browser implementers, Igalia, and other community members.
Custom functions have been a huge web developer request for a long, long time and is one of the remaining gaps between standard CSS and Sass/LESS, after variables and nesting shipped. Mixins are next, and they'll be good too.
Not every advancement in the web platform needs to be some kind of conspiracy.
This idea has traction with other browser vendors too, FWIW. They just don’t have godlike budgets, unfortunately.
Either it will be popular enough that other browsers will implement the open standard, or it will not be popular and no one will implement it in other browsers and few sites will use it.
Mozilla has a revenue of like $600M. They should have no problem keeping up with popular w3c standards. Hell, even opera, with only a tiny fraction of users can keep up.
isn't opera just chrome now? that would obviously let them keep up
Yeah Opera uses Blink just like Chrome. Vivaldi browser, created by Opera's original team does as well.
Thanks. Looks hideous.
@function --light-dark(--light, --dark) {
It does look like something a Googler came up with.
Looks decent to me, I understand they have to stay within the normal look of CSS. That function, other than nesting, could every well be parsed by a 20-year-old parser.
looks like Racket got high and all its parentheses become wobbly
makes my eyes hurt
Yeah, I couldn't believe it at first.
If you're going to add imperative programming to CSS, just do it already. Hacking in conditionals in this way feels like a bad joke.
These are closer to macros than functions, especially without css if(). It's nothing that you can't already do.
This is it. This is all I’ve wanted in CSS for the last decade. In fact, I just wanted basic mixins without function-like behavior, but this gets me there.
The comments here indicate that the article doesn’t do much to explain what this does or why you’d want it, but basically this gives you a way to reuse blocks of styles without needing to resort to e.g. utility classes or other hacks that get around specificity issues. The syntax doesn’t help explain that.
Shame about the syntax, but I’m used to it at this point.
Can these be used as mixins? I looks like there’s only a single return value.
Edit: Looks like mixins are planned: https://github.com/w3c/csswg-drafts/issues/9350#issuecomment...
Can you expand with some examples of pressing use cases? To me, great complexity should bring even greater utility. I have no use for this, and I’m not sure who it’s for. Can we get rid of tailwind? Polyfills? Any UI libs?
It’s hard to explain because most web development solves these problems with CSS in JS with JS runtimes. One use case I have is what I call “responsive variants”; basically a way to apply a variant’s styles on a component instance (speaking abstractly here; could be react, vue, whatever) within any arbitrary styling context without duplicating CSS or resorting to something that applies CSS with a JS runtime.
I work on a web development platform for a living and this is the sort of thing that would be good for us; if you don’t want your website to wait for JS to render content correctly and you want to keep your CSS bundle small, there aren’t many good options.
How do you replace mixins with those functions?
Was https://en.wikipedia.org/wiki/JavaScript_Style_Sheets right all along?
This feels like a really bad idea, I hope it doesn't make it into the browser. CSS Houdini would be a better path to take.
These are not mutually exclusive proposals. Houdini provides a way to extend e.g. CSS with arbitrary JS. This is merely a new abstraction for code-reuse in CSS. It’s inspired by the same concept from Sass, but doesn’t need to be compiled and thus won’t bloat your CSS bundle.
Oh man, and I thought the current JS status-quo was already full of vulnerabilities and privacy risks.
If I had mind-boggling amounts of money, one of the things I would do is start an organization to name and shame and give anti-awards to websites that most abuse javascript and whatever-this-will-be. Or a dang mutual fund: "Like an index fund except we don't support companies with websites that require a ridiculous amount of control over the client computer."
Wait, who am I kidding: A real activist tycoon would probably just become a shareholder and make demands.
Okay you had your FUD, now for the just desserts: This is actually a feature that is likely to reduce the amount of JS that needs to run on the web. It allows for common component-oriented styling patterns to be employed without bloating CSS bundles or using runtime CSS-in-JS functionality to accomplish it. Source: I work on a web development platform (booo, hisss)
Pointed out well!!!
I'm confused at all the negativity? I am personally very excited for this feature, it's going to enable one to use less JavaScript,and CSS to accomplish things that should be easy.
I look forward to writing Typescript that transpiles to Javascript that writes CSS that calls functions.
Maybe throw some wasm in there.
It seems like the spec draft itself offers a much better example than the article.
https://drafts.csswg.org/css-mixins-1/
I do think it's strange that using a wrapper like var() wasn't required here. Like func() or such. I'd actually rather that var() hadn't existed to begin with, but it should be consistent, at least.
OK but how about they fix broken CSS variables first before this?
Why stop there? Why not add interfaces, OO and design patterns while we're at it? Then CSS will be a "real" language.
I don't know how the web does it. There are so many cool things being added. How do they keep the spec manageable? What if someone wanted to build a compliant web browser from the ground up?
That's not a concern of the people writing the spec, but Ladybird is making an admirable go of it. You can shed a lot of complexity by only focusing on the modern standards, and Ladybird has helped fix several bugs in the standards themselves.
Is it time for "CSS: The Good Parts" ?
Why not just use CSS-in-JS at this point? With functions and if statements, you now have two full Turing-complete programming languages in the browser.
Why? If the problem is JS bundle parse time, couldn't you just have a special kind of <script> tag that opts out of compilation and runs in interpreted mode only, and stick your layout JS in there? Having two entirely separate languages seems like such a waste of effort both on the platform side, and on the web developer side having to learn so many things.
Today on "everything that's wrong with modern web and more"
I don't see how this is wrong?
It’s just a new addition and change, doesn’t dictate you must write that way. I still use <center> as a tag (I know, HTML).
It's not about how they write CSS, it's about how everyone else does, and what browsers will need to be able to process.
I don't know how you figured their complaint is somehow compat breakage. From what I know, CSS doesn't really have breaking changes.
It absolutely has breaking changes! But most developers will never notice. I work on a complex browser based web development platform and we’ve had certain specs change under our feet leading to incidents that required us to disable features until major browser vendors reverted things. I do not envy spec authors. Huge respect for their patience.
Like using <table> for layout, <center> is still unreasonably convenient.
Finally, the inverse of CSS-in-JS.
Looking forward to DoomCSS
DOOM in CSS when?
"Your scientists were so preoccupied with whether or not they could, they didn't stop to think if they should."
Turns out they couldn't do it very well and they shouldn't have done it in the first place.
No worries, the web is already went wrong from the original purpose. Google is outdated itself. Better they update their own blog spot site layouts/functions before touching the web.
functions in stylesheets?
That's nuts.
The web is developing in the wrong way.
Instead of XSSs we will soon have XSCSFSs (Cross Site Cascading Style Function Scripting)!
At least it could probably run Doom
Already done.
https://github.com/yurkagon/Doom-Nukem-CSS
Not at least in that link. It is a clone and not running the original binary.
These aren't functions in the traditional programming sense. Looking at examples in the spec, they're mostly a way to do conditional logic around which properties to apply when (desperately needed in CSS as the only way to do this now—if at all—is with media queries, funky selectors, or as a last resort, JavaScript).
Just finished work on a new CSS framework and would have loved to have stuff like this. If it lands with baseline support, I'd be able to save a lot of footprint using these.
CSS preprocessors like Sass have had functions for, like, ever.
Always has been.
I wish we'd just admit we're heading for SASS and use that. It'd save a lot of hand-wringing and time spent justifying adding each feature.
This is yet another example of how declarative languages almost always evolve into full programming language if popular enough.
Usually with really bad syntax because the original design didn't expect that to happen.
Taking bets now on how long after release it takes to end up with someone making a "JS in CSS" framework, but with the added wrinkle that they have to be serious about it, not just doing it as a joke.
So taking the article seriously and not just being glib:
This feels like a misunderstanding of how to write good CSS. Good CSS is a lot like SQL, which shouldn't be a surprise since it's centered around selectors. CSS is a set-based language. Adding general purpose functions that seem to abuse rule precedence to make conditional statements feels like a dirty hack to force CSS into an imperative model.
Now, maybe there is something to be said for the idea that, here we are, 30 years into having CSS, and people are still bad at set-description operations. Maybe there should be an imperative styling language. But it's a mistake to overload CSS to do it.
There is so little to write about and so much to overengineer about our text systems that all we can do now is endlessly debate punctuation.
Why do we allow Google to singlehandedly keep pumping garbage into the web ecosystem? Do they own W3C?
You have a (very common) mistaken view of what the W3C is and how it works. It is NOT an independent standards body that tells browser makers what to do! In fact, it's the exact opposite: the browser makers (and Google is a big one) tell the W3C what to do.
This makes perfect sense if you think about it, because the browser makers ultimately decide what goes into the browser. If the W3C was "in charge" and tried to make Google (or another browser maker) do anything, Google could simply ignore them. That system wouldn't last.
It has to work this way ... and Google (along with Apple, Microsoft, etc.) have decided this syntax is best for them (and possibly their users).
While I think this particular idea is bad, Google is following the W3C process for proposing new features. This is what browser vendors are supposed to do: develop the feature, document it so other vendors can implement/compete it, see if there's enough early-adopter developer interest to bother standardizing.
Are there any examples of the W3C refusing a submission from Google?
... no, you're still not understanding the nature of the W3C.
The W3C is descriptive, not prescriptive. It doesn't have any regulatory power, so it can't make design decisions or value judgements of any kind. It isn't even a separate group from the browser vendors; while individuals may join, the vast majority of active members are the developers working on the browsers.
The teeth come from the other browser vendors. They make pledges to each other to implement each other's features. They collaborate through the W3C to come to a consensus on feature designs, because a feature can't get standardized if it's not implemented by more than one vendor and it won't get implemented if the vendors can't come to a consensus.
Anything the W3C says is not how browsers should work, it's how they already work.
[dead]
The syntax might kind of suck but this will actually be very useful to have.
holy shit I need to retire soon
I am too old for this sh*t
This comment chain gave me a good laugh.