hckrnws
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.
It's like designers are the very first corner to cut. Or the dev is expected to also be a designer. It's a very different skill set. I'll build your mock-ups, or copy the look and feel of something else, but I can't design my way out of a paper bag. My brain just doesn't seem to work that way.
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
JS animation libraries let you declaratively define and hook into CSS animations.
"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
Good news! You can with the Web Animations API.
Just recently I had to code a little but complex animation and I ended up using the web animations API. It's nice, it was a lot less code than the css counterpart.
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.
Which are CSS animations underneath
Yes, but you define them with Javascript rather than in CSS which is a key difference since the syntax is more intuitive for some (myself included)
So since the original comment was questioning the necessity of animations in CSS, and JS is essentially using CSS animations for many things, I'd say the answer is yes. It's also a great way for UI designers to use subtle movement to hint at actions/status/next steps/etc without having to execute any JavaScript. When you've got a purely visual task, I'd say involving a general purpose programming tool is the unnecessary part— like using sed or the like vs opening up a repl in Python or whatever.
No - CSS and JavaScript are two ways of defining the same thing, an animation. Safari runs its accelerated animations with CoreAnimation - is CoreAnimation a CSS animation?
Shhh, don't tell him that.
Whether a language is arcane or not depends on the levels of comfort one is familiar with the language, or how approximately familiar someone is with similar languages.
It explicitly is designed for this, what are you talking about
Also just moving problems to the graphics card. The common rotate, transform, and so on, are all classic graphics hardware tasks.
You still need the CPU to tell the GPU what to do
Right, so you have simple statically defined optimized routines written in c/c++ calling the GPU, like any high performance graphics engine.
> Can't this be done with Javascript?
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
Yes and yes. You’ve already pointed out fingerprinting, but there are other attacks that can be done.
See:
- CSS keylogger, 2018: https://github.com/maxchehab/CSS-Keylogging
- OWASP cites CSS injection as a mechanism for XSS and data exfiltration: https://owasp.org/www-project-web-security-testing-guide/sta...
Luckily we haven’t seen new classes of attacks here, but being concerned about attack surface of any browser technology is valid and reasonable.
https://developer.mozilla.org/en-US/docs/Web/CSS/Privacy_and...
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.
More than half of the examples you listed only partially use CSS as part of the exploit chain and could be done without CSS at all. For instance, you can certainly flash the screen but CSS is never going to be able to, on its own, read and exfiltrate the data necessary. You're relying on things like access logs at that point.
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.
uBlock, I exfiltrate: exploiting ad blockers with CSS
https://portswigger.net/research/ublock-i-exfiltrate-exploit...
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.
At least in terms of animations being superfluous, there's an accessibility setting to reduce animations that at least built in browser CSS animations can reliably respect, whereas with hand-coded Javascript animations, you're relying on each individual author to write code to respect that setting.
I hope someone chimes in to correct me if this is wrong, but AFAIK CSS animations are not automatically disabled by toggling such a setting.
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.
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.
Reminds me of the rust into linux debacl3
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.
What you will be animating are styles. The programmatic aspects of animation are fairly straightforward. It just makes sense for it to be in CSS no?
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.
welcome to modern web dev in a nutshell
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...
No, it's not what we all are thinking.
Moving work from JS to the browser’s native, polished, tested implementation with optimized performance is the right thing to do.
> Moving work from JS to the browser’s native, polished, tested implementation with optimized performance is the right thing to do.
Of course, not disagreeing with that. It is just done in a way that is complex and cumbersome IMO. CSS is often handled by people with very little programming experience as well. I have worked for companies which gave me HTML templates, and CSS files, and my job as the developer was basically do add dynamic behavior by fetching stuff from their DB and looping over some data here and there to fill out lists/tables with actual content. To me that was very pleasant; but the guy handing me the CSS and HTML templates, had zero programming experience.
I think webdesign already is a copy-n-paste bonanza, where people find something they like, and copy it; if it gets very complicated as well. Developers are often last resort in terms of finding out why something does not work, and I fear complicated CSS after a few rounds of copy-n-paste is going painful to unwrap.
Your comment is quite unfair to the author, who explained every part of the complicated CSS ruleset. It's not a copy-paste, for sure.
I think you misunderstood. Never meant the author of the article copy-n-pasted anything. Not the commenter that I "commented" on either. CSS had grown into something a bit too complex for its own good.
kelnos> This seems like a bit much. More than a bit much.
I just said that web-design, either done by programmers with zero design experience, or by designers with zero programming experience lends itself towards copy-n-paste (from different resources online). I.e. many people copy-n-paste stuff they don't really know much about in order to make their website look decent. If the underlying technology is complex and difficult to understand, this can lead to an unholy mess that (most likely) developers will have to unwrap.
It does add another hurdle for Servo and Ladybird, probably intentionally.
Are you seriously suggesting that the primary motivation for this feature to be added to CSS is to make life harder for new browser engines?
The thought had crossed my mind, yes. Do you think Google does anything from the kindness of their hearts, without considering Chrome's position? It's one of their most valuable assets.
It's needlessly conspiratorial to ascribe intention here, especially when the Servo community have already expressed interest in supporting upcoming (difficult!) standards like CSSOM
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.
After reading through the mdn article I'm hopelessly confused.
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?
I think of them as effectively CSS variables with types and that can be animated.
By default CSS variables can't be animated since it has no idea what unit it's animating between
Critically, CSS custom properties are not evaluated by default until you use them. They're more akin to preprocessor substitution. Yes, this does mean that:
calc(var(--foo) * 2)
calc((var(--foo)) * 2)
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/
I have no idea how naive this question is... but here goes.
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?
Imo, those are security reasons to disable JS. The main privacy reason (again, imo) to disable JS is simply that JS can just send each and every one of your inputs to the server.
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.)
Well, exfiltration via CSS is possible already: https://infosecwriteups.com/exfiltration-via-css-injection-4...
I don't see these new CSS features opening up privacy issues, though.
I've disabled CSS too (via uBlock), it's amazing how many sites break because of it (less than the reliance on JS though). Still, the experience is generally still better enough times that I've left it as the default.
It depends on the use case. JS makes browser fingerprinting a lot more accurate. If you're using a VPN, I believe JS can leak your real IP, but I'm not positive about that. There's also a big chunk of zero-day attack surface that's gone. Obviously they can't do in-browser bidding scripts for ad space or whatever. Personally I always keep it on, but for some use cases or levels of privacy paranoia, it makes sense.
What's absolutely amazing about that is how far people go to do everything in pure CSS, without Javascript, that they put Javascript inside their CSS.
CSS is becoming ever more like a programming language. But you cannot debug it. So why not use a programming language instead where you can do that, and can do pretty much anything you want.
CSS is absolutely debuggable, every browser has dev tools just for this very thing.
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.
Good points about declarative languages. I use CSS all the time. Have to. It is the best tool for the job. But I don't find the browsers' CSS dev-tools very useful. Maybe I'm not just using them right.
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.
The off-by-x-pixels problem usually only happens when you take the unwise path somewhere.
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.
Yes the CSS debugging tooling that comes with every major browser is incredibly useful.
Because the browser can more effectively GPU accelerate CSS animations, which seems to be the main driver for features like this.
Comment was deleted :(
Comment was deleted :(
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"?
Comment was deleted :(
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!
> Wow, reading this, I can _feel_ my brain resist an unfamiliar concept.
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.
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
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...
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.
Unclear to me wether you are using the term "unhinged" in a positive or negative way
Lol i mean in a good way. I like a little unhinged sometimes
Lol that’s how css3pie (http://css3pie.com/) worked, right?
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.
https://css-tricks.com/exploring-property-and-its-animating-...
You will particularly like the Airport number/timer flip display type example.
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)
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?
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.
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 :)
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.
This website makes me happy.
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.
people seem to hate CSS.
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.
I find the animations make everything look like an 00's display ad. In a bad way.
Really hope this aesthetic doesn't catch on.
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.
I thought at first that codepen trying to upsell me.
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
how you personally feel about it is irrelevant, I would personally prefer the web to stay simple too
but this isn't realistic — the places most people spend their time online are in native apps, if the web doesn't at least pretend to keep pace this will only get worse
The web doesn't need to be anything more than a document delivery program. You thinking it needs to be an app delivery system is a deep error in judgement
the web right now is more than a document delivery program... the genie is out of the bottle
this is like saying usenet is all the social media we need... it might be aspirational, and it might be right, but it's not reality
people seem to forget that computers exist, and these things call programs exist, that can execute on computers, even if a browser is not even installed on the computer
indeed, but again this does not track with the way things are currently working
Obviously you don't know what a VPS is
PFM... Pure f*cking magic is definitely how I feel about some of the things that can be done with CSS animations. Unfortunately, it seems so specifically tuned to CSS and CSS alone that it's hard to learn and conceptualize than doing things via JS programmatically. I just don't think in those terms. I have enough trouble with all the options for css flex usage.
It really is a whole alien domain to itself. The syntax being so foreign to most developers doesn't help. But it's so powerful, incredibly powerful, and in most browsers, extremely efficient.
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.
> That is because CSS is a different Chomsky Grammar than HTML and EMCA - intentionally not Turing complete, nor-self referential - why the "has(" puedo property was so problematic.
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.
> That is because CSS is a different Chomsky Grammar than HTML and EMCA - intentionally not Turing complete
CSS has been Turing complete for many years.
You can simulate Turing machines with pure HTML+CSS, e.g. https://github.com/yrd/tm2css
"Rule 110" which implies Turing-completeness has also been implemented in CSS, e.g. http://eli.fox-epste.in/rule110/
CSS has been very, very, very close.
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.
You could just call it syntax, you know.
Everyone reading this speaks multiple computer languages, and knows what a "syntax" is.
The disambiguation between levels (grammars) of syntax is what the above poster was both lamenting and heralding - possibly unaware of it's technical and mathematical necessity.
https://en.wikipedia.org/wiki/Ambiguous_grammar#Trivial_lang...
It's a declarative paradigm like that of SQL. From a purely imperative perspective, either does take some time with the spec and some experimentation to grasp as a paradigm, but it's a way of thinking worth the study for more than just being able to use SQL and CSS. (Which are not without worth in their own right!)
This is why I hired a designer who knows how to code HTML + CSS (but not much else). I can throw some un-styled elements on a page that are hooked up to the business logic, and the designer can style them however they want. We can iterate on polishing the UI later if needed.
This is the way. I still love to work like this.
JS is always, always my last resort. The amount of JS I've stripped out of code in the last few years as CSS features have arrived in most browsers. I love getting a page to "JavaScript Zero".
If they could just decide on the name[1] for the CSS "masonry" feature so we could finally have that without scripting, I'd be very happy.
In this particular case property is part of the CSS Houdini APIs which allows you to manipulate CSS from JavaScript in a much more powerful way than before. https://developer.mozilla.org/en-US/docs/Web/API/Houdini_API...
The author has an enthusiasm for a new piece of CSS that I haven't seen in a solid decade. I appreciate it a lot. In my 20s I would have tinkered with the possibilities of this thing for hours/days. Trying to get stuff to work in CSS brought me joy. Now it's kind of easy, thanks to flexbox, grid, and the fact that most websites and apps follow standard design principles. We've "solved" web UI, for the most part.
What are these standard design principals?
I guess a better way to say what I meant is "common design language." Things that become components in some component library.
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)
What are these standard design principals?
Copy what the next-bigger tech company is doing, and call it "best practices."
What we solved? Layout? Still need to go back a re read some shady aspects of flex and grid. Sticky positioning is one of the most useful features ever; yet if for any any reason doesn’t work it’s very hard or almost impossible to debug and understand why(does any parent up the tree have any overflow?), and good luck finding any good documentation explaining corner cases. Without dev tools and a lot of wasted clicks it’s impossible to debug css from source code alone, you have to inspect that element at runtime. Most native inputs still have very limited styling capabilities(please don’t tell me it’s a good thing), we waited years for native modals and popovers. Last time I checked can’t still animate from display none to block with height. I can go on for days, my point is how did we become so accustomed to all the problems css have and lost any bit of criticism?
We can now transition to height auto: https://css-tricks.com/transitioning-to-auto-height/
Just remember that because you can doesn't mean you should. When super bright blue LEDs came out every damn piece of hardware had them just to show their product is new but it didn't add any value to the user.
What? Blue LEDs were much cooler! I even modified hardware to swap out green/red for blue (c1997) cause they were so awesome. I have to put a small V-drop cause they were so bright.
This demo reminded me of 2001-2002 when I was hanging out on forums about Macromedia Flash: people were making crazy demos with a mix of hand-drawn shapes, animations and ActionScript.
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.
Hand-written HTML+CSS+JS can scale, but cool-react-demo.dev is more impressive for all sorts of reasons. You also can't blame people for chasing the skills that get you hired.
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.
New Tailwind classes "look-good-mobile md:look-good" /s
The prior submissions from this domain never got traction but smooth them are also pretty interesting and educational:
The average Tailwind user can't comprehend this.
Dont fret, there will be a 192 character long tailwind classname specifically for this.
I’ve been doing web stuff since 2003. But tailwind is nice and has its benefits.
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.
styled-components is css, don't lump it together with tailwind
A candidate interviewed and did not know what a CSS selector was. This was due to their exclusive experience with styled components.
that sounds like a made up story
As an avg tailwindcss user, and lover, I concur.
While the demo is interesting from a technical standpoint, please don't make buttons animate like this. It seems like everyone is adding nasty purple gradient borders to everything and now they want to animate it. Just because you can do this doesn't mean you should! I'm getting tired of writing custom CSS to remove distracting styles like this from websites.
It feels like "blink" all over again, although much prettier. I'll probably feel differently about that last part really soon.
What developers _should_ be doing is disabling such animations if `prefer-reduced-motion` is set in your browser. This way, both people who have trouble seeing stuff when there's too many complex color animations as well as people who "just don't want to deal with all that mess" can specify what they want to see, and the code can change based on their preferences.
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.
It's Flash all over again.
The problem with Flash -- as I remember it -- wasn't the animation so much as how the Flash embed 1) required a plugin, 2) didn't interact as one would expect of a web page (e.g. right click), 3) was slow to load, 4) and didn't play nicely with the surrounding DOM.
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.
Fancy CSS effects are slow to run, they use lots of CPU time just like Flash animations used to.
When I switch from this HN tab to the article page, Firefox's CPU usage goes from 2% to 26%.
Everyone making so much a menace about the 90's coming back. Please let it happen man! it can't be too much worse than this!
My take is the opposite. Please do it, let's stop everybody conform to the same aesthetics, the same button, the same effect.
Please do whatever you feel like doing. If you like the aesthetic and it fits the overall design, why not? Don’t let some HN commenter tell you what you can’t do.
What if I need to draw customer’s attention to something? These things do have use cases just like real world neon signs.
Comparing these animated buttons to distracting light pollution is pretty apt.
Drive around some of Vegas and say that all the old incandescent lights and neon are just pollution. Some of it, designed just for eyeballs and profit, actually ends up being beautiful.
Hire a designer and select an attention-getting color? Use a unique shape which is different than the regular visual flow on the page?
The internet is a cesspool of ad-plastered pulsating garbage. Please don’t litter more on the garbage pile.
There are plenty of better ways to draw a user’s attention to something. Any half decent designer should be able to do it without this kind of noise. And there are people like me that will close the tab before interacting with the page, so you’ll lose some people with this approach.
It depends on the concrete case and why drawing their attention is important, but flashy animation is never the answer, unless it's to indicate an imminent life-threatening danger, or unless your app is a game.
Some people don't like neon signs. As a business owner, you're free to ignore them.
Use a 'new' gif that is animated like in the 2000's =D
Comment was deleted :(
At some point, it will be nice to have an "Information Experience Palette" that is in your locked .env.pii.llm personal AI firewall, gateway. All of your digital DNA is held, managed, protected, and preferred by you, in your own, Sound Voice.
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.
Comment was deleted :(
I'm so glad I work backend...
Is there any software that can generate CSS visually by combining nodes in a graph, akin to shader graphs in game engines? (https://unity-connect-prd.storage.googleapis.com/20200902/le...). It'd be so useful for stuff like this.
From https://www.w3.org/Style/CSS/
> Cascading Style Sheets (CSS) is a simple mechanism for adding style (e.g., fonts, colors, spacing) to Web documents.
I think somewhere "simple" got lost unfortunately.
At some point it seems like folks working on CSS have a “we need to be paid so let’s add more features”.
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?
Is it wrong my first thought of this is that it's too complex for me, but I'll tell ChatGPT what I want and it can generate the effect I want with the @property stuff I don't understand.
This must be the mentality of new CS students.
This seems like a bad path to go down. Even if ChatGPT were a perfect developer, being able to understand code would be important because communicating specs is hard
This seems like we will need some wrapper libraries around this. It's super cool, but also super complex, and I am not sure you want all this complexity in your codebase.
It remind me times when I participate in development of VRML Engine. VRML can include JavaScript, but it has timers & interpolations of almost anything (coordinates, texture coordinates, any properties of transformation like angle or axe of rotation, scale, etc) without using scripts. And even can process input events without scripts! It is possible to create simple 3D game without any "real programming" in VRML.
as somebody who spent many years writing "regular" css, this is magic
i wonder if we start to see the "css engineer" job posts sooner or later
It me. I write CSS. I also write javascript, html, vue code, react…
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.
We just call that "front end engineering"
Wait, so `@property` isn't scoped by anything else other than the variable name itself right? That means an explicit single global scope for variable names, which is not a new thing but never affected the actual usage until now. I can easily imagine a future where variable names are mangled just like class names...
Here's a @property-based complex animation that I made recently https://indutny.github.io/on-call-rotation/#sindresorhus,jam...
Comment was deleted :(
I saw the demo CSS and remembered why I stay away from frontend development. So much for so little
CSS - a language invented to make styling webpages more accessible than regular code!
As an aside, modern CSS would be useful in a non-web configuration language role too, but almost nobody seriously considers it --- instead preferring the usual ad-hoc mix of JSON, YAML, and TOML.
It is a crapload of CSS for a single button, that's for sure. But today we learned some new things. Thanks for the article.
At this point we really need a CSS blocker because it's going to be used to plaster ads and annoyances all over websites that used to require javascript and were easily solved by blocking JS by default. CSS is becoming so complex that it'll be as much of a security risk as JS.
Preferably a blocker that allows a sane subset of CSS so that normal formatting isn't impacted.
How do we unit test such code in CSS?
You don't unit test CSS.
You E2E test it, and you visual regression test it.
Comment was deleted :(
Comment was deleted :(
Comment was deleted :(
Comment was deleted :(
What the hell, CSS has types now?
Always has.
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.
Comment was deleted :(
Just so everyone understands what this is... they've added typed variables to CSS that can be passed down to children, so CSS is just converging even more to SCSS and friends. The button is flashy, but not really relevant.
TLDR: you didn't actually need @property to do any of this magic.
You need @property for the interpolations between values for the animations
Isn't that what @keyframes is for?
@keyframes specifies what the values should be at specific moments in a timeline, but not what values they can be between those moments.
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.
Neat! Okay, wake me up when we have native CSS mixins.
[flagged]
[flagged]
Crafted by Rajat
Source Code