~

~

# Embed it and you’re good to go

Using <show-keystrokes> is as simple as loading the module from npm (or a CDN) and dropping the custom element onto your page. Embed it on your site and you’re good to go:

<script type="module" src="https://cdn.jsdelivr.net/npm/show-keystrokes/index.js"></script>
<show-keystrokes></show-keystrokes>

Out of the box, <show-keystrokes> listens for keyboard events and displays keyboard shortcuts (such as ⌘ + A or ⇧ + ⌘ + T) and navigational keys (such as ⇥, →, ←, ↵, and ⎋), while ignoring regular typing. If you do want to show every single key press, you can set the keystrokes attribute to all (or narrow it down to shortcuts or navigational).

<script type="module" src="https://cdn.jsdelivr.net/npm/show-keystrokes/index.js"></script>
<show-keystrokes keystrokes="all"></show-keystrokes>

The component automatically adapts to your platform (showing ⌘ and ⌥ on macOS versus CTRL and ALT on Windows/Linux), supports both symbol glyphs and text labels (⌘ vs CMD), and ships with two built-in themes that respond to light and dark mode via light-dark(). And oh, it’s fully styleable through by targeting the exposed ::part()s and custom properties.

~

# Powered by the Popover API and CSS Anchor Positioning

Depending on what you are demoing, you might want the keycaps to appear in different places. Using the position attribute, you can easily position the component in a corner of the viewport (the default is viewport top right), right next to the cursor (position="pointer"), or just inline in normal document flow (position="normal").

<!-- Fixed in the bottom-center of the viewport -->
<show-keystrokes position="viewport bottom center"></show-keystrokes>

<!-- Follow the cursor -->
<show-keystrokes position="pointer"></show-keystrokes>

<!-- Render inline in normal document flow -->
<show-keystrokes position="normal"></show-keystrokes>

Under the hood, <show-keystrokes> leans heavily on modern web platform features to make this work seamlessly without any z-index battles or JavaScript bounding-box math.

First, the component always stays on top of everything else on the page thanks to the Popover API. Its internal container is promoted to the browser’s Top Layer using popover="manual", ensuring that no matter how complex the host page’s stacking contexts are, your keystrokes will never be clipped or hidden behind another element.

Second, the component positions and repositions itself thanks to CSS Anchor Positioning. In viewport mode, it anchors itself inside a full-viewport anchor element and aligns itself using position-area, align-self, and justify-self. In pointer mode, an invisible anchor tracks your cursor coordinates (via custom properties), and the popover anchors itself next to it using position-area. The position-try-fallbacks: flip-inline, flip-block, flip-inline flip-block are set by default, so the browser automatically flips the keystroke overlay to the other side of the cursor whenever you move it too close to the edge of the viewport. 🙂

~

# Run it on any site with the Bookmarklet or Chrome Extension

Because you don’t always control the source code of the site you want to demo, the project also comes with both a bookmarklet ⓘ and a Chrome Extension so you can inject <show-keystrokes> onto any webpage on the fly.

The bookmarklet is a quick drag-and-drop button (available on the demo page) that dynamically imports the package from jsDelivr and calls the programmatic create() helper. For sites with a strict Content Security Policy (CSP) or when you want <show-keystrokes> to persist across page navigations, the Chrome Extension (currently pending review on the Chrome Web Store) has you covered. It bundles the component locally, lets you configure global defaults as well as per-origin overrides right from the popup, and includes a handy ⇧ + ⌘ + K (or ⇧ + CTRL + K) shortcut to toggle it on or off.

The Chrome Extension was a bit of an afterthought once I had version 1.0.0 of the component ready. But thanks to Modern Web Guidance and its Chrome Extensions skill, creating it was easy-peasy and done in no time (also see this guide) 🙂

~

# Links

• <show-keystrokes> Live Demo & Playground →
• <show-keystrokes> on GitHub →
• show-keystrokes on npm →
• <show-keystrokes> Chrome Extension →

~

# Spread the word

Feel free to reshare one of the following posts on social media to help spread the word:

• 🦋 Bluesky
• 🦣 Mastodon

~

~

~

# The Code

To make this work there is a two-way opt-in:

• The embedder (e.g. index.html) needs to set the frame-sizing CSS property with a value of auto, content-height, or content-width (or its logical variants) on the iframe.
• The document loaded in the <iframe> (e.g. iframe.html) needs to include a meta tag to indicate that it’s OK to communicate its size the parent embedder.

In code:

/* In styles.css for index.html */
iframe {
  frame-sizing: content-height;
  width: 100%;
}

<!-- In the iframe.html’s head -->
<meta name="responsive-embedded-sizing" content="allow-origins=*">

The content’s size is communicated from the embedded document after page load. To communicate a new size, the document in the frame must call window.requestResize();

Use allow-origins to limit which origins the document communicates its size info to.

~

# Demo

Here’s a demo that contains a form which is an <iframe>. Whenever you go to a next step of the form, the <iframe> resizes itself to its contents … if your browser suppports frame-sizing that is.

Because the iframe resizes itself, the form is seamlessly embedded, without any scrollbar appearing at all.

~

# Browser Support

Support for responsively size iframes is this:

Chromium (Blink)

✅ Supported in Chrome 154

Firefox (Gecko)

❌ No Support. There is no bug tracking this yet.

Safari (WebKit)

❌ No Support. There is no bug tracking this yet.

~

# Learn More

Get all the details about responsive iframes on developer.chrome.com, in this article I co-authored: Responsive iframes in Chrome 154 →

~

~

The Need: Clean imports without leaking implementation details

When authoring a package, you typically have a directory layout like this:

my-package/
├── src/
│   └── index.js
├── dist/
│   └── index.js
├── package.json
└── README.md

Source code lives in src/, while your a build step typically spits out the distribution files into a dist/ or build/ folder. Or if your package has no build step, because you authored an ES Module in JavaScript, you can even ship src/ as-is. This detail can leak into your public API, which is something you generally want to avoid, especially when loading the files from a CDN.

For example, the very first version of my ie-page-transitions package — which has no build step — shipped the src folder as part of the package structure.

my-package/
├── src/
│   ├── ie-page-transitions.css
│   ├── ie-page-transitions.mpa.js
│   ├── ie-page-transitions.shared.js
│   └── ie-page-transitions.spa.js
├── package.json
└── README.md

To users that use NodeJS (or a bundler) this detail is not visible, thanks to the exports field in the package.json.

{
  "name": "ie-page-transitions",
  "version": "0.0.1",
  …
  "exports": {
    "./spa": "./src/ie-page-transitions.spa.js",
    "./mpa": "./src/ie-page-transitions.mpa.js",
    "./shared": "./src/ie-page-transitions.shared.js",
    "./css": "./src/ie-page-transitions.css"
  },
  …
}

When using NodeJS, users can just import the files straight from the package without needing to know the files live in the ./src folder. For example, the CSS can be imported as follow:

import styles from 'ie-page-transitions/css' with { type: "css" };

But for users loading the package from a CDN, it’s a different story. When loading the package from a CDN like jsDelivr, users needed to import the files from locations that all include that src folder. That same CSS file for example needs to be loaded from this location:

https://cdn.jsdelivr.net/npm/ie-page-transitions@0.0.1/src/ie-page-transitions.css

I don’t like this, because having src/ (or dist/ or build/) in public import paths is an implementation detail that leaked into the public API. It looks clunky, exposes the internal folder structure, and is just annoying to type.

~

The Solution: npm publish ./folder

For my last three packages (hic-pageflip, mermaid-element, and rich-input), which all build their source into a ./dist folder, I’ve been using a little trick to publish only the contents of the dist folder to NPM. This makes the import paths clean and direct. For example, for hic-pageflip, when loading from a CDN like jsDelivr, it does not include dist/-part in the URL:

import { PageFlip } from 'https://cdn.jsdelivr.net/npm/hic-pageflip';

To achieve this, I used a lesser-known capability of the npm CLI: npm publish accepts a folder path as an argument.

npm publish ./dist

When you pass a folder path to npm publish, npm doesn’t package the current working directory. Instead, it treats that target folder as the package root.

Whatever is inside ./dist will be placed directly at the top level of the tarball uploaded to the registry.

For this to work, you do need some extra preparation, but it’s worth it. Let me walk you through how it works.

~

Making It Work: The Missing Pieces

In order to publish the dist folder, there are two main things you need to do once your project has been built:

1. Copy other necessary package files (package.json, README.md, LICENSE, etc.) into ./dist.
2. Rewrite the package.json in ./dist so its paths match the new root (and optionally remove the scripts from that file as well).

Let’s look at both steps.

~

1. Copy files you want to package into ./dist

Because npm publish ./dist treats ./dist as the package root and ignores everything outside of it, that folder needs to contain all the metadata files required for a valid package alongside your built code:

• package.json (so npm knows your package name, version, dependencies, and entry points).
• README.md (so npmjs.com displays your documentation).
• LICENSE (so npm recognizes your license and consumers stay legally safe).

Since all of these typically live in your project root, you need to copy them into ./dist after building. You can also include other files if you want, of course.

~

2. Rewrite the package.json in ./dist

Simply copying your root package.json into ./dist as-is won’t work — the package.json in the build folder needs to be adjusted.

In your root package.json, your entry points typically include the ./dist/ prefix:

{
  "name": "my-package",
  "version": "1.0.0",
  "main": "./dist/index.js",
  "module": "./dist/index.js",
  "exports": {
    ".": "./dist/index.js",
    "./submodule": "./dist/submodule.js"
  }
}

If you copy that package.json as-is into ./dist and publish it, everything breaks because for published package, the root is the contents of ./dist itself.

So the paths in the file ./dist/package.json must be rewritten relative to the new root:

{
  "name": "my-package",
  "version": "1.0.0",
  "main": "./index.js",
  "module": "./index.js",
  "exports": {
    ".": "./index.js",
    "./submodule": "./submodule.js"
  }
}

~

The Code: Assembling ./dist

Rather than manually copying files and re-mapping every single export field by hand, you can automate both steps in a small Node.js script. For the package.json adjustments, a quick string replace does the trick: take your root package.json, strip out internal scripts, and replace ./dist/ with ./.

Here’s a clean, zero-dependency Node.js script (scripts/postbuild.js) that does the heavy lifting:

import fs from 'node:fs';
import path from 'node:path';
import { fileURLToPath } from 'node:url';

const __filename = fileURLToPath(import.meta.url);
const __dirname = path.dirname(__filename);
const rootDir = path.resolve(__dirname, '..');
const distDir = path.join(rootDir, 'dist');
const srcDir = path.join(rootDir, 'src');

console.log('Preparing ./dist package...');

// 1. Clean and recreate the dist directory (if not already handled by your bundler)
fs.rmSync(distDir, { recursive: true, force: true });
fs.mkdirSync(distDir, { recursive: true });

// 2. Copy compiled/source files into dist/
fs.cpSync(srcDir, distDir, { recursive: true });

// 3. Copy essential metadata files from root to dist/
const filesToCopy = ['README.md', 'LICENSE'];
for (const file of filesToCopy) {
  const srcPath = path.join(rootDir, file);
  if (fs.existsSync(srcPath)) {
    fs.copyFileSync(srcPath, path.join(distDir, file));
  }
}

// 4. Prepare and rewrite package.json for dist/
const pkgPath = path.join(rootDir, 'package.json');
if (fs.existsSync(pkgPath)) {
  const pkg = JSON.parse(fs.readFileSync(pkgPath, 'utf8'));

  // Strip scripts so consumers don't get internal build/test scripts
  delete pkg.scripts;

  // Replace ./dist/ with ./ so all paths point to the root of the published package
  const distPkgContent = JSON.stringify(pkg, null, 2).replaceAll('./dist/', './') + 'n';

  // Write out the tailored package.json to dist/
  fs.writeFileSync(
    path.join(distDir, 'package.json'),
    distPkgContent,
    'utf8'
  );
}

console.log('Successfully prepared ./dist for publishing!');

You can (and should) set this up as a postbuild step in your root package.json so that it automatically runs every time npm run build finishes:

{
  "scripts": {
    "build": "…",
    "postbuild": "node scripts/postbuild.js"
  }
}

Now, every time you run npm run build, the files and code in ./dist end up as a self-contained, publication-ready package.

~

# Safeguarding Against Muscle Memory: Prevent npm publish from running

Typically, when authoring a package that has a build step, you have npm run build execute in a prepublishOnly task in your package.json:

{
  "scripts": {
    "build": "…",
    "postbuild": "node scripts/postbuild.js",
    "prepublishOnly": "npm run build"
  }
}

That way, every time you run npm publish, npm automatically builds the project first before publishing.

However, with our subfolder setup, there’s a big catch here: developer muscle memory.

When you’re ready to ship an update and instinctively type npm publish into your terminal, npm will dutifully run prepublishOnly and execute npm run build … but then it’s still gonna try and publish the project root instead of ./dist … uh-oh!

To prevent this from ever happening, you can repurpose prepublishOnly into a safeguard and combine it with a dedicated publish script (npm run pub) that runs npm run build before calling npm publish ./dist.

In your root package.json:

{
  "scripts": {
    "build": "…",
    "postbuild": "node scripts/postbuild.js",
    "prepublishOnly": "if [ -z $PUBLISH ]; then echo 'n🛑 ERROR: This package must be published using `npm run pub`n' && exit 1; fi",
    "pub": "PUBLISH=true npm run build && npm publish ./dist"
  }
}

The trick here is the $PUBLISH environment variable. When you run npm publish directly, $PUBLISH is not set, and the script simply exits — preventing npm publish from running.

In the pub script (invoked via npm run pub), $PUBLISH gets explicitly set to true, which allows the build and npm publish ./dist to go through without being blocked.

This setup is simple, elegant, and completely foolproof 🙂

~

Testing Your Publish: Dry Runs and Tarballs

Before you publish a package to the live registry for the first time with this setup, don’t just push it and hope for the best. Test it locally first.

Here are two essential commands to verify your setup:

1. Perform a dry run with npm publish ./dist --dry-run

You can run npm publish with the --dry-run flag pointing to your folder:

npm publish ./dist --dry-run

This runs the entire publishing pipeline — tarball creation, file filtering, checksum generation — without actually uploading anything to NPM.

It outputs a detailed manifest of everything that will be shipped:

npm notice === Tarball Contents ===
npm notice 1.1kB  LICENSE
npm notice 1.8kB  README.md
npm notice 850B   index.js
npm notice 1.2kB  package.json
npm notice 4.2kB  core/engine.js
npm notice === Tarball Details ===
npm notice name:          hic-pageflip
npm notice version:       1.0.1
npm notice filename:      hic-pageflip-1.0.1.tgz
npm notice package size:  3.2 kB
npm notice unpacked size: 9.1 kB
npm notice total files:   5

Look closely at that file list: notice how index.js, README.md, and LICENSE are all sitting right at the root, with no dist/ prefix in sight? That’s your confirmation that the subfolder structure is working as intended.

~

2. Inspect the created tarball with npm pack

The previous step already generates the tarball for publishing. You can also run npm pack on its own to generate a local tarball (e.g. my-package-1.0.0.tgz) for inspection.

# Be sure to run npm run build first
npm pack ./dist

You can then extract and inspect the contents of the generated tarball:

tar -xzf my-package-1.0.0.tgz ./my-package-1.0.0

Now you’ll see the contents of ./dist sitting right in the folder ./my-package-1.0.0 which confirms that the package was correctly packaged and is ready for publishing.

~

In Closing

Publishing a subfolder instead of your repository root is one of those small tweaks that, I think, makes for a better package, without much added complexity. I’ve successfully used this pattern in multiple projects, including hic-pageflip and rich-input.

It feels a bit stupid that NPM does not have this functionality built in, especially since developers have been asking about this for more than 10 years by now. A new publishDirectory field in the package.json that instructs npm publish to publish that specific subfolder would be welcome here. PNPM has this (publishConfig.directory), and I think it’s long overdue for NPM to support this as well …

Until then, you can use the pattern I detailed here in this post 🙂

~

Spread the word

Feel free to reshare this post on social media to help spread the word:

• 🦋 Bluesky
• 🐘 Mastodon
• 💼 LinkedIn

~

~

~

# The need for a rich search input

If you have ever used search fields on GitHub, Gmail, or modern music databases, you know the pattern: you can type regular free-text words, but you can also narrow things down using structured key:value pairs. For my record collection side-project, I wanted exactly that kind of search engine-grade filter intelligence.

I wanted to be able to type queries such as ambient artist:"Aphex Twin" label:"Warp Records"; year:2024, complete with autocompletion for both the filter keywords and their allowed values. On top of that, I wanted in-input syntax highlighting for the structured filter values, without relying on heavy frontend frameworks or breaking standard form behaviors.

Looking around a bit, it seemed like an easy-to-use, standalone custom element providing this out of the box simply did not exist yet. So I nerd sniped myself into creating one: <rich-input>.

~

# What is <rich-input>?

<rich-input> is a standalone Web Component that gives you smart, keyword-aware search fields. You configure it completely declaratively by nesting standard HTML <datalist> elements inside it:

<script type="module" src="https://cdn.jsdelivr.net/npm/rich-input/index.js"></script>

<rich-input placeholder="Search music catalog...">
  <!-- String filter with rich autocomplete options -->
  <datalist id="label" label="Record Label">
    <option value="Warp Records">
      <img src="assets/warp-records.png" height="50" width="50" alt="Warp Records">
      Warp Records
    </option>
    <option value="Ninja Tune">
      <img src="assets/ninja-tune.jpg" height="50" width="50" alt="Ninja Tune">
      Ninja Tune
    </option>
  </datalist>

  <!-- Numeric filter -->
  <datalist id="year" label="Release Year" data-type="number">
    <option value="2026"></option>
    <option value="2025"></option>
    <option value="2024"></option>
  </datalist>
</rich-input>

With just that markup in place, the component gives you:

• Dual Autocompletion: It automatically suggests filter keywords when you start typing a word (e.g. typing l suggests label:, typing y suggests year:) as well as the values for that keyword (typing label:“W suggests Warp Records).
• Full-String Suggestion Filtering: The suggestion dropdown filters against the full token string rather than a naive slice at the caret position. Whether your caret is at label:“W|arp Records” or right between the colon and quotes at label:|“Warp Records”, the dropdown cleanly matches the actual value.
• Rich Option Markup: You can embed <img> logos or avatars inside your <option> tags. The component extracts them into the autocomplete popover and exposes ::part(suggestion-image) so you can style them (e.g. as circular avatars).
• Validation & Squiggly Underlines: If you enter an unrecognized keyword or a value that is not part of the configured <datalist>, the component marks it as invalid with a wavy red underline via ::highlight(rich-input-invalid) once your cursor moves away or the input loses focus.
• Native Form Participation: It uses formAssociated = true, so it seamlessly submits via standard <form> elements and works with FormData.

Try it out here:

~

# Powering it with the OpaqueRange API

I knew this project would be quite easy to build thanks to the new OpaqueRange API (as recently covered by Ollie Williams), available in Chrome 152+.

Historically, doing any kind of rich interaction inside a native <input> — such as measuring exact caret coordinates to position a popover, or applying styling to substrings within the input — was a notorious exercise in pain. You had to resort to brittle “mirror div” hacks: an off-screen or invisible <div> styled with the exact same font, padding, border, and scroll offsets, replicating the input’s text to measure coordinates.

With OpaqueRange native text inputs gain first-class range capabilities. You can call input.createValueRange(start, end) to get an OpaqueRange representing any text slice inside the control. This unlocks two massive superpowers:

1. Anchoring popovers: You can call range.getBoundingClientRect() directly on an OpaqueRange to get the exact viewport coordinates of the active token or caret, allowing the autocomplete popover to anchor precisely to the start of the token.
2. Custom Highlights: You can register the ranges with the CSS Custom Highlight API via CSS.highlights.set(keyword, new Highlight(range)). That means you can style each keyword’s value directly in your CSS stylesheet!

/* Style record label values */
::highlight(label) {
  background-color: oklch(0.92 0.08 240);
  color: oklch(0.28 0.14 240);
  text-decoration: 2px underline solid oklch(0.5 0.15 240 / 0.5);
}

/* Style release years */
::highlight(year) {
  background-color: oklch(0.93 0.1 85);
  color: oklch(0.35 0.14 85);
}

/* Style invalid tokens with a wavy red squiggly */
::highlight(rich-input-invalid) {
  text-decoration: underline wavy #ef4444;
  text-decoration-skip-ink: none;
}

Because these are native highlights, text selection, copy-pasting, undo/redo stacks, and caret navigation continue to work 100% natively without any layout shifts or DOM synchronization glitches.

~

# The Cross-Browser Fallback

Because OpaqueRange is still brand new and currently only supported in Chromium 152+, the component also comes with a built-in fallback strategy. When OpaqueRange is not supported, the component internally swaps the native <input> inside its Shadow DOM for an adapted, single-line [contenteditable] element and resorts to regular CSS Custom Highlights to do the highlighting — a technique I pioneered in https://brm.us/syntax-highlighting.

For some reason the Custom Highlights do not cross into the Shadow DOM in Firefox and Safari. To fix that, the component also copies over document’s custom highlights from document.stylesheets into the Shadow DOM. Also accepted is a <style> element nested directly inside the <rich-text>.

~

# AI-Assisted with Google Antigravity

Just like my previous two custom element projects (<hic-pageflip> and <mermaid-element>), this component was built with AI assistance using Google Antigravity.

I used stock Antigravity powered by Gemini, configured with the Modern Web Guidance skill and the Chrome DevTools MCP server.

In my prompt, also explicitly pointed Antigravity to my two previous repositories, instructing it to replicate their project layout, demo structure, and styling. Finally, I also included links to resources about OpaqueRange, including Ollie’s post. You can check my initial prompt here:

Create me a rich search component `<rich-search>` that can automplete values for keyword-bases searches.

The component is and acts like a regular `<input type=text>` so you can type in just text. But when typing in specific keywords it should add suggestions for those keywords. Those keyword-searches are in the form  of `keyword:value`

As an example, some keywords and values one could entere for a music application are:
- genre:"<string>"
- style:"<string>"
- year:<number>
- label:"<string>"
- artist:"<string>"
- mix:"<string>"
- mixid:<number>
- playlist:"<string>"
- playlistid:<number>

An example search string could be something like `label:"We Play House Recordings" year:2026 playlist:"WPH Classics"`.

The search field should be able to autocomplete:
- The keywords. E.g. when I type in `m` at the start of a new word, it should suggest `mix:` and `mixid:` which I can choose from a list of suggested options.
- The values for those keywords. E.g. when I start typing `label:"K|` (with | being the current cursor position), then it should suggest the labels “Kranky” and “Keinemusik”.

The configuration of all this happens through `<datalist>` elements that are placed inside the `<rich-search>` element. E.g. this could be the list that suggest values for `label`:

```html
<datalist id=label label="Record Label">
  <option value="Defected"></option>
  <option value="Keinemusik"></option>
  <option value="Kranky"></option>
  <option value="Ninja Tune"></option>
  <option value="We Play House Recordings"></option>
  <option value="XL Recordings"></option>
</datalist>
```

Technically, implement this using the OpaqueRange API. Check these resources for info:
- https://chromestatus.com/feature/6297362687066112
- https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/OpaqueRange/explainer.md
- https://olliewilliams.xyz/blog/opaquerange/

Styling of the values using the Custom Highlights API should be possible (e.g. `::highlight(label)` can be used to style the value set in label:"We Play House Recordings"). Styling of the input itself should be done using `::part()`.

Follow the project structure as seen in the projects https://github.com/bramus/hic-pageflip and https://github.com/bramus/mermaid-element. Also use the same demo structure and style.

Antigravity handled this prompt very well. Like, it came up with adding a little leading icon, added a “clear input” button, added keyboard navigation, added the getParsedQuery() API, etc. all without me asking 🙂

(Later on I renamed it from <rich-search> to <rich-input>, added support for images, added the fallbacks, etc.)

~

If you take a look at the commit history on GitHub, you’ll notice that most commit messages include the exact prompt I used. One commit I really liked is the one where I asked it to generate a visual similar to the one Una made for Customizable Select.

The result (after two extra nudges that got squashed into the commit) is this nice visual:

~

# Get the package

You can use <rich-input> right now or drop it into your own projects:

To install it via npm:

npm install rich-input

Once imported, the custom element is ready to use (the package registers the component all by itself)

import rich-input;

Alternatively, you can load it directly in HTML from a CDN such as jsDelivr:

<script type="module" src="https://cdn.jsdelivr.net/npm/rich-input/index.js"></script>

~

# Links and Resources

Check out the following links for more info and demos:

• 🚀 Project Homepage & Live Demo: https://rich-input.netlify.app/ →
• 📦 NPM Package: rich-input on npm →
• 💻 Source Code: bramus/rich-input on GitHub →

~

# Spread the word

Feel free to reshare one of the following posts on social media to help spread the word:

• 🦋 Bluesky
• 🦣 Mastodon
• 💼 LinkedIn

~

About a month ago, WebKit gained support for interactive-widget. While it’s not clear whether this will end up in Safari or not, this is pretty exciting news: If you have ever had a virtual keyboard obscure your fixed navigation bar, then interactive-widget is for you.

This post details a quick recap of what the feature does, how we got here, and a sneak peek at it running in WebKit.

~

# The backstory: Interop 2022

Back in 2022, I did a lot of research into viewports as the lead of the Viewport Investigation Effort, part of Interop 2022.

While that effort still hasn’t led to an actual Interop Proposal (due to the lack of proper mobile testing, something that is in the works ever since 2023 😏), one of the outcomes was that we at Chrome changed how viewports get resized when the virtual keyboard gets shown in Chrome on Android.

~

# Enter interactive-widget

Where Chrome used to resize the layout viewport by default, its behavior changed in Chrome 108. As of that version, which shipped in 2022, Chrome only resizes the visual viewport, thereby aligning its behavior with that of Safari.

The side-effect of this change, though, is that you could end up with position: fixed content that gets obscured by the virtual keyboard:

As some developers heavily relied on the old behavior — or just want to have a fixed bottom toolbar that sits atop the virtual keyboard – we at Chrome developed a way to control what should happen when the virtual keyboard pops up: the interactive-widget directive for use in the viewport <meta> tag.

<meta name="viewport" content="width=device-width, initial-scale=1.0, interactive-widget=resizes-content">

The directive accepts three values:

• resizes-visual: Resize only the Visual Viewport but not the Layout Viewport (default behavior).
• resizes-content: Resize both the Visual Viewport and Layout Viewport.
• overlays-content: Do not resize any viewport. This is similar to using the Virtual Keyboard API with overlaysContent set to true.

Put visually:

~

# Available in WebKit

About a month ago (mid-August), I was surprised to read a comment on the WebKit GitHub repo that interactive-widget had been implemented in WebKit.

Eager to test this out, it quickly became clear that this was not exactly possible without building WebKit yourself and running it using a simple browser shell called MobileMiniBrowser on the iPhone Simulator. A pity, as I don’t think all web developers out there can find their way around that.

Anywho, today I bit the bullet and built WebKit locally. Some time later (with fan noises as background music throughout) I had MobileMiniBrowser open in an iPhone Simulator with the Viewport Resize Behavior demos open.

While interactive-widget works fine in MobileMiniBrowser (hooray!), I still would like to test things in a real Safari on iOS. For that I will probably have to wait for Safari 27.1 to come, which, I guess, will be the version that will include this change. It is not clear though, because the Safari Technology Preview release notes have no mention of interactive-widget, even though Safari on desktop shows it in the list of feature flags …

Reason I would like to test Safari on iOS itself, is because its UI differs a lot from the MobileMiniBrowser. For example, I’d like to see if and how Safari’s floating address bar influences things here. It’s probably fine already — there’s clever people work on Safari after all — but ever since viewport-fit ended up getting broken in Safari 26 (and still is broken to this day), I’d like to double check.

(💭 Side thought: If only there were a Safari Technology Preview for iOS …)

~

# Browser Support

interactive-widget is supported in the following browsers:

Chromium (Blink)

✅ Supported in Chrome 108 (Android)

Firefox (Gecko)

✅ Supported in Firefox 133 (Android)

Safari (WebKit)

⏳ In development. Implemented in the WebKit source, but not yet shipped in a public release of Safari or Safari Technology Preview.

~

# Closing thoughts

I’m excited to see interactive-widget, a feature I helped shape, become part of WebKit. Hopefully it will come to Safari as well, so that developers can get control over how the viewport should resize when the virtual keyboard gets shown. To learn more about interactive-widget, check out the following resources I’ve authored:

• Control the Viewport Resize Behavior on mobile with interactive-widget →
• Viewport vs Virtual Keyboard Resize Behavior Explainer →
• Prepare for viewport resize behavior changes coming to Chrome on Android →

~

~

~

Looking at Chris’s demos, I see CodePen relies on Markdown code blocks with backticks (```mermaid) to render the diagrams. Seeing that in action got me wondering: is there a standalone custom element out there to drop Mermaid diagrams declaratively onto any web page? Turns out, there wasn’t.

So I built one, assisted by Antigravity: <mermaid-element>.

It’s a zero-config, dependency-free web component that renders Mermaid diagrams inside an open Shadow DOM. Simply import the script and put your Mermaid syntax directly inside the custom element:

<script type="module" src="https://cdn.jsdelivr.net/npm/mermaid-element/index.js"></script>
<mermaid-element>
  graph TD
    Client[Client Request] --> LB[Load Balancer]
    LB --> Server1[Server 01]
    LB --> Server2[Server 02]
</mermaid-element>

(Yes, you can also get the component from npm)

~

By default, <mermaid-element> is a drop in component that will automatically load Mermaid (version 12) on demand via jsDelivr. However, if you want to use a different version of Mermaid, you can pin a specific version or supply a custom endpoint using the mermaid attribute. Just set mermaid to a version string (e.g. mermaid="10.9.8") or a full URL, and <mermaid-element> will use that.

The component also comes with a built-in in-memory cache. If you have multiple diagrams on the same page, they will download Mermaid only once. Also, if your app already bundles Mermaid, you can assign your own copy to MermaidElement.defaultMermaid to bypass external CDN requests altogether.

~

I also built an interactive playground to show some examples and to show how you can configure the component. The resulting HTML is shown right underneath the visualization, ready for you to copy and paste:

See the Pen
<mermaid-element> playground by Bramus (@bramus)
on CodePen.

The <mermaid-element> website has some more examples (and instructions).

~

Check out the live documentation or grab the package from npm:

• <mermaid-element> Website & Live Demo →
• mermaid-element on npm →
• mermaid-element on GitHub →

~

~

~

# The Technique

The effect we are after is this one: as the grid resizes, the grid cells nicely animate to their new position:

The trick here is to use CSS Anchor Positioning and anchor the cell’s content to the cell itself. Since you can’t anchor content directly onto a grid’s cell — grid cells are virtual concepts — you need to inject an extra wrapper div that is set to take up the cell’s available space and act as the anchor. Regular CSS transitions are then responsible for nicely animating things as they shift around.

<div class="grid">
	<div class="cell">
		<div class="content">CONTENT</div>
	</div>
	<div class="cell">
		<div class="content">CONTENT</div>
	</div>
	…
</div>

.grid {
	display: grid;
	grid-template-columns: repeat(auto-fill, 6rem);
	gap: 1em;
}

.cell {
	height: auto;
	aspect-ratio: 1;
	
	anchor-scope: --a;
	anchor-name: --a;
}

.content {
	position: absolute;
	position-anchor: --a;
	inset: anchor(inside);
	width: 6rem;
	height: 6rem;

	transition: inset 0.2s ease;
}

There are four key details that make this whole setup click:

1. Because anchor names are by default global, they need to be scoped to a specific cell’s subtree. anchor-scope: --a; takes care of that, allowing every .cell to reuse the --a identifier without clashing with any other cells.

2. The aspect-ratio: 1; on the .cells ensures they take up as much height as they are wide.

3. The transition declaration ensures the inset nicely transitions from one value to the other.

4. The .content divs are given explicit dimensions (width and height). Without it, the .content divs would stretch and squeeze as they interpolate across the resizing grid.

Unlike with View Transitions, this technique requires absolutely no JavaScript and the animations are perfectly interruptible. If you rapidly resize the viewport back and forth, the tiles don’t get queued up waiting for animation frames or transition promises to finish—they immediately redirect mid-flight toward their newly calculated positions.

~

# Demo

Here is the demo I built to demonstrate this behavior:

See the Pen
Animated Reorganizing Grid with Anchor Positioning (No View Transitions!) by Bramus (@bramus)
on CodePen.

Try resizing the embed or the .container in the demo itself to see the grid rearrange itself.

Or, if you want something more high-fidelity (and that more closely matches the Brave New Tab Page IIRC):

See the Pen
Animated CSS Grid with CSS Anchor Positioning by Bramus (@bramus)
on CodePen.

~

# Spread the word

Feel free to reshare one of the following posts on social media to help spread the word:

• 🦋 Bluesky
• 🦣 Mastodon
• 💼 LinkedIn

~

~

~

~

~

PageFlip?

PageFlip is a classic UI pattern that simulates a hyper-realistic, interactive book or magazine: users can click, drag, and peel page corners to flip through content with dynamic lighting, curls, and shadows. It was popularized in 2005–2006 by Iparigrafika who shipped a Flash Component.

While recreating this effect on the web has technically been possible for years using 2D Canvas or WebGL shaders, it always came with massive accessibility and usability drawbacks. Because the pages were trapped inside a canvas pixel grid or rendered as static images, you lost selectable text, clickable links, screen reader support, and browser features like find-in-page.

Using HTML to render pages has also been possible by leveraging CSS transforms (see this example). However, that effect was always somewhat “fake”: it’s a pure 2D clip effect with a shadow laid on top, instead of true 3D folding and curling as described in Chris Luke’s “The anatomy of a page curl”.

~

HTML-in-Canvas was made for this

Up until now, you always had to compromise: either get authentic 3D page curls with Canvas or WebGL at the cost of throwing away accessibility, or stick to real HTML with CSS transforms and settle for a flat 2D clipping illusion.

The new (and still experimental) HTML-in-Canvas API changes the game. By letting you draw live DOM elements directly into canvas contexts and WebGL textures, you no longer have to choose. You can build true 3D conical and cylindrical page curls, while the pages remain fully interactive and accessible, with selectable text and clickable links.

Armed with Google Antigravity and the math from Chris Luke’s article, I set out to build it.

~

Keeping Things Easy: <hic-pageflip>

In under two hours, I had a working pageflip prototype powered by HTML-in-Canvas up and running. I then continued the work to further refine the interactions and visuals, and eventually had Antigravity refactor the whole thing into an easy-to-use web component: <hic-pageflip>

You can see it in action on the demo website which is also embedded here:

The source code is available on GitHub and you can install the package from NPM.

~

Installation

You can install the package from npm:

npm install hic-pageflip

Import the package in your application to have it register the custom elements:

import 'hic-pageflip';

You can also load it directly from a CDN and use it in your HTML, without npm at all. For example, using jsDelivr:

<script type="module" src="https://cdn.jsdelivr.net/npm/hic-pageflip"></script>

Once installed and imported, you can start using it.

~

Minimal Example

With the component, creating a pageflip interface powered by HTML-in-Canvas becomes as easy as this:

<hic-pageflip engine="3d" page-width="300" page-height="450" page-background="#c1c8c7">
	<!-- Slide 1: Cover -->
	<hic-pageflip-page>
		<div class="content">
			<h1>Cover Page</h1>
			<p>This is HTML inside a 3D WebGL pageflip!</p>
		</div>
	</hic-pageflip-page>

	<!-- Slide 2 -->
	<hic-pageflip-page>
		<div class="content">
			<h2>Inside Left Page</h2>
			<p>Selectable text and clickable <a href="https://github.com/bramus/hic-pageflip" target="_top">links</a> work natively.</p>
		</div>
	</hic-pageflip-page>

	<!-- Slide 3 -->
	<hic-pageflip-page>
		<div class="content">
			<h2>Inside Right Page</h2>
			<p>And images (with the right CORS headers)!</p>
			<p><img src="https://gravatar.com/avatar/c47bf5e271115acb3820392b0a5c9574" alt="Bramus" height="50" width="50" crossorigin="anonymous"></p>
		</div>
	</hic-pageflip-page>

	<!-- Slide 4: Backcover -->
	<hic-pageflip-page>
		<div class="content">
			<h2>Backcover</h2>
			<p>And CSS as well …</p>
			<p class="rainbow">Rainbow text, Yay!</p>
		</div>
	</hic-pageflip-page>
</hic-pageflip>

The enclosing <hic-pageflip> component creates the pageflip interface, and the <hic-pageflip-page> components are the pages contained within.

With some mininal styling applied, the code above looks like this:

~

Customization

Use the attributes on the <hic-pageflip> component to control a bunch of things, including which engine to use:

1. 2D Engine (engine="2d"): Uses 2D canvas affine matrix reflections, clipping, and dynamic drop shadows.
2. 3D Engine (engine="3d"): Uses WebGL vertex shaders for true cylindrical and conical page curls, based on Chris Luke’s page curl algorithm.

The default is 3d, the one with the true page curl effect.

The <hic-pageflip> component itself only offers the pageflip interface, without any controls. However, you can control the pageflip programmatically by calling methods directly on the component:

const pageflip = document.querySelector('hic-pageflip');
// Go to next page
pageflip.next();
// Go to previous page
pageflip.previous();
// Go to page 4
pageflip.goToPage(4);
// Flip to a page
pageflip.flipTo(4);

Hook these up to your own buttons and you’re good to go 🙂

~

Links and resources

To recap, here are all the links you need:

• 🚀 Project Homepage + Demo: https://hic-pageflip.netlify.app/ →
• 🤖 Minimal Demo: <hic-pageflip> demo (CodePen) →
• 💻 Source Code: bramus/hic-pageflip →
• 📦 NPM Package: hic-pageflip →

~

Spread the word

Feel free to reshare one of the following posts on social media to help spread the word:

• 🦋 Bluesky
• 🦣 Mastodon
• 💼 LinkedIn

~

~

The OG use-case: “Flexbox Gap”

Back in the day (and by back in the day, I mean 2020 😅), I wrote about the gap property for Flex layouts landing in Chromium. The property already worked with Grid Layouts, and the post celebrated the property also starting to have an effect on Flex layouts.

Historically, this gap property debuted in 2015 as grid-gap (as a shorthand for grid-row-gap and grid-column-gap), and worked exclusively for CSS Grid Layout. Later on, in 2017, driven by author demand, the CSS Working Group decided that spacing out items was useful across all layout methods. So they dropped the grid- prefix and created the shorthand gap property (and its longhands row-gap and column-gap) that applies to both Grid and Flex layouts.

- grid-gap: 2em;
+ gap: 2em;

Browsers followed suit, and started treating grid-gap as an alias for the newly created gap property. But — BUT! — that didn’t mean that gap also immediately worked with Flex layouts in browsers. While aliasing grid-gap to gap was quick and easy, there was a massive gap (pun intended 🥁) between it being specced to work with Flex layout and a browser actually supporting “Flexbox gap”.

During this limbo, there was no straightforward way to detect whether the browser supported “Flexbox gap” or not. You couldn’t do @supports (gap: 1em) because the browser would truthfully say “Yes! I support that!” (for Grid). You also couldn’t do @supports (display: flex), as the browser also said yes. And combining both — through @supports (display: flex) and (gap: 1em) — also didn’t work because the browser only checks whether it can parse the passed in <suppports-condition>s, not whether they have a combined effect.

/* This only checks if CSS can parse these declarations, not if they work together */
@supports (display: flex) and (gap: 1em) {
  …
}

So right after Chromium shipped “Flexbox Gap” in 2020, I filed w3c/csswg-drafts#5062 at the CSS Working Group asking how to properly feature detect gap also playing nice with Flexbox.

Turns out this was already on their radar, and the request got duped into the more generically worded w3c/csswg-drafts#3559 from 2019, which was about “testing support of properties and values with partial implementations”.

~

Enter named-feature()

The discussion in w3c/csswg-drafts#3559 eventually turned silent but at the end of 2023 it became very relevant again as browsers were about to support align-content having an effect on display: block containers.

Two months later, the Working Group accepted a proposal by David Baron to solve this. I really like David’s original pitch to solving this problem:

I think it might be reasonable to add specific, one-off solutions when we think they’re important enough. They’d need to be for significant enough features that we’d be willing to add an extra keyword to CSS for them, and that an implementor wouldn’t miss that it needed to be implemented, and that we’d be willing to write specific web-platform-tests to verify and monitor the results closely to make sure the rollout doesn’t go wrong. And we could probably choose reasonably verbose keywords.

The result is named-feature(), which is a function that allows you to feature-detect very specific behaviors or behavior changes that cannot be caught using the traditional @supports-checks. The function require a keyword as its argument, and the list of allowed keywords is predefined in the spec.

@supports named-feature(some-specific-behavior) {
  /* CSS for browsers that support 'some-specific-behavior' here … */
}

Keywords are only added for the handful of tricky edge cases where feature detection is highly requested but impossible to do using other mechanisms in CSS.

~

Real-World Use Cases

Currently the CSS Working Group has specified two keywords for named-feature(). I’m quite happy about these, as I proposed both of them at the Working Group 🙂

~

1. Transform-Aware Anchor Positioning

CSS Anchor Positioning initially shipped without taking transforms into account. Because author demand was huge, things changed and the spec got updated to support this use-case. The change shipped in Chrome 144, is included in the upcoming Safari 27, and is currently being prototyped in Firefox.

While you could already easily feature detect Anchor Positioning itself, you couldn’t detect if the browser respects transforms on the anchor. To solve this, you can now use the keyword that was resolved on in w3c/csswg-drafts#13678: anchor-position-follows-transforms.

@supports named-feature(anchor-position-follows-transforms) {
  /* ✅ The browser supports transform-aware anchor positioning! */
}

While not originally slated for their 27.0 release — the release that includes Transform-Aware Anchor Positioning — I reached out to the Safari team to add support for named-feature(anchor-position-follows-transforms), and the PR got merged earlier this month. Firefox is currently prototyping Transform-Aware Anchor Positioning, and they announced that they will ship named-feature() simultaneously.

~

2. Single-Axis Scroll Containers

Another feature that needs more advanced feature detection is the recent change that allows containers to be a scroller for only a single axis. This fixes a longstanding issue where position: sticky on one axis gets trapped by an unrelated scroller on the other axis, as detailed in my post on CSS sticky per axis.

While you can feature detect Single-Axis Scroll Containers by throwing lots of JavaScript at the problem, there was no way to do this in CSS. But thanks to my proposal in w3c/csswg-drafts#13677, we now have the single-axis-scroll-container keyword for use with @supports named-feature(single-axis-scroll-container):

@supports named-feature(single-axis-scroll-container) {
  /* ✅ Single-axis scroll containers are supported, so sticky per axis just works! */
}

~

# Browser Support

Support for named-feature() looks as follows:

Chromium (Blink)

✅ Supported in Chrome 150

Firefox (Gecko)

☑️ Supported in Firefox 156 (soon in beta)

Safari (WebKit)

☑️ Supported in Safari Technology Preview

What is more interesting though, is support for the various keywords.

Support for anchor-position-follows-transforms:

Chromium (Blink)

✅ Supported in Chrome 150

Firefox (Gecko)

☑️ Supported in Firefox 156 (soon in beta)

Safari (WebKit)

☑️ Supported in Safari Technology Preview

Support for single-axis-scroll-container:

Chromium (Blink)

✅ Supported in Chrome 153

Firefox (Gecko)

❌ No Support. There is no bug tracking this yet.

Safari (WebKit)

❌ No Support. There is no bug tracking this yet.

~

What about other features?

If you are wondering about the older features I mentioned here, and why they don’t have a keyword, here goes:

CSS gap with display: flex

All browser support this by now. Too much time has passed since it shipped and this feature detection through named-feature() becoming available.

align-content having an effect on display: block

Chrome did it’s homework and did (internal) testing against the top X websites. The only notable breakage that came out of that was Netflix being broken (they had align-content on an element that switched from block to flex through a media query) but we got them to fix their CSS.

And then there’s also these features that are currently hard to detect:

Style Queries

I have filed w3c/csswg-drafts#13975 for it a while ago. The tricky thing with it though, is that a lot of time has passed since Chrome first shipped it in March 2023 and Safari in September 2024 … so shipping a check now would yield a lot of false negatives. Additionally, there is a documented workaround to feature detect style queries.

For completeness: Other at-rules — such as @property — can be feature detected using at-rule().

~

Spread the word

Feel free to reshare one of the following posts on social media to help spread the word:

• 🦋 Bluesky
• 🦣 Mastodon
• 💼 LinkedIn

~

~

~

The Problem: Targeting Multiple Prefixed Classes

When coming up with classnames for use in the class attribute, a common practice is to use a prefix to retain some grouping or hierarchy. You might be familiar with classes like .btn-primary, .btn-secondary, .btn-danger, and so on.

To apply a base style to all of these buttons today, you typically have to list them all out, or introduce a separate .btn base class:

/* Adding a base class */
.btn {
  padding: 0.5rem 1rem;
  border-radius: 4px;
}

/* Or listing everything... yuck! */
.btn-primary,
.btn-secondary,
.btn-danger {
  padding: 0.5rem 1rem;
  border-radius: 4px;
}

Some of you even resort to substring-matching attribute selectors, but those selectors perform badly:

/* Works, but performs badly */
[class^="btn-"],
[class*=" btn-"] {
  padding: 0.5rem 1rem;
}

Looking at a benchmark I ran (CLI results here) using css-selector-benchmark, a regular class selector ran at more than 6000 runs/s, whereas [class*=" btn-"] dipped as low as 328 runs/s … that’s almost 20 times slower and also 3ms out of your frame budget just to match an element!

~

The Solution: The Class Prefix Selector

Just two weeks ago, at the CSS Working Group F2F meeting in Berlin (August 2026), we resolved to add a dedicated Class Prefix Selector to the CSS Selectors Level 5 specification. The idea was originally pitched by Lea Verou back in 2024 (w3c/csswg-drafts/#10001), and also championed by Lea (and Tab Atkins—Bittner) at the F2F.

The syntax is incredibly straightforward:

.btn-* {
  padding: 0.5rem 1rem;
  border-radius: 4px;
}

That’s it! The -* part at the end makes the selector a Class Prefix Selector and will try to match any class that begins with that hyphen-separated prefix.

It’s a huge win for utility classes and design systems, allowing you to easily target groups of related elements without having to bloat your HTML payload or write fragile attribute selectors.

~

What about the empty string?

An interesting question that popped up during the discussions is whether .foo-* should match the empty string (w3c/csswg-drafts/#14291), meaning: should .foo-* also match an element that merely has the .foo- class?

While the exact default behavior is still being ironed out, currently the selector is specified to only match classes that start with the prefix and that have at least one character beyond the prefix (and the first such character beyond the prefix is not also a hyphen)

So no, class="foo-" would NOT be matched by .foo-*, which I think is fine. That same selector also would not match class="foo--", which is also probably fine.

~

What about non-dashes?

The Class Prefix Selector is currently limited to hyphen-separated prefixes, at least at first. Other separators, like _, might be added as possibilities in the future as we receive request from authors like yourself about what would be needed.

One thing that is already quite clear right now, is that there must at least be some separator. Arbitrary prefixes (like .foo*) are not going to be allowed for at least two reasons:

1. You could accidentally overselect: .foo* would also match .footer
2. Selector Performance: Browsers typically create buckets for class selectors for quick selector matching. Adding arbitrary wildcards defeat that optimization entirely. With the - as a separator, the browser can already create extra buckets when parsing the HTML, long before CSS ever gets parsed and starts matching.

Similarly, wildcards in the middle of a selector (such as .card-*-primary) are also not going to be allowed.

~

Why not reuse the |= selector?

In the issue thread and during the CSSWG call, the idea of reusing the existing “dash match” attribute selector (|=) was brought up. Instead of introducing the new .foo-* syntax, what if we just wrote [class|="foo"]?

I also initially thought this would be a good idea, but the working group ultimately decided against it for valid reasons.

First of all, there are a few issues with the |= selector that prevent it from being a drop-in solution for wildcard class matching:

• The |= operator was originally created for language attributes (like [lang|="en"]). By design, it matches the hyphenated prefix (like en-us) but also the exact value (en). As argued on the call, this is a massive footgun for utility classes: if you want to target all .bi-* icons, you probably don’t want those styles accidentally leaking to a standalone .bi base class.
• To make the |= selector work for class matching, its behavior would need to change. The way the selector currently works is by only checking values from the very beginning of an attribute’s string. If you have an element with multiple classes like <div class="card btn-primary">, the selector [class|="btn"] would completely fail to match it because btn-primary isn’t at the start of the class attribute.
• Selector Performance (see previous mentions about this).

The most important reason, though, is The Bigger Picture™ for wildcards in CSS: there is an ongoing, larger effort within the CSSWG (also championed by Lea) to standardize wildcards across all of CSS

By choosing -* as the syntax for prefixes, the syntax can later be reused for future extensions such as wildcard attribute names (e.g. [data-*]) and wildcard (custom) element names (e.g. custom-framework-*).

Because the |= selector only works for attribute values, it is effectively a dead end for those other use cases.

# Browser Support

Since this was literally just resolved at the CSSWG F2F in Berlin two weeks ago, browser support is currently non-existent. To follow along with the progress – if any – you can follow these browser issues:

Chromium (Blink)

❌ No Support

Subscribe to CrBug #550093337 to follow along.

Firefox (Gecko)

❌ No Support

There is no bug tracking this yet.

Safari (WebKit)

❌ No Support

There is no bug tracking this yet.

This feature is still in its early days and needs to be fleshed out further, so could be that it takes a few more years before you can use it in production …

# Feature Detection

You can feature detect support with a regular @supports rule:

@supports selector(.foo-*) {
  /* Browser has support */
}

The following CodePen uses this and will light green when you browser supports it:

See the Pen
CSS Class Prefix Selector Support test by Bramus (@bramus)
on CodePen.

Spread the word

Feel free to reshare one of the following posts on social media to help spread the word:

• 🦋 Bluesky
• 🦣 Mastodon
• 💼 LinkedIn

~