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.

With web development, I've always thought that there is an element missing for many devs: design acumen and appreciation (I need better terms.) Just look at the site linked from this post and you see an attractive personal site. Most devs struggle with these aesthetic elements.

Desktop development is fairly constrained. As an example, devs can make good or bad decisions around use of the toolkit, but it's less of an open canvas than the web. A lot of the expanded scope of CSS can be more easily exploited if you appreciate the design aspects or have designers creating some target design for you. Putting these capabilities in front of devs without those elements doesn't lead to much success which is another factor driving sentiment.

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.

They try to sandbox it.

There are more clever ways now. Like... everything you interact with is a binary search into a projection of your (2^n-interaction) "guess"-ed/history.

If you interact with it, then it is assumed that you can see it.

Even detecting if the room is generally lit or not via the Ambient Light API can be paired with bright and dark elements to ping flashes off your face, in a dark room, to read whether or not elements were of that certain color.

But lets scrap :Visited and use arcane browser implementations and user behaviors; even something as innocuous as zooming slightly in or out is a session-persistent signal. The browsers explicit and even _inferred_ zoom level can be leveraged. A few irrational numbers and difference in spec implementations and your zoom level on Compromised_Site_A can identify you exactly from Compromised_Site_B even without Javascript.

But let's reset zoom between domains. Easy? sure.

But something still has to get painted to the page, like images, that could be cached....depending on how long they have been visited, and from what domain, and from what order. And the timing between all those are almost certainly unique to few, and sensitive to all.

If you load a thumbnail from Bad_site_a within 100ms in a country that blocked the original resource....thats a paddlin.

Those are just the first few, I could go on.

  CSS is never going to be able to, on its own, read and exfiltrate the data necessary.

https://blog.sheddow.xyz/css-timing-attack/

  You're relying on things like access logs at that point.

IMHO, I see all those bells & whistles more related to scripting than to styling. I'd prefer to be able to navigate with Javascript disabled and not having to suffer some superfluous animations, but maintain the styles.

Original idea puts it under the authors control to add @prefers-reduced-motion media queries.

Might be that some browsers do this anyway, otherwise it would be easy with a user script or user style sheet.

This article argues for the spirit of the spec:

https://css-tricks.com/nuking-motion-with-prefers-reduced-mo...

> “animation isn’t unnecessary.”

It has a point, intrusive animation's main bastions are not CSS-based anyway.

For example, there seems to be a continuous (JS- and HTML-based) cat-and-mouse game that makes me require an ad blocker to disable autoplay videos on news sites, regardless of browser preferences.

This part is like the DNT header all over again, incentives don't align.

And the lesson should be that CSS is the most benign battle site for this issue, because it is customizable and not yet locked down behind anti-debugging and obfuscation techniques.

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.

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.

JS should just do the same in the browser instead of relying on an arcane language not designed for this

"Arcane language" not only is CSS one of the core languages of the web, but also if you find this arcane I wonder what you think of the "native" code that react native is generating for the animations.

CSS as an animation engine is completely acceptable, and it's limitations (like the one in TFA) are slowly being pushed back.

  >"Arcane language" 
  >"native" code that react native is generating for the animations.
  >CSS as an animation engine is completely acceptable, and it's limitation
  >TFA

But, if I* have to write this same animation in two years and @property is widely available, I'll reach up for that first.

*To be honest, it will be 100% an LLM that writes it for me.

Moving work from JS to the browser’s native, polished, tested implementation with optimized performance is the right thing to do.

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

   calc(var(--foo) * 2)

   calc((var(--foo)) * 2)

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

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.

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

But IE devs were unhinged. You could build JS code as a module and attach it to elements using CSS.

Finally we're getting those kind of unhinged features again.

e.g. https://developer.chrome.com/docs/css-ui/houdini

From what I gather, this new feature lets you write:

    from var(--gradient-angle)

    360deg

Plus there's the `inherits: false;` bit. I'm not sure what to make of that. What it does is clear enough but I don't understand why. CSS selectors already let you control inheritance. Now you can control it from a second place? I don't follow...

Also, why do I have to define the type in the @property block? I don't have to define types anywhere else in CSS. The browser can see where the @property is used, why can't it infer the type from that?

This new feature, @property, allows you to define your property ahead of time, what "type" (syntax) it should accept (percentage, angle, color, etc), whether or not the property should inherits values from parents, and give it a default value (initial-value).

This means that if a property is declared as an angle type, and an element says "--my-prop: 5px" it will be ignored. Previously, this would be valid and depending on where you used it it might have unintentional side effects. It also means you can specify something like "--my-prop: initial" and it will use the default value (initial-value), without needing to know what it is exactly.

`inherits: false` lets you control how the property is inherited. For example, in normal css, the property `color: red` is inherited. If you set it on a div, all elements in the div will have `color:red` unless they specifically override it. But, say the property `display: flex` does not behave this way. If I set it on the div, only the div becomes display flex. This is exposing the ability to control how your custom property is inherited -- like `color` (`inherits: true`) or like `display` (`inherits: false`).

I believe the type is there so that it can at static time know what to animate. Since a css variable can be anything, unlike a css property. E.g. `from { color: red } to {color: blue}` it knows the types because of the properties. With css variables, it needs to be told what the types are.

Added fun fact: the type syntax is actually the same syntax you'll see on like mdn! https://developer.mozilla.org/en-US/docs/Web/CSS/color#forma... . So it's like exposing the internals of CSS as an API any developer can use :)

I've always loved noodling with CSS. After a decade+ of web dev and through making a career of web stuff I learned how much people seem to hate CSS.

I can pour countless hours into exploring and tinkering with hand rolled HTML+CSS. Deploying it just to see how it feels for real on my phone. And 99% of it all never going anywhere.

I guess for most people that's called a waste of time. Well this site sure does make my day =)

It’s great to see new features coming to html/css that reduce or eliminate the need for JavaScript.

The more that can be done with declarative interfaces with the browser assuming the optimization and complexity instead of hand coding in JavaScript, the better.

This hindered adoption.

Then over the years the overall complexity of the web stack (and its' Javascript-based "derivatives") grew, and suddenly CSS is no longer so complex - in comparison.

CSS is so much better than it used to be. Many people will remember positioning things with float and display: table-cell. Every time I use modern CSS I’m like a kid in a candy store.

Coming from also writing frontends pretty much entirely with JSX (in prod, especially), my understanding of the query logic has generally improved by a lot ever since I happened into a separate rabbit hole on Web scraping.

My related hot take is that the query logic wouldn't be nearly as much of a pain if professional settings used semantic elements more. (Never mind how much bare HTML has defined behaviors you don't then have to maintain, like modals.)

The people who are vocal about hating CSS are mostly just people who don't understand CSS.

That's perfectly OK. I don't understand APEX, or AP/L, or the framework-of-the-day. But I do understand CSS, and because of that I enjoy it quite a bit.

For some people it clicks, and for other people it doesn't.

The rub comes when someone for whom CSS doesn't click is required by their job to do things in CSS. Naturally, they hate it. I'd hate it if my job made me maintain an Active Directory installation. Not my thing. But CSS isn't inherently bad.

Yeah because as soon as you're not tinkering with only your particular combination of device/screen/browser/browser version/OS/OS version but have to implement something reasonably widely supported all the subtle "we're not following the specs" get really annoying to deal with.

Microsoft used to be the most notorious specs violator, today it's Apple.

Apply some deadline pressure, and the constraints of an existing complex frontend project, and all of a sudden the estimate you pulled out of your ass for a pixel-perfect design doesn't look so achievable; ergo, CSS sucks for some people.

These sorts of things scream marketing and manipulation. Let me read your site and decide what I want to do. Don't try to distract me by annoyingly drawing my attention to the thing that will make you money.

The extremely vast majority of web app developers don't need 99% of what CSS can offer. But it's neat to know it's there.

  whole alien domain
  so foreign to most developers
  doesn't help.
  it's so powerful, incredibly powerful,
  most browsers, extremely efficient.

That also relates to sibling comments about the awkwardness of the pairing to Javscript, which is of a higher grammar, and Turing Complete*.

It also relates to the "awesomeness" of the "fire-and-forget" nature of CSS - unless very specifically hooked, it can be hardware-accelerated nearly care-free because it isn't per frame to the DOM, which Javascript is (meaning HTML, it's own Chomsky Grammar!)

It is what it is, the epitome of an optimized amalgamation of technical debt we call the modern web specification.

I would had had, had - "has" not been had, expected sooner, but atlas.

But the aforementioned ":has": : The :has() pseudo-class cannot be nested within another :has(). This is because many pseudo-elements exist conditionally based on the styling of their ancestors and allowing these to be queried by :has() can introduce cyclic querying.

  Pseudo-elements are also not valid selectors within :has() and pseudo-elements are not valid anchors for :has().

The former is required for a basic computational model, the latter for one that supports recursive-ness and thus some optimizations .

  "Rule 110"

You'd think someone woulda parasol'd the checkboxes and at least attempted to use :onHover with grid to require minimal mouse movement to trigger input instead.

Or, a bounding box input state driven hack - like when your cursor is "in between" elements, changing every frame.

  pure HTML+CSS, e.g. https://github.com/yrd/tm2css

But it can't: https://www.w3.org/TR/css-variables/#cycles

  This can create cyclic dependencies where a custom property uses a var() referring to itself, or two or more custom properties each attempt to refer to each other....If there is a cycle in the dependency graph, all the custom properties in the cycle are invalid at computed-value time.

It will be a nitpicky comment, and I’m sure you mean it this way, but it wasn’t clear to me: a language’s syntax being in one type of grammar class is irrelevant to its execution semantics corresponding to a recognizing automaton. So you can have a language with a regular syntax that is Turing complete just fine.

In fact, most languages’ syntaxes are context-free (sometimes with some escape hatches), but are semantically Turing-complete.

  nitpicky comment,

I was unclear. It is intentionally not Turing Complete, by way of avoiding self-references, as self-references would make it a higher-order grammar, and Turing-complete because it then it can innately loop, making it impossible to flatten to a lower, Labeled Push down automaton.

Although they are mutually exclusive, I implied causality.

Its the implicit loop and requirement of a heap/stack of variables self-referencing requires that is Turing-Complete itself.

They aren't written down, set in stone, spec'd in any way, but for example:

* the idea of a hero image with a headline and a sub headline followed by a call to action is common on many SaaS product websites. * news websites all look very coherent, so they've adopted some sort of typographical rhythm just like they would in a print publication * the multitude of component libraries means advanced UI can be programmed with some readymade parts, diminishing the need to write custom CSS for something like an image carousel (for a trivial example)

That said, I’m always shocked when I’m interviewing a front-end candidate and they don’t know CSS. Too many rookies out there that haven’t used anything outside of styled components and tailwind.

Unfortunately, I believe for "custom jobs" like this you'd need to explicitly state that you don't want it to occur because it won't happen by default, unlike some other stuff that's more standard in the browser.

I don't think this is the case here. For a CTA button (literally "Call to Action"), I think it's perfectly acceptable to add an animation to it.

When I switch from this HN tab to the article page, Firefox's CPU usage goes from 2% to 26%.

The internet is a cesspool of ad-plastered pulsating garbage. Please don’t litter more on the garbage pile.

So ultimately, you apply the view to the page and the page conforms to your ingestion preference.

I should carry my own 'css' and be able to just pluck any URL and let me speak to my filter on how to display it.

And it will provide a new way to interact with my browsing history - allowing me to recall how that thing from HN from 3 months ago can tie into this thing, and augment my understanding when I can view them next to eachother... and I can categorize them into tags of the same ilk and have a mental rolodex that lets me re-view my browsing history in the UX lens of my choosing.

/edible.

This must be the mentality of new CS students.

We just haven't needed a lot of pure CSS in the modern era. A lot is abstracted away in frameworks where you can simply set variables to customize the look and feel.

All websites also kind of look the same now, which isn't the worst thing, but it definitely means less need to mess with CSS.

What you can do in modern HTML+CSS+JS is incredible. Too bad people bury it down under millions of layers of frameworks and code transformers.

Lots of factors got us into this framework and transformer hellscape, and the 'people' that made is happen are right here. I'm not without some blame within my own organization for sure.

Seems pretty gibberish. Theres already CSS vars and a bazillion less/sass/css-in-js preprocessors.

Who really needs this? Why make the spec so complex?

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.

TLDR: you didn't actually need @property to do any of this magic.

Certain types are continuous between two values which allow them to be smoothly interpolated in an animation. For example, an animation from 10px to 20px would be 15px in the middle.

Certain types are discrete, so they cannot be smoothly interpolated. For example: flex to grid. There's no half flex half grid value. An animation would just hard switch to the other value.

Variables can be assigned continuous typed values, discrete typed values, or values that can be continuous or discrete.

If you're animating over a value where you don't know if the animation is continuous or discrete, you have to treat it as discrete to avoid nonsense values.

This is why @property at-rule exists. It allows you to specify "this variable" is of a continuous type, and it can not be overridden by a discrete type in the future, which among other things, allows a variable to be animated smoothly when it otherwise couldn't be without the chance of encountering a nonsense value.