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.

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

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.

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)

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?

I really wonder if AI coding is just going to lock us into 2024-ish era languages and libraries forever.

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.

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.

Here's a live example: https://www.w3schools.com/howto/howto_css_dropdown.asp

So, let the user type, then validate in javascript if you want instant feedback (by changing colors, say, to red / orange), but ideally don't fully block it from being seen by the server. And do the real validation on the server side. This is what I found to be fairly robust, while allowing mitigations if a bad rollout breaks something (delivering to clients is slower than updating something on the server side, most often).

And for some front-end form field validation in the spirit of htmx, ParsleyJS[0] is quite nice. Below is one way to enable the former to support the latter:

  htmx.defineExtension (
      'parsley-validation',
      {
          onEvent : function (name, evt) {
              var allow = true;
  
              if (name === 'htmx:load')
                  $(evt.target).parsley ();
              else if (name === 'htmx:confirm') {
                  var theForm = $(evt.target).parsley ();
  
                  theForm.validationResult = allow = theForm.isValid ();
  
                  if (!allow)
                      evt.preventDefault ();
              }
  
              return allow;
          }
      }
  )

https://developer.mozilla.org/en-US/docs/Web/API/View_Transi...

https://view-transitions.chrome.dev

Best part about it is how gracefully it degrades.

Even if a site doesn’t monetize with Google Ads, there’s a decent chance it’s pulling a script from ajax.googleapis.com, and Google still knows that you visited the site from the Referer of the script download.

https://noscript.net/

But yes, there's also a very good argument to be made in favor of having such localized elements follow the content's `lang` attribute - potentially with a `lang="initial"` to reset it to "whatever the user has configured for their OS".

Of course most JavaScript-based tables get this wrong, too.

But thinking about it: Is there a precedent for HTML to be able to include information that instructs the device to present the DOM out of order? Maybe it's out of scope for HTML to have information about presentation order, when the order is supposed to be implied strictly by the DOM hierarchy itself.

Of course, CSS can visually reorder stuff (e.g. `order` on flex/grid items), but MDN has accessibility warnings regarding the use of `order` and visually presenting the data in an order not reflected by the DOM. So, maybe sorting is best done by reordering the DOM after all.

Yes, it can be done with JS, but nothing is going to beat the browser engine for frequent DOM manipulation of that sort. It's also just one less dependency to have to pull in.

It's really easy to do this with server rendered HTML. Put a link with the sort param in the column headers and be done.

HTML describes layout, CSS describes style, JS adds interactivity.

Want sortable tables? Get a jquery plugin and spend five minutes, done.

This was all solved a decade or more ago.

https://css-tricks.com/covering-hiddenuntil-found/

https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...

So you could use it for additional notes, things like "view pricing terms" or "show exclusions" on product listings — stuff people need to read only when they need to read it — without it being hidden from them if they search for it.

Though humans will accidentally find it too, so using a details tag with appropriate summary as a warning would be more friendly than just hidden content. It'll still get opened, but the user at least has a way of closing it again afterwards.

Also before using it I'd want to check what old UAs including accessibility tools tend to do when they hit a value that they don't recognise for the hidden="" attribute - would what they don't recognise as a valid value result in defaulting to the content being hidden or visible/read/other?

"AI-bot protection" is the latest boogeyman for driving the Internet towards centralised control, along with age/identity verification and the rest of the DRM "trusted" computing crap. So much manufactured consent. It's sickening to see so many fall for that propaganda, especially those who should know better. Tell everyone who still thinks "AI bots" and not just plain old DDoS'es from those in bed with Big Tech are somehow pummeling their site, that the misdirection and lies are no longer working, and we might see things improve.

https://developer.chrome.com/blog/a-customizable-select

If I clicked it to open it, then if I want to close it, I'll click it again. Don't hide content I might still be reading!

Wait, that wasn't what you meant?

If it's part of a paragraph of insightful commentary, it's meaningful. On its own it's not, it appears as though the poster chose to copy-and-paste a cliché instead of bothering to tell us what their specific disagreement even is (perfectly reasonable sarcasm from the sibling comment notwithstanding).

https://austingil.com/animating-details-element-with-only-cs...

https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/S...

Supposed to be real handy for tooltips too, but haven’t used that myself yet.

Edit to avoid potential confusion: these are separate from modal dialogs, think more like very small popups anchored to one point on the page that still allow you to interact with everything else. Theoretically you can make them modal, but it would be silly to - you’d be better off using <dialog> and the invoker api

It's true, the amount of work that would be needed nowadays has made the idea of building a new browser engine almost impossible (I don't know how the Ladybird devs are getting on). It's a reason to encourage people to support Firefox on desktop, since just about everything else is based on the other browser engine. I still miss Opera's Presto - we don't want to lose another one, or there'll be no competition at all.

But as we've already crossed that threshold where the workload is preventing new engines from being built: choosing not to use new features, after they've been added to all the existing browser engines, isn't going to help that situation in any way.

Hard pass, that's essentially unusable.

How you handle it is project-dependent. But if you're doing a real web site, not an SPA, you can show an error/help page, or re-load the current page with the error/help message.

Hopefully, never. There's enough ad-blocking arms race as it is.