Polyfills

Eunomia relies on two fairly recent platform APIs: the Popover API for every floating panel (Select, Date picker, Tooltip, the dropdown menu, the drawer, the modal…), and the CSS Anchor Positioning API to keep those panels attached to whatever opened them. Only one of the two already degrades gracefully inside Eunomia's own components on its own: you don't need to install anything just to get <eun-select> or <eun-tooltip> correctly positioned on a browser that lacks native anchor positioning. The other one, the Popover API itself, Eunomia assumes is there, so it's worth knowing exactly when that assumption needs help. This page covers both, the two situations where reaching for a real polyfill is worth it, and, since "import it somewhere" means something different in every setup, exactly where that import belongs in React, Next.js, Vue, Angular, and plain JavaScript. Pick a framework in the toolbar above the page and every code sample below adapts to it.

What Eunomia already handles for you

CSS Anchor Positioning: every Eunomia component that positions a panel against another element (Select, Date picker, Time picker, Tooltip, Search, the dropdown menu…) checks CSS.supports("anchor-name: --a") once, and automatically falls back to a getBoundingClientRect()-based positioning path, with the same flip-to-the-opposite-side behavior, everywhere the native API isn't available. That's why the tooltip below already opens in the right place, with nothing installed, on a browser without native support:

Native anchor positioning itself has shipped in every major engine (Chrome/Edge 125+, Firefox 147+, Safari 26+), but plenty of real traffic still runs older versions of each, which is exactly the gap this fallback closes. There's nothing to configure either way: the check runs on its own, and Eunomia's components use whichever path the browser qualifies for.

Popover API: this one Eunomia does not soften for you. Select's listbox, Tooltip's panel, Date picker's calendar, and the dropdown menu all call .showPopover() / .hidePopover() directly on their panel element. On a browser new enough to matter today (Safari 17+, Firefox 125+, Chrome/Edge 114+) that's the real, native method: nothing to do. On something genuinely old, that call throws (showPopover is not a function), which is exactly the gap the polyfill below closes.

Neither of these is new JS you have to load: it already ships inside @eunomia/elements today.

When you actually need a polyfill

Two of the three below, CSS Anchor Positioning and Popover, are maintained by Oddbird, the team that also helped author the underlying specs, and both ship their own TypeScript types: nothing extra to install for either. The other, Invoker Commands, is unrelated to Eunomia itself: eun-button, eun-fab, eun-modal, and eun-drawer implement command/commandfor in JavaScript directly rather than depending on the browser (see the Invoker Commands API guide), so it only matters for a native <button> you write yourself.

CSS Anchor Positioning polyfill

This one is for your own anchor-positioned UI, not for Eunomia components: Eunomia's own mixin decides whether to use the native path or its JS fallback by asking CSS.supports("anchor-name: --a") directly, which reports the browser's real support and is unaffected by whether this polyfill is loaded. So installing it changes nothing for <eun-select> or <eun-tooltip>, and only helps if you're writing anchor-name / position-anchor / anchor() yourself, elsewhere in your app.

npm install @oddbird/css-anchor-positioning

import polyfill from "@oddbird/css-anchor-positioning/fn";

polyfill();

When and how to call it

polyfill() reads layout from the real DOM (document, and, via roots, any shadow roots you pass it), so unlike the Popover polyfill above, which only patches a prototype and is safe to import unconditionally at the very top of anything, this one needs to run after the elements it's scanning actually exist, and only in the browser. Pick a framework in the toolbar above:

import polyfill from "@oddbird/css-anchor-positioning/fn";

if (!CSS.supports("anchor-name: --a")) {
  polyfill();
}

<div id="anchor">Anchor</div>
<div id="target" style="position-anchor: --a">Target</div>

<script type="module">
  import polyfill from "@oddbird/css-anchor-positioning/fn";
  if (!CSS.supports("anchor-name: --a")) {
    polyfill();
  }
</script>

import { useEffect } from "react";
import polyfill from "@oddbird/css-anchor-positioning/fn";

function App() {
  useEffect(() => {
    if (!CSS.supports("anchor-name: --a")) {
      polyfill();
    }
  }, []);

  return <div /* your anchored markup */ />;
}

// instrumentation-client.ts
import polyfill from "@oddbird/css-anchor-positioning/fn";

if (!CSS.supports("anchor-name: --a")) {
  polyfill();
}

import { Component, afterNextRender } from "@angular/core";
import polyfill from "@oddbird/css-anchor-positioning/fn";

@Component({
  /* ... */
})
export class AppComponent {
  constructor() {
    afterNextRender(() => {
      if (!CSS.supports("anchor-name: --a")) {
        polyfill();
      }
    });
  }
}

Configuring what it scans

polyfill() takes an options object if the defaults (scan the whole document, recalculate on scroll/resize) aren't right for your case:

import polyfill from "@oddbird/css-anchor-positioning/fn";

polyfill({ roots: [someElement.shadowRoot], useAnimationFrame: true });

TypeScript

Like the Popover polyfill, this package ships its own .d.ts files for both the default import and /fn: no extra install, no hand-written ambient declarations needed for the polyfill() call or its options object.

See Tooltip or Select for a live, already-anchored panel: both already run their own fallback wherever native anchor positioning isn't available, without this polyfill.

Invoker Commands API polyfill

This one isn't for Eunomia either. eun-button, eun-fab, eun-modal, and eun-drawer all implement command/commandfor themselves in JavaScript, so they already work with each other on every browser Eunomia supports, with nothing installed. What doesn't, on an older browser, is a plain native <button command commandfor>, written outside any of those four, targeting one of them (or any other element you've wired up to listen for command yourself). See the Invoker Commands API guide for how the attributes work.

npm install invokers-polyfill

Import it once, as early as possible, exactly like the Popover polyfill above: it checks for native support itself and only patches what's missing, so it's always safe to import unconditionally.

import "invokers-polyfill";

Where to import it

The same "as early as possible" rule as the Popover polyfill above applies here too. Pick a framework in the toolbar above:

import "invokers-polyfill";
// ...the rest of your app's entry point

<script type="module">
  import "invokers-polyfill";
</script>

<button command="show-modal" commandfor="my-modal">Open</button>
<dialog id="my-modal">...</dialog>

import "invokers-polyfill";
import { createRoot } from "react-dom/client";
import App from "./App";

createRoot(document.getElementById("root")!).render(<App />);

// instrumentation-client.ts — project root, or inside src/
import "invokers-polyfill";

import "invokers-polyfill";
import { createApp } from "vue";
import App from "./App.vue";

createApp(App).mount("#app");

{
  "projects": {
    "your-app": {
      "architect": {
        "build": {
          "options": {
            "polyfills": ["zone.js", "invokers-polyfill"]
          }
        }
      }
    }
  }
}

TypeScript

Ships its own .d.ts files for both the default import and the /fn entry point: nothing extra to install. The default import (what every example above uses) patches unconditionally and gives you nothing to type beyond "this module has side effects." To decide yourself whether to apply the patch instead, use /fn:

import { isSupported, apply } from "invokers-polyfill/fn";

if (!isSupported()) {
  apply();
}

Popover API polyfill

npm install @oddbird/popover-polyfill

Import it once, as early as possible (before any Eunomia component that opens a popover gets used): it checks "showPopover" in HTMLElement.prototype itself and only patches the prototype when that's missing, so it's always safe to import unconditionally:

import "@oddbird/popover-polyfill";

Where to import it

"As early as possible" means something different depending on how your app boots. Pick a framework in the toolbar above:

import "@oddbird/popover-polyfill";
// ...the rest of your app's entry point

<script type="module">
  import "@oddbird/popover-polyfill";
  import { EunomiaSelect } from "@eunomia/elements";
</script>

import "@oddbird/popover-polyfill";
import { createRoot } from "react-dom/client";
import App from "./App";

createRoot(document.getElementById("root")!).render(<App />);

// instrumentation-client.ts — project root, or inside src/
import "@oddbird/popover-polyfill";

import "@oddbird/popover-polyfill";
import { createApp } from "vue";
import App from "./App.vue";

createApp(App).mount("#app");

{
  "projects": {
    "your-app": {
      "architect": {
        "build": {
          "options": {
            "polyfills": ["zone.js", "@oddbird/popover-polyfill"]
          }
        }
      }
    }
  }
}

The button below is plain native HTML (no Eunomia component, no JS of ours at all), using the browser's own popovertarget attribute, the exact same showPopover()/hidePopover() machinery Select, Tooltip, Date picker, and the dropdown menu call directly on their own panels:

On a browser that already supports the Popover API natively, this already works with nothing installed. On one old enough to lack it, the import above is what makes this exact markup keep working instead of throwing.

TypeScript

Both the default import and the /fn entry point ship their own .d.ts files: nothing to add to a global declaration file, no @types/... package to install. The default import (what every example above uses) patches the prototype unconditionally and gives you nothing to type beyond "this module has side effects." If you'd rather decide yourself whether to apply the patch (say, to log which visitors actually needed it), use the /fn entry point instead:

import { apply, isPolyfilled, isSupported } from "@oddbird/popover-polyfill/fn";

if (!isSupported()) {
  apply();
}

isSupported() mirrors the check the default import already runs internally ("showPopover" in HTMLElement.prototype), while isPolyfilled() tells you afterward whether apply() actually did anything.

See also

• @oddbird/css-anchor-positioning on GitHub
• invokers-polyfill on GitHub
• @oddbird/popover-polyfill on GitHub
• Next.js: instrumentation-client.ts
• Get started: the same framework-adaptive toolbar, applied to install/import/use
• Tooltip: using the CSS Anchor Positioning API with a JS fallback
• Select: a popover="auto" listbox positioned with the same AnchorPositionMixin
• Invoker Commands API: what command/commandfor do and why Eunomia doesn't need this polyfill for its own components