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.
> If you break Safari then no one on an iPhone or iPad can use your site.
A CSS issue is not going to break any site unless it causes interactive elements to overlap or be hidden from view. Most sites do not implement bleeding-edge features for this reason. Those that want to set it up will do it in such a way that there's a fallback for browsers that don't support that function.
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.
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.
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 looks wrong to me - it looks like it should always return ‘light,’ because the ‘if prefers dark then return dark’ conditional is introduced after the default result
Is it more like - result is a variable that can be redefined over and over during the function, and whatever value it is at the end, is what’s returned?
I didn't know about this and looked it up. I've played around with P5.js, the Canvas-based library for animations and generative art, and this syntax is almost exactly how DOM elements are styled in there.
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)
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.
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.
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.
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.
The syntax is getting pretty un-CSS like though, so how much of a benefit is it going to be? FE developers would still have to learn another new way of doing something that can be handled with JS.
I didn’t interpret it as a break in compatibility, more so that simply because a new feature or addition in CSS arises it doesn’t stipulate that you have to adopt it. You can still continue on writing CSS how you want to. I appreciate that it makes it more difficult when new features come about in a language and you have to work on a shared codebase, you sometimes spend a while looking at many differing ways to achieve the same result.
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.
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.
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.
And that's fine as long as there's a "build/process *.sass" step happening on the server before the resulting HTML+CSS is getting sent to the client (browser).
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.
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.
Bramus is a frontend web developer from Belgium, working as a Chrome Developer Relations Engineer at Google.
Exactly.