I'm not a web developer, but I've built toy websites (without frameworks) and can do basic things in a few web frameworks. I remember when CSS was "invented". After a small amount of time, I could reasonably fit all of it in my head without needing to look anything up.
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 remember when CSS was "invented". After a small amount of time, I could reasonably fit all of it in my head without needing to look anything up. 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?
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.
You aren't the only one thinking this. The surface area and possibilities with CSS amaze me as one of those web developers who had a solid understanding years ago and have returned it recently. The sentiment is a response to feeling overwhelmed and a sense of reduced competence. You can accept it and learn or rail against it. The latter often happens for a while first.
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.
Performance. JS would need to run 60 times a second without hiccups. But JS is single-threaded, therefore any time something clogs your main thread you'll skip a frame. Plus, as incredible as modern JS engines are they're still not as efficient as the native code, which leads to extra CPU usage and that spells trouble for battery life.
The way animations are done in react native for instance, is that you use JS to define the animation and send it to the native code which actually executes it.
JS should just do the same in the browser instead of relying on an arcane language not designed for this
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.
Is there a future where CSS’ expanding surface area leads to exploits and tracking? For instance, some time ago I saw an article about how font face rules can be used to fingerprint users
Honest question. Is really "animations" a thing related with styling?
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.
Needing a full feature programming language for things purely related to the page aesthetic is not a great idea.
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.
Counterpoint; anywhere but the web, using the same application programming language to define styling and visuals is normal. I get your point though, JS is still an all-or-nothing thing in most use cases.
Right, so you don't really understand the problem area and don't know the syntax, so think that something that you can't immediately understand must be a negative change.
Great feedback IMNSHO. But the key is CSS (cascading STYLE sheets)...
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.
There are still great use cases for using JS to handle animations instead of CSS, such as creating novel, dynamic images or 3D models in a canvas element (particularly when you want it to be interactive in anyway) or to animate SVGs.
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.
You said what we were all thinking. There was a lot of debate when CSS introduced these animation properties; I didn't have too strong opinions about it. But is has morphed into something rather complex...
Wow, reading this, I can _feel_ my brain resist an unfamiliar concept. I recommend people read the MDN article linked to in the first sentence before moving onto the examples in the blog.
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.
What's particularly interesting about @property is that you can associate custom rendering code. I think this website does a pretty good job showing the powers: https://houdini.how/
well technically the selectors cascade, so that when you have a selector that overrides another one the variable value you set in that selector takes precedence, the cool thing being that the variable is of course not just set for its element but also the subtree under the element.
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.
As is so often the case with articles that cause frantic head-scratching and hair pulling (my lack of which I could possibly blame on people who write CSS blogs), they didn't bother to explain the case that the shiny new thing is supposed to fix.
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"?
Same. I think this article does a terrible job at explaining it.
From the MDN article, it sounds like it's basically the same as plain old CSS variables but scoped to specific elements and/or children with some additional constraints so that it has some awareness of CSS units like angles, percentages, etc...
I probably won't be using it though. Such slight benefits don't justify added complexity and compatibility tradeoffs. I try to avoid using unnecessary new fancy syntax. I kind of stopped caring about new additions to CSS after CSS variables.
I'm sure it's very difficult and stressful to be a surgeon, but once you receive that big paycheck at the end of the week/month while sitting comfortably in your expensive home with a view, scrolling through your stock portfolio on your phone, thinking about what shares/companies you will buy next and where your next holiday will be, it can't be that hard to recover!
As someone who really enjoys working with CSS, but also working with colleagues who struggle with it, I strongly recommend Kevin Powell’s YouTube channel.
He has touched on exact feature a few times, here’s a video he uploaded a week ago that shows one useful feature that registered properties enables: https://youtu.be/U8NykwZNbGs
I'm excited about the recent work on CSS (particular Houdini). I haven't felt like this since I got a book of IE 5.5 features. Don't get me wrong -- CSS has gotten a lot of new features over the last 14 years, but they've been like basic things you kind of expect in a style framework, like new layout options or variables.
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.
Yeah. It causally allowed you to extend the CSS engine in a simplistic way, like what Houdini allows you to do. Houdini is likely way more performant though and substantially way more fleshed out.
A nice short article. If you want to dive deeper with lot more examples, quite a lot of them much simpler to get to have an idea faster, I'd like to suggest an old article from CSS-Tricks. The article is from 2021 but still very valid and well-done.
I've been out of web development for awhile, and it took me way too long to figure out what this actually does. I don't think the article does a good job describing it.
From what I gather, this new feature lets you write:
from var(--gradient-angle)
Instead of just a raw value, like:
360deg
And the former effectively gets replaced with the latter, sourcing the value from where you defined it in a `@property --gradient-angle {...}` block.
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?
The big win for me has been that this feature let's you animate css variables. A place I used it a while back was a little experiment where I tweaked youtube's design to look "neon" -- eg all the lines and stuff were bright red and glowed. I designed it so the hue of the primary colour was controlled by a single css variable. I then thought why not make this extra insane and animate the hue slowly through the spectrum so that the colour of the page is changing slowly in the background! Apparently you can't animate a css variable without @property. So it's not just letting you use a css variable instead of a raw value, it's letting you animate the css variable -- and, in turn, all the places that css variable is referenced! So with one simple `@keyframes neon-flow { from { --dc-neon-hue: 0; } to { --dc-neon-hue: 360; } }`, I animate everything -- all the primary colours, all the box shadows, etc.
`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.
CSS properties already existed before this new feature (@property). You could already for instance declare a property "--my-prop: 10px" and use it elsewhere "var(--my-prop)".
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.
Thank you. Why the article doesn't describe what @property does or how to use it is mind-boggling. It's completely obfuscated by the overly complex example.
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 =)
I really like CSS. I find it easy enough to understand. It has grown in complexity over the last 10 years, but now you can do the stuff from 10 years ago a lot more simply. And all the code from 10 years ago still works.
I’ve been testing out the (experimental) animation-timeline and scroll() functionality and it’s incredible.
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.
It is more complex, but the complexity in spec can help keep codebases simpler... a lot of the new complexity takes place of some gnarly JS and CSS hacks. Looking back at my career it's hard to believe we used to build websites entirely in tables for layout.
I think it's like this: Håkon/Bert did aim a bit high with the initial design of CSS. It was harder to understand and internalize than HTML.
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.
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.
I think it's fun to play with, and new features are always interesting to explore. But I often get the feeling that CSS features come from a place of "Hmm, what else can we come up with?". I guess there must be a forum with serious discussions somewhere, that I am missing.
Which features do you feel are unnecessary? I mostly have the opposite reaction to new CSS features “What took them so long?”
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.
Mine is still pretty minimal, but I've been making a point of using more hand-rolled CSS myself to get a clearer idea of how to work outside of tools like Bootstrap and Tailwind (which I have more direct experience with in professional settings).
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.)
> After a decade+ of web dev and through making a career of web stuff I learned how much people seem to hate CSS.
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.
I think it depends mainly on where your personal sense of curiosity sits, on the spectrum of technical and finicky problems to solve in any given project, whether you'll hate it categorically because of the variances in implementation. I'd argue more of the general hatred comes from people naively expecting visual stuff to be trivial, instead of actually harder than a lot of other software implementation details. It's evident in the UX designers (hopefully of the past) that basically brought zero technical skills to the table and had no knowledge of even why mobile-first responsive design was more than just a marginally ideal approach.
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.
Same. I thought it was neat (though a bit ridiculous) that the codepen examples are doable just with CSS, but if I saw the first call to action button on a website, I'd think it was tacky and cringey.
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.
These are things people are already doing in native app code, so we've got to have some web equivalents or everyone's going to be doing everything in walled gardens.
I agree, God forbid a native do something better than a web app. Let's make web dev even more complicated, I was just saying how simple it is currently
Readit News
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.
JS should just do the same in the browser instead of relying on an arcane language not designed for this
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.
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.
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.
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
Deleted Comment
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"?
Deleted Comment
From the MDN article, it sounds like it's basically the same as plain old CSS variables but scoped to specific elements and/or children with some additional constraints so that it has some awareness of CSS units like angles, percentages, etc...
I probably won't be using it though. Such slight benefits don't justify added complexity and compatibility tradeoffs. I try to avoid using unnecessary new fancy syntax. I kind of stopped caring about new additions to CSS after CSS variables.
I'm sure it's very difficult and stressful to be a surgeon, but once you receive that big paycheck at the end of the week/month while sitting comfortably in your expensive home with a view, scrolling through your stock portfolio on your phone, thinking about what shares/companies you will buy next and where your next holiday will be, it can't be that hard to recover!
Ha, thought it was just me.
This strikes me as very strange. I'm not sure what the benefits are over just using CSS transforms.
He has touched on exact feature a few times, here’s a video he uploaded a week ago that shows one useful feature that registered properties enables: https://youtu.be/U8NykwZNbGs
There’s also this article that breaks down registered properties with an easy-to-follow example: https://moderncss.dev/providing-type-definitions-for-css-wit...
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
https://css-tricks.com/exploring-property-and-its-animating-...
You will particularly like the Airport number/timer flip display type example.
From what I gather, this new feature lets you write:
Instead of just a raw value, like: And the former effectively gets replaced with the latter, sourcing the value from where you defined it in a `@property --gradient-angle {...}` block.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?
`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 :)
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.
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.
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.
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.)
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.
Really hope this aesthetic doesn't catch on.
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.