What Arrived in HTML 2023–2026: search, popover, Invoker Commands, Customizable Select and What's Next

Version note: This post follows the November 2026 state of the HTML (HyperText Markup Language) Living Standard and Baseline; support data comes from the web-features 3.46 and baseline-browser-mapping 2.11 packages, and the feature checks were tested with Chrome 158 and WebKit 27.2 (Playwright 1.65).

Guess First

Bookstore's Angular 22 application uses a list of features we saw in this series: search, inert, details with name, popover, dialog.requestClose(), Invoker Commands, :open, autocorrect, field-sizing. As of November 2026, all of them are Baseline. Someone on the team says "let's use the Baseline ones without fallbacks, Angular targets Baseline anyway".

Are they right? How many of these really work in every browser Angular 22 officially supports? A hint: Angular's target isn't "Baseline", it's "Baseline widely available" on a specific date.

In the previous post, "Accessible Markup Basics and HTML in Frameworks", we saw how to check the HTML frameworks produce, and with that the topic posts of the series are done. In this last post we step back and look at the last three years as a whole: what arrived in HTML between 2023 and 2026, what hasn't arrived yet, and how we decide to use these in a production application today.

No Versions, Only Dates

As we saw in the first post of the series, HTML has no versions such as "HTML5" or "HTML6"; the WHATWG's (Web Hypertext Application Technology Working Group) Living Standard is continuously updated. And the day a feature enters the spec is not the day you can use it. That is why we read change through Baseline dates, not version numbers.

As a reminder, there are two dates. A feature becomes newly available on the day it works in the current version of every core browser (Chrome, Edge, Firefox and Safari, desktop and mobile); the year in a label such as "Baseline 2025" is this date. 30 months later it becomes widely available, because by then most people on older versions are assumed to have updated. What matters in practice: a newly available feature is in the latest version of every browser today, but not for a user who is a few versions behind.

The 2023–2026 Timeline

The Baseline dates of the features we used in the series, from web-features data. The widely available date is calculated by adding 30 months to the newly available date:

Two things stand out in the table. The first is the pace: from 2025 on, a new feature in HTML, or in CSS (Cascading Style Sheets) directly tied to HTML, became Baseline almost every quarter, and most of them cluster around dialogs, popovers and forms. The modal, the dropdown panel and the accordion, for many years the job of JavaScript libraries, are now part of the platform. The second is how far away the widely available dates are: Invoker Commands won't be widely available until mid-2028.

One date may look odd to you: popover. It had been in Chrome since 116, yet its Baseline date is January 2025. The reason is that iOS Safari's support only counts as complete from version 18.3; Baseline takes the date of the last browser in the core set to join. This detail will come up again below when we compare with Angular's target.

Not Baseline Yet

In the series we also used a few features that are limited availability as of November 2026. Each has a different missing browser and a different way to use it today:

• closedby (post 6): in Chrome 134 and Firefox 141, not in Safari. A browser without support ignores the attribute and the dialog keeps closing with Esc; usable today.
• popover="hint" and interestfor (post 6): hint is in Chrome 151 and Firefox 153, interestfor only in Chrome since 149. In a browser without support, hint behaves like manual; wait, except for unimportant information such as a tooltip.
• Customizable select (post 7): in Chrome 135 and Safari 27, not in Firefox. Because it falls back cleanly to the classic select, it is usable today as long as options have text.
• hidden="until-found" (post 6): in Chrome 102 and Firefox 148, not in Safari. Use it if the content can also be reached another way.
• sizes="auto" and JPEG (Joint Photographic Experts Group) XL (post 8): the former arrived with Safari 27 but is counted as unsupported again in web-features data because of a bug; JPEG XL was turned on with Chrome 155 and Firefox 158, and is not in Edge. Both are safe today when written with a fallback.

The story of sizes="auto" contains a lesson: web.dev's September 2026 roundup announced it as Baseline newly available, but web-features data later started counting Safari 27 as unsupported because of a bug that breaks drawing of SVG (Scalable Vector Graphics) images (WebKit bug 324661). Baseline status is not a one-way ladder; data can be corrected and a feature can step back down. When deciding, rely on current data, not on a blog announcement.

Interop 2026 and What's Next

The best way to guess which features will soon become Baseline is to look at Interop: a compatibility effort whose areas browser makers (Apple, Google, Microsoft, Mozilla and Igalia) choose together every year and track with tests. One of the focus areas of Interop 2026, announced on 12 February 2026, is directly this series' subject: dialog and popover additions. According to WebKit's announcement, this area covers closedby, popover="hint" and :open. :open already became Baseline in May 2026; Safari support for closedby and hint is expected during the year.

The same Interop also has "investigation" areas; these are not compatibility goals yet, but preparation. JPEG XL, WebVTT (Web Video Text Tracks) and accessibility testing are on this list. Customizable select and interestfor are not in Interop 2026; I saw no commitment that Firefox will bring either of them this year.

Angular 22's Browser Target and Baseline

Back to the guessing question. Since v20, Angular has defined the browsers it supports in terms of Baseline: each major version targets the set of browsers that is widely available on a chosen date. For Angular 22 that date is 2026-05-07. A script that feeds this date to Baseline's browser mapping and compares the support of every feature we used in the series against that set:

import { features } from 'web-features';
import { getCompatibleVersions } from 'baseline-browser-mapping';

// Angular 22's browser target: Baseline widely available as of 2026-05-07
// (I leave out the Android versions for readability; in this list they match desktop)
const target = Object.fromEntries(
  getCompatibleVersions({ widelyAvailableOnDate: '2026-05-07' })
    .filter(b => !b.browser.endsWith('_android')).map(b => [b.browser, b.version]));

const ids = ['search', 'inert', 'details-name', 'popover', 'requestclose', 'invoker-commands',
  'open-pseudo', 'toggleevent-source', 'autocorrect', 'field-sizing', 'sizes-auto',
  'dialog-closedby', 'popover-hint', 'interest-invokers', 'customizable-select', 'hidden-until-found'];

const older = (a, b) => {
  const [x, y] = [a, b].map(v => v.split('.').map(Number));
  return x[0] - y[0] || (x[1] ?? 0) - (y[1] ?? 0);
};

console.log('Angular 22 target:', Object.entries(target).map(([b, v]) => `${b} ${v}`).join(', '));
for (const id of ids) {
  const { baseline, baseline_low_date: low, baseline_high_date: high, support } = features[id].status;
  const status = baseline === 'high' ? `widely (${high})` : baseline === 'low' ? `newly (${low})` : 'limited';
  // if the oldest version in the target doesn't support the feature, a fallback is needed
  const gaps = Object.keys(target).filter(b => !support[b] || older(support[b], target[b]) > 0)
    .map(b => support[b] ? `${b}<${support[b]}` : `${b}:none`);
  console.log(`${id.padEnd(20)} ${status.padEnd(20)} ${gaps.length ? 'fallback: ' + gaps.join(' ') : 'ok'}`);
}

Angular 22 target: chrome 119, edge 119, firefox 119, safari 17, safari_ios 17
search               widely (2026-04-13)  ok
inert                widely (2025-10-11)  ok
details-name         newly (2024-09-03)   fallback: chrome<120 edge<120 firefox<130 safari<17.2 safari_ios<17.2
popover              newly (2025-01-27)   fallback: firefox<125 safari_ios<18.3
requestclose         newly (2025-05-27)   fallback: chrome<134 edge<134 firefox<139 safari<18.4 safari_ios<18.4
invoker-commands     newly (2025-12-12)   fallback: chrome<135 edge<135 firefox<144 safari<26.2 safari_ios<26.2
open-pseudo          newly (2026-05-11)   fallback: chrome<133 edge<133 firefox<136 safari<26.5 safari_ios<26.5
toggleevent-source   newly (2026-05-11)   fallback: chrome<140 edge<140 firefox<145 safari<26.5 safari_ios<26.5
autocorrect          newly (2026-09-11)   fallback: chrome<153 edge<153 firefox<136
field-sizing         newly (2026-06-16)   fallback: chrome<123 edge<123 firefox<152 safari<26.2 safari_ios<26.2
sizes-auto           limited              fallback: chrome<126 edge<126 firefox<150 safari:none safari_ios:none
dialog-closedby      limited              fallback: chrome<134 edge<134 firefox<141 safari:none safari_ios:none
popover-hint         limited              fallback: chrome<151 edge<151 firefox<153 safari:none safari_ios:none
interest-invokers    limited              fallback: chrome<149 edge<149 firefox:none safari:none safari_ios:none
customizable-select  limited              fallback: chrome<135 edge<135 firefox:none safari<27 safari_ios<27
hidden-until-found   limited              fallback: firefox<148 safari:none safari_ios:none

The first line gives the oldest versions Angular 22 supports: Chrome, Edge and Firefox 119, Safari 17. Of the list, only search and inert are in that whole set; both are widely available. For every remaining newly available feature, there are browser versions that Angular officially supports but that don't know the feature. For example, every Safari version from 17 to 26.1 for Invoker Commands, and Firefox 119–124 and iOS Safari 17.x–18.2 for popover.

So the answer to the claim in the guessing question is no. "Baseline" and "Angular's target" are not the same thing: Angular targets widely available, that is, 30 months back; a feature being newly available says nothing about it being in the browsers within those 30 months. The rule can be set like this: if your target is a widely available date, features that became widely available before that date go without fallbacks; everything else goes with progressive enhancement or a polyfill.

Don't take this as specific to Angular. The same question applies to a Razor application or to any build that defines its browser list with Browserslist: write your target as a date or a list of versions and check features against it. Running the script above in CI (Continuous Integration) ties the "can we use this feature?" discussion to data.

Feature Checks and the Test Environment Trap

The first step of a fallback is checking at runtime whether the feature exists. The checks I use for the features in the series, and their results in two engines:

const pw = require('playwright');

// feature checks for progressive enhancement
const checks = {
  'invoker commands': () => 'command' in HTMLButtonElement.prototype,
  'popover': () => 'popover' in HTMLElement.prototype,
  'dialog closedby': () => 'closedBy' in HTMLDialogElement.prototype,
  'popover="hint"': () => { const d = document.createElement('div'); d.popover = 'hint'; return d.popover === 'hint'; },
  'interestfor': () => 'interestForElement' in HTMLButtonElement.prototype,
  'customizable select': () => CSS.supports('appearance', 'base-select'),
  ':open': () => CSS.supports('selector(:open)'),
  'hidden="until-found"': () => 'onbeforematch' in HTMLElement.prototype,
};

(async () => {
  for (const name of ['chromium', 'webkit']) {
    const browser = await pw[name].launch();
    const page = await browser.newPage();
    const results = [];
    for (const [feature, fn] of Object.entries(checks)) {
      results.push(`${feature}=${await page.evaluate(fn) ? 'yes' : 'no'}`);
    }
    console.log(`${name} ${browser.version()}: ${results.join(', ')}`);
    await browser.close();
  }
})();

chromium 158.0.8127.18: invoker commands=yes, popover=yes, dialog closedby=yes, popover="hint"=yes, interestfor=yes, customizable select=yes, :open=yes, hidden="until-found"=yes
webkit 27.2: invoker commands=yes, popover=yes, dialog closedby=yes, popover="hint"=yes, interestfor=no, customizable select=yes, :open=yes, hidden="until-found"=yes

In Chromium everything is there; that is expected. The striking line is WebKit's: closedby, popover="hint", customizable select and hidden="until-found" appear to be present. But according to the data above, released Safari versions don't have closedby, hint or until-found. The reason, as I also noted in the series' "Native Interactive Elements 1" post, is that Playwright's WebKit build follows WebKit's development branch. Tests passing in WebKit don't mean a Safari user sees the same behaviour today. Make support decisions with web-features data, and behaviour tests with real Safari where possible.

Two notes on the checks themselves. For CSS features, CSS.supports() and @supports in CSS are the safest way. For HTML attributes, checking for the DOM (Document Object Model) property is common but not always enough: a browser that doesn't support a value such as popover="hint" still knows the property, so you have to assign the value and read it back. In CSS there is another subtlety with a new pseudo-class: a single unrecognised selector in a selector list invalidates the whole rule. If you write details[open], details:open, a browser that doesn't know :open won't apply details[open] either. The list inside :is(details[open], details:open), on the other hand, is forgiving; it skips what it doesn't recognise.

A Decision Table for Bookstore

Applying all of this to Bookstore gives this table:

The table's logic rests on a single question: what does the user lose when the feature doesn't work? If they lose nothing (closedby, autocorrect) or what they lose is decoration (the images in a customizable select), use it today. If they lose a function (a dialog that doesn't open without Invoker Commands, a cart that is always visible without popover), either write a fallback or show with analytics that those browsers' share is acceptable.

In Production

The dates and versions in this post are a snapshot of November 2026. The web-features package publishes new versions regularly; read a feature's status from current data, not from a blog post written a year ago, not even from this post. The Baseline box on MDN (MDN Web Docs) pages and the web-features explorer show the same data.

Keep the target browser list in one place in the codebase and make it visible to everyone. In Angular this decision comes with the framework version; but if your own analytics show a meaningful share of users on browsers older than what Angular supports (enterprise customers, devices that don't update), comparing that share with the target is your job. The reverse holds too: if almost all users are on the latest versions, weigh the cost of the fallback you'd write for a newly available feature against what it gains.

When adding a polyfill, watch its size and how it loads: load it only in browsers that need it, after a feature check. A polyfill sent to every user is a cost most of them never need; measuring that is covered in the Web Performance series.

Common Pitfalls

First, treating "Baseline" and "widely available" as the same. A newly available feature is missing for users a few versions behind.

Second, assuming your framework's browser target covers every HTML feature you use. Angular 22 supports Safari 17; Invoker Commands arrived in Safari 26.2.

Third, taking Playwright's WebKit for Safari. Make support decisions with data.

Fourth, putting a new pseudo-class in the same selector list as the old one in CSS. A browser that doesn't recognise it drops the whole rule; use :is().

Fifth, treating a Baseline announcement as permanent. As the sizes="auto" example shows, data can be corrected.

A Small Experiment

★☆☆ Change the date in support.mjs from 2026-05-07 to today's date and compare the output. Which features became "ok", which still need a fallback?

★★☆ Find your project's browser target (Angular version, Browserslist or a list of versions) and adapt support.mjs to it. Add three new HTML or CSS features you use to the list and share the result with your team.

★★★ Make Bookstore's "Delete book" confirmation (post 6) work in browsers without Invoker Commands too: write a small click handler that loads only when needed, after a 'command' in HTMLButtonElement.prototype check, and test the behaviour in a browser that doesn't support Invoker Commands (e.g. an older Safari or a cloud-based real-device testing service).

The series ends here. Across twelve posts, from the skeleton to landmarks, from forms to dialog, from tables to the head, we chose the right element for the right meaning and measured it at every step. There are two natural ways to continue from here: the upcoming Accessibility (a11y) series for the depth of ARIA (Accessible Rich Internet Applications), focus management and screen reader testing; and the upcoming CSS3: Flexbox, Grid and Modern CSS series for the look of these elements, dialog and popover animations and anchor positioning.