Popover, dialog, invoker commands, our entire production app uses these everywhere and it works really well! The fact that dialogs and popovers are rendered on the "top layer" and that nested popovers are also automatically stacked on top of each other and have 'cascading close' shows how well these standards were designed.
The only hard thing is still to position a popover near the element that triggers it, such as when you want to create a context menu that has to render above/below the button that triggered it. There is anchor positioning in CSS now but support is still limited and I find it hard to wrap my head around.
LLMs are also terrible at these new standards. If they even know about them, they often think they're not baseline yet and they have almost zero training data compared to the giant mountain of weird JS and CSS that people had to use before the introduction of these standards.
I'm curious how many people are involved in the design of your app and what their concerns are.
Testing for accessibility and on mobile devices has a tendency to derail the best intentions. What tools are you using for those concerns? I'm not asking because I need advice. I'm asking because I want to know what you or your team did.
It's a small team of four, everyone works on the "full stack" which is Rails with HTMX and very little JS. As the lead dev, I am usually the one to make the decision that we should use the modern browser standards.
It's a niche B2B SaaS app and luckily we know most of our users personally. They all use modern browsers, usually Chrome or Edge on Windows. There is not a lot of mobile usage although we do support it.
> The only hard thing is still to position a popover near the element that triggers it, such as when you want to create a context menu that has to render above/below the button that triggered it. There is anchor positioning in CSS now but support is still limited and I find it hard to wrap my head around.
I was going to suggest anchor positioning. I found it difficult to wrap my head around too, but once it clicks it's pretty simple. As a bonus, you can use it to position many other things than just popovers.
Baseline newly available. For Germany that means 80% vs the usual 90% (I wonder how the Internet looks for those 10% who use ie, Firefox 20 and Chrome 1 or whatever), which, considering that it doesn't really degrade well, makes it pretty much unusable for serious sites.
Thanks for giving me some confidence, I converted one of our popovers to use anchor positioning and it was actually rather easy. Just had to use anchor-scope which not all tutorials use!
[−]commandlinefan · 2026-08-20 Thu 20:32 UTC ·
link
> often think they're not baseline yet
I'm not an LLM, but that was my immediate thought - how new does a browser have to be to support these and which browsers am I excluding by using these features?
> The only hard thing is still to position a popover near the element that triggers it, such as when you want to create a context menu that has to render above/below the button that triggered it.
If you put something like this in your popover class, it will resolve to the button that called it when position-anchor is not set:
top: anchor(bottom);
I'm not sure how widely supported it is but I've been using it in Firefox/Chrome.
All current browsers support anchor positioning including popover buttons being the implicit anchor. However, the anchor positioning polyfill does not support this, it requires an explicit anchor-name.
> LLMs are also terrible at these new standards. If they even know about them, they often think they're not baseline yet and they have almost zero training data compared to the giant mountain of weird JS and CSS that people had to use before the introduction of these standards.
I really wonder if AI coding is just going to lock us into 2024-ish era languages and libraries forever.
[−]actionfromafar · 2026-08-20 Thu 22:17 UTC ·
link
At least one thing to hold the torrent of churn back just a little. Silver linings..
Can we stop calling them skills? They're mostly just documents like any other. Call them cheat-sheets or guides.
Wrapping an .md file in all this circus, with lingo carefully designed to hide the fact that under the hood you're really just dumping another text file into the LLM's context , helps nobody but people's AI psychosis.
But I guess "my LLM can use skills" sounds a lot cooler than "my LLM can read text files", so we'd rather keep pretending really hard.
The top-layer + cascading-close behavior is exactly why we finally dropped a bunch of custom overlay managers.
On positioning: we got farther with CSS anchor positioning once we stopped treating it like absolute offsets and started from "this is the preferred edge, then let the browser flip." Still awkward for nested context menus, but far less brittle than measuring getBoundingClientRect in a resize observer.
This seems like a common enough issue that it would be worthwhile publishing a "Markdown library" of "stuff HTML can do" that you can "call" from your AGENTS.md.
(They made it a skill, which brings me to another thing I've had on my mind lately: that's annoying if you know when you start the harness that you will want it to read the skill. It's a roundtrip through the model to activate it. But maybe there's a way to fix that?)
(Edit2: Claude says if you activate the skill via /skill-name in the initial prompt, you get what I want)
The only hard thing is still to position a popover near the element that triggers it, such as when you want to create a context menu that has to render above/below the button that triggered it. There is anchor positioning in CSS now but support is still limited and I find it hard to wrap my head around.
LLMs are also terrible at these new standards. If they even know about them, they often think they're not baseline yet and they have almost zero training data compared to the giant mountain of weird JS and CSS that people had to use before the introduction of these standards.
Testing for accessibility and on mobile devices has a tendency to derail the best intentions. What tools are you using for those concerns? I'm not asking because I need advice. I'm asking because I want to know what you or your team did.
It's a niche B2B SaaS app and luckily we know most of our users personally. They all use modern browsers, usually Chrome or Edge on Windows. There is not a lot of mobile usage although we do support it.
I was going to suggest anchor positioning. I found it difficult to wrap my head around too, but once it clicks it's pretty simple. As a bonus, you can use it to position many other things than just popovers.
Here's a live example: https://www.w3schools.com/howto/howto_css_dropdown.asp
I'm not an LLM, but that was my immediate thought - how new does a browser have to be to support these and which browsers am I excluding by using these features?
If you put something like this in your popover class, it will resolve to the button that called it when position-anchor is not set:
top: anchor(bottom);
I'm not sure how widely supported it is but I've been using it in Firefox/Chrome.
I really wonder if AI coding is just going to lock us into 2024-ish era languages and libraries forever.
It's exactly like trying to acquire a bootleg of a movie, but all you can afford is a single blurry jpeg taken from the back row of a theater.
What's worse is you're an alien who wants to understand life on Earth by watching this single movie. That's how far away we are from AGI.
It doesn’t have to be that way.
You could create a Skill [1] that tells the agent to use modern css; the newer models like Opus 5 are probably much better with modern css.
Google released a set of skills at I/O called Modern Web Guidance [2] that steer coding agents to use modern css and best practices.
[1]: https://www.skills.sh/paulirish/dotfiles/modern-css
[2]: https://developer.chrome.com/docs/modern-web-guidance/get-st...
Wrapping an .md file in all this circus, with lingo carefully designed to hide the fact that under the hood you're really just dumping another text file into the LLM's context , helps nobody but people's AI psychosis.
But I guess "my LLM can use skills" sounds a lot cooler than "my LLM can read text files", so we'd rather keep pretending really hard.
Some terms and ideas are just shit, especially in the early stages of something new.
Skill issue? I mean, I wonder if adding a skill to use these newer standards can push it over the edge from the crappy JS it was trained on.
On positioning: we got farther with CSS anchor positioning once we stopped treating it like absolute offsets and started from "this is the preferred edge, then let the browser flip." Still awkward for nested context menus, but far less brittle than measuring getBoundingClientRect in a resize observer.
This seems like a common enough issue that it would be worthwhile publishing a "Markdown library" of "stuff HTML can do" that you can "call" from your AGENTS.md.
Edit: lol, a sibling commenter shows I am not the first to have this idea! https://developer.chrome.com/docs/modern-web-guidance/get-st...
(They made it a skill, which brings me to another thing I've had on my mind lately: that's annoying if you know when you start the harness that you will want it to read the skill. It's a roundtrip through the model to activate it. But maybe there's a way to fix that?)
(Edit2: Claude says if you activate the skill via /skill-name in the initial prompt, you get what I want)