New Things You Should Know About HTML Here in Mid 2026 – Master.dev Blog

Nah, I wouldn’t do that to you. We’re going to do some other elements, attributes, and HTML fun that might have slipped under your radar in recent years. Mostly 2026 stuff, but I’m not terribly strict about it, as you’ll see.

Permissions Elements (like )

There was a element tested out a while back, but that experiment is dead. Instead, we’re going to get more specific elements for things you need permissions for, like the element.

I kind of like the direct semantics of a button for a specific permission; that’s nice. But I think the bigger story is “recovery”, as they call it. Have you ever had a browser ask you for permissions for some kind of access and you’re like “No!”? That’s fair. And it’s the point. APIs behind permission prompts are sensitive. It’s fair that you don’t want some website to know exactly where you are in the world, for example.

But when you said “No!” — it’s also fair that you might change your mind at some point in the future. But at this point, those APIs are kinda locked, and the only way to change your mind is to dig around in your browser preferences, find where you made that choice, and remove or reverse it. A permissions-specific button makes it much easier to change your mind. Just click it again; the button will ask again, and you can make a fresh choice. There is a variety of data showing that the recovery flows are much more successful.

The Element

This new element essentially makes a specialty you can click to trigger a geolocation event. And, like I explained above, be asked whether that’s OK with you, regardless of what you may have allowed or disallowed in the past.

<geolocation onlocation="handleLocation(event)">
  <button onclick="handleLocationFallback(event)" autolocate>
    Use location
  button>
geolocation>Code language: HTML, XML (xml)

function handleLocation(event) {
  console.log("coordinates got!");
  
}

function handleLocationFallback(event) {
  navigator.geolocation.getCurrentPosition(handleLocation);
}Code language: JavaScript (javascript)

I’m a fan! I like the enforced accessibility.

Browser support is Chrome-only, but also isn’t a massive concern, as non-supporting browsers will essentially see like a meaningless and the

inside will handle the permissions flow just like it traditionally has. These elements will be firm progressive enhancements.

The Element

This one is for the camera and microphone:

 manages the entire flow for camera and microphone access. It captures user intent, manages the browser prompt, and delivers the MediaStream object to the application.

<usermedia id="media-ctrl">
  <button>Enable camera and microphonebutton>
usermedia>Code language: HTML, XML (xml)

Like all these permission prompts, you get a literal prompt in the browser.

Because it’s a literal on-screen button, even if you deny the permission, it gives you a chance to change your mind later without having to dig through settings to figure out how to do that. That “recovery” data is strong:

Cisco observed that users who initially denied permissions were only about 10% likely to successfully grant permissions using legacy prompts, but that rate jumped to more than 65% with the new element.

There is also planned and elements for video-only and audio-only situations, respectively.

---

The Element

Here’s another Chrome-led one with a good premise:

Web app installation is fragmented. Every browser has its own set of entry points, for example address-bar icons, menu items, and prompts. Developers have limited control over when and how the install flow is surfaced.

Install web apps with the new HTML install element

So rather than rely on how different browsers surface web app installation (PWA’s, as it were), we make a semantic button for the job we can place wherever we like on our sites. Safari on iOS is notorious for making this difficult, leading many developers to believe it’s an intentional downplaying of the web (and an upplaying of their app store). So we’ll see if we ever get a cross-browser implementation of this.

<install 
  installurl="https://awesome-app.com/"
  manifestid="https://awesome-app.com/?source=pwa">
>
  <a href="https://awesome-app.com/">Launch Awesome Appa>
install>Code language: HTML, XML (xml)

Note that to make a website installable, you need a web application manifest. And to make a good installable web app, you’re probably doing things like caching data with a service worker.

In a simple twist of fate, desktop Safari on macOS has an “add to Dock” feature that does not require a web app manifest.

---

The Element

Wait! That’s not new! But being able to custom design it is from CSS. It’s a story right now because Chrome was first out of the gate with it, but now Safari supports it too.

There is plenty to know about it, because you need to opt in to it, and styling certain parts of it requires new pseudo-elements and such. First, you need to opt in to the styleability like:

select,
::picker(select) {
  appearance: base-select;
}Code language: CSS (css)

Then you’ve pretty much got carte blanche to do whatever you want.

But there is a lot more to know. You can put a:

<select>
  <button>
    <selectedcontent>selectedcontent>
  button>

  <option>...Code language: HTML, XML (xml)

In there, which clones the contents of the that is currently selected, and you can style it specially. There is the ::picker(select) which is the dropdown parent itself. The select::picker-icon which is the indicator the whole thing even is a dropdown. And a bunch more. Brecht has a huge series going deep on all this.

---

Web Components

Web Components have been around for quite a while, but they aren’t just one thing; they are a collection of APIs that evolve independently.

Scoped Element Registries

You can just register a custom element the classic way:

customElements.define("my-element", MyElementClass);Code language: JavaScript (javascript)

But you could also put it into a Custom Element Registry, like:

const myCustomRegistry = new CustomElementRegistry();
myCustomRegistry.define("my-element", MyElementClass);Code language: JavaScript (javascript)

Once you have a Custom Element Registry, you can tell any given Shadow DOM to use that one.

const shadow = footer.attachShadow({
  mode: "open",
  customElementRegistry: myCustomRegistry
});Code language: JavaScript (javascript)

Then, whatever you put in that particular shadow will use the new custom registry.

The point is, you can have different/multiple registries. Which… is pretty niche. But we can imagine a situation where a big fancy company has a versioned design system and their new fancy weather widget uses v3 of their design system, which has a and all the rest of the elements on the rest of the page are stuck slumming it on v2. In other words: this is an escape hatch for same-named but different-versioned custom elements.

Declarative Shadow DOM

Declarative Shadow DOM became widely supported more like 2024, I just feel like it’s still relatively new and not particularly well known so it’s going on the list, gosh dang it.

It basically means: Shadow DOM without needing JavaScript (and costing a bunch of potentially repetitive HTML). I could do this and get a fully legit Shadow DOM:

<my-element>
  <template shadowrootmode="open">
    <h1><slot name="title">Fallback Titleslot>h1>
  template>

  <span slot="title">The Titlespan>
my-element>Code language: HTML, XML (xml)

If there were CSS on the page like h1 { color: red; } it wouldn’t target this h1 because of the Shadow DOM boundary. Here’s that basic example and a more fleshed-out generated example.

This feature, to me, is meant to be the output of a build process for Server-Side Rendering (SSR) of web components. Here’s an example of that.

Reference Target

Let’s say you’ve got a outside a Shadow DOM, but an

inside the Shadow DOM. The kind of thing that might happen in a design system with a or whatever. Labels and inputs need to reference each other for accessibility. Typically the for attribute of the label matches the id of the input. This can work now with this reference target feature.

Here’s an example with declarative shadow DOM:

<label for="name">Your namelabel>

<fancy-input id="name">
  <template shadowrootmode="open" shadowrootreferencetarget="real-input">
    <span class="decoration">✎span>
    <input id="real-input" type="text">
  template>
fancy-input>Code language: HTML, XML (xml)

It’s out in Chrome and behind flags in Safari and Firefox, so really not far off.

Declarative CSS Module Scripts

I’m a big fan of CSS Module Scripts, the kind like this:

import sheet from './styles.css' with { type: 'css' };Code language: JavaScript (javascript)

But this is not that. And I think it’s only an experimental Chrome thing for now. But it’s interesting!

<script type="importmap">
  {
    "imports": {
      "foo": "https://example.com/foo.css"
    }
  }
script>
<my-element>
  <template shadowrootmode="open">
    <link rel="stylesheet" import="foo">
    <p>Inside Shadow DOMp>
  template>
my-element>
Code language: HTML, XML (xml)

---

HTML Includes

Not the Web Components Kind, The Streaming Kind.

Why my mind thinks “HTML Includes”, I don’t think of “HTML imports”, the web components feature that sadly never saw the light of day, I think of the very basic…

<main>
  <p>Blah blah blah.p>
main>

Code language: HTML, XML (xml)

That light of day is starting to peek out for this again. The concept of declarative partial updates is alive, which is related to HTML streaming. It all feels too new to really see how it’s all going to work. But perhaps, if you’re literally streaming some HTML, they can be new declarative elements that allow you say, hey that new