Tom MacWright

Some new Browser APIs

Some new APIs I’ve seen floating around:

Popover API - this has gotten a lot of buzz because JavaScript popover libraries are seen as overkill. I have mixed feelings about it: a lot of the code in the JavaScript popover implementations has to do with positioning logic - see floating-ui as a pretty authoritative implementation of that. The DOM API doesn’t help at all with positioning. Using CSS relative or absolute for positioning isn’t enough: flipping popovers around an anchor is really table stakes, and that still will require JavaScript. Plus, just like the <details> element, pretty much every time I use <details> for collapsing or popover for showing things, I eventually want to lazy-render the stuff that’s initially hidden, which brings us back to the scenario of having some JavaScript. It does look like the API will help with restoring focus and showing a backdrop. So: my guess is that this will be possibly useful, but it won’t eliminate the need for JavaScript in all but the most basic cases.

I’m kind of broadly skeptical of these new browser elements - for example, color inputs, date inputs, and progress elements seem to all fall just short of being useful for advanced applications, whether because they don’t support date ranges, or aren’t style-able enough. They just aren’t good enough to displace all of the JavaScript solutions.

As Chris points out, the popover API does provide a better starting point for accessibility. There are aria attributes for popups, but a lot of DIY implementations neglect to use them.

As Chase points out, there’s a separate proposed anchor positioning API that might solve the positioning problem! Very early on that one, though - no Firefox or Safari support.

CSS Custom Highlight API - now this one I can get excited about, for two reasons:

  1. “Browser search” is really hard to do in userspace. When you hit cmd+f in a browser, a lot of very subtle behaviors are invoked that are specific to your browser and hard to replicate in JavaScript - highlighting across elements, searching for words with locale replacements (searching for “naive” matches “naïve”). The custom highlight API makes this somewhat more possible to replicate in userspace - something that we really wanted to do at Observable and never could pull off.
  2. “Code highlighting” is a nearly worst-case scenario for excessive DOM sizes - every little syntax token needs to be wrapped with a <span> or some other element. This really hurts the performance of pages that show source code. Using custom highlighting for code syntax highlighting would be amazing. The only downside is that it would necessarily be client-side only, so no server rendering and probably a flash of unhighlighted code.

Array.with is super cool. Over the long term, basically everything that was introduced in underscore (which was itself heavily inspired by Ruby’s standard library) is becoming part of core JavaScript, and I’m into it. I think one of the takeaways of the npm tiny modules discourse is that if you have a too-small standard library, then you get a too-big third-party ecosystem with modules for silly things like detecting whether something is a number. There are just too many modules like that, and too many implementations of the same well-defined basic problems. The world is better now that we have String.padStart instead of several left-pad modules, including mine, sadly.