CSS @property and the new style
https://ryanmulligan.dev/blog/css-property-new-style/I looked at the CSS for the first codepen example, and it looks like gibberish to me.
Should we really have a mini animations programming language in the styling system? This seems like a bit much. More than a bit much.
Can't this be done with Javascript? I get that a lot of people have a knee-jerk negative reaction to using JS for everything, but it's a programming language... this is kinda its job.
I don't understand this sentiment. If you are not a web developer, and in particular not a frontend web developer, then you probably aren't building html elements with these fancy effects. And if so, then why does it matter what advanced things CSS is capable of?
> Can't this be done with Javascript?
You can totally do this with javascript. You can plop in a canvas, and use webgl to program this effect on the GPU, like a real graphics programmer. You would have to recreate all accessibility features of the html button on your own. Is it going to be easier? I doubt it. But you certainly can.
I welcome opportunities to avoid javascript in my sites, even if it's more work for me. It makes life easy for visitors who prefer to disable javascript, thereby avoiding many of the exploits, trackers, etc. that plague the web today.
By the same token, I appreciate sites that do not require javascript.
The reasoning: some hosting platforms allow you to personalize your personal page changing the HTML and CSS bits, but not the JS - for security reason, obviously. Itch.io is an exmaple of that, where you can personalize your game and profile. By using CSS animations I can create cool effects without any of the security concern that allowing access to JS gives me. It makes sense and it's nice to be able to do so.
You and I are NOT designers if I may be so bold. In 1996 I was one of about 100 people on new and MAJOR website/application build. From scratch. My role: Billing Lead. As a "full stack dev" only my eCommerce insights were needed from me. It is called FOCUS.
As a StartupBus alumnus of three treks the model was brilliant: Build teams from three skill sets: Devs, Designers, and BizDevs. Focus.
I love that the examples will not be gibberish to the designers of our day.
My understanding of CSS animations is that they are particularly optimized to run more efficiently and it’s also helpful that it runs outside of the JS runtime, which frees it from any errors in the JS or it adding to the CPU load that may already be chugging along on the page.
Additionally (and this is old info so it may be outdated), using things like `translate3D()` instead of just `translate()` in your CSS will engage the GPU to handle whatever your instructions are, making everything smoother and further unburdening the CPU. This is from my own memory of things I read more than 10 years ago, so it’s possible that even more CSS functions use the GPU at this point, but I’ve not looked it up since.
Anyway, tl;dr: there are performance benefits to using CSS instead of JS for animations.
I'll have to play around with @property myself to get a sense of how it works - knowing esoteric CSS features is a superpower if you've got a complex UI to implement but wanna minimize JS dependencies.
Isn't that literally just css variables?
werent they cascading too, so the variable could be "overwritten" via classes etc? Isn't that even how tailwind does bg-opacity etc?
By default CSS variables can't be animated since it has no idea what unit it's animating between
Some privacy-conscious users disable JS, or use NoScript to selectively enable JS. My understanding is that this is (1) because JS engines are often themselves a source of vulnerabilities, (2) untrusted code execution might be risky in the face of speculation execution/access attacks.
Do such users need to worry about either, or both, with such advanced, compute-y CSS primitives?
But as lelandfe points out, CSS can do that, too, for form and mouse/touch inputs at least. So the main difference is that JS tracking is ubiquitous, and CSS tracking is very rare afaik.
(This isn't a response to the question about whether speculative execution attacks are possible, sorry.)
I don't see these new CSS features opening up privacy issues, though.
To do this, you can add or remove rules, or change the values of variables.
Something that might be a source of confusion for you is that CSS isn't an imperative language, it's a declarative language.
If you're not aware of the distinction:
- Declarative languages describe what they want the output to be but doesn't go through every single step on how to create the output. (e.g. html, css, regex, sql, nix, etc...)
- Imperative languages describe every single step on how to create an output, but not what the output actually is. (e.g. js/ts, php, go, c++, rust, etc...)
Since CSS is declarative, it doesn't have imperative steps on how to draw things (e.g. calculate a bunch of co-ords, then loop through all pixels between the co-ords while setting their pixel values to #0000FF). Instead we describe what we want (.box { background-color: blue }) and leave it up to the browser to decide how to do it.
This has several advantages from a web browsing perspective:
If someone figures out a better way to draw a blue box then every website developer doesn't need to go back and change their box drawing code. Instead, the browser developers change their box drawing code and now every website is automatically upgraded at the same time.
A browser might also make decisions on which way to draw a box. It might loop through each pixel one-at-a-time on a cheap cpu-only device, whereas it might pass some info to the GPU and have its shaders draw the blue box, or it might use some clever heuristics to determine that the blue box is above a large box that already has the same blue so there's no need to draw over the same space a second time.
There are other advantages to declarative languages too. Typically around being able to specify constraints to eliminate certain problems in the design of the language itself (e.g. race conditions, side-effects, indeterminate states, halting problem, etc...).
In the end, you want to use the language paradigm that makes the most sense for the situation at hand.
For scripting: you want imperative languages.
For information and presentation: you want declarative languages.
It is often not clear to me why something is off by 3 pixels or something.
Maybe it is the cascading nature of CSS hat makes it complicated. Or maybe it is the fact that I am also using JavaScript to dynamically alter the CSS. Or maybe CSS is just getting very complicated because of its evolving nature yet having to remain backwards compatible.
Following standard practice in regards to layout will help you here:
1. Use `box-sizing` everywhere (should be defined in your css reset file, example: https://piccalil.li/blog/a-more-modern-css-reset/)
2. If you can do something in css or js, do it in css.
3. Don't use pixel values anywhere (this avoid a lot of off-by-x errors when either the math is wrong or a previous assumption is violated by new code somewhere else). Two exceptions: a) The base font size on the root (usually the <html>) element. b) A 1px border, since the box-sizing in step 1 will allow you to take it from the element's block and inline size.
---------------------------------
Also, if you're trying to position text, or an icon inside a button and it seems off, you don't want to be trying to fine-tune the positioning with pixels.
It's always better to address the root cause.
Usually this is `line-height`, `vertical-align` and also the font itself. You can see lots of examples of the font being the issue here: https://tonsky.me/blog/centering/
If you run into this issue, you can look at the font's internal metrics (shown in the link above) to get the exact values you need (Browsers will be able to do this in 2-3 years automatically with `text-box-trim`). Or you could simply switch to a better font that already has the correct values.
Since there are lots of ways to do this kind of thing, pseudo selectors, attr function etc. the ability to do dynamic and complex things from CSS, or with just CSS and HTML combined is pretty big, but as a general rule if you want to do this kind of thing statefully it is probably best to do it in JS - maintaining what variable values are in play on a particular element by setting it that way.
Imagine trying to get someone to use Git without explaining the problems it's supposed to tackle. Who could come away from that conversation thinking "this is tool I must use" and not "that was confusing"?
You can see them in the specs.
You might have a variable that has the type: A|D, or maybe even A&D.
And you might have a case where a rule can interpolate values of type A, B, or C, but not D.
The @property syntax allows you to say: This variable will only ever have a type of A, so now it can be animated.