HTML Next
A markup-first authoring layer for HTML: leveled modules that compile to, and polyfill on, the web platform.
Status of this document
An unofficial editor's draft for discussion at Stage 0. It is not a standard and does not represent the position of the W3C, the WHATWG, or any browser vendor.
HTML Next does not fork or compete with the HTML Living Standard. It specifies an authoring layer above the platform today, with the explicit aim that its modules are adopted into the platform through the normal standards process. Everything normative here currently constrains HTML Next tooling, not the browser, that boundary is what would move if a module graduates.
Abstract
HTML Next is a public proposal to grow HTML into a reliable, reactive application layer. The platform gained a rendering engine, a networking stack, and a component mechanism, but never an application authoring model, so for fifteen years the primitives authors need most (reusable typed components, control flow, data sources, reactivity) were reinvented, incompatibly, in one JavaScript framework after another. This proposes those primitives as part of the platform, expressed as markup, so the web gains a standard, reactive application layer of its own, one that degrades to plain HTML and outlives any single framework.
In plain terms: if you build web interfaces, HTML Next lets you write components, control flow, and reactivity as HTML, and run the same file natively in the browser or compile it to React, Vue, or Svelte, with no build step and no eval().
<!-- You write a component as markup -->
<x-button variant="solid">Save</x-button>
<!-- It becomes a real native button — no wrapper, no shadow root -->
<button data-component="x-button" data-variant="solid">Save</button>You author a component once, as literal browser-parseable HTML with an inert typed contract. HTML Next lowers it into idiomatic Vanilla DOM, React, Vue, and Svelte, or interprets the same source directly in Chromium, Firefox, and WebKit, with no Custom Elements and no eval(). One semantics, many backends.
Introduction & goals
The missing layer
The web platform kept advancing: fetch, Grid, ES modules, even Custom Elements and Shadow DOM. Yet HTML's own vocabulary for building applications barely grew. The primitives an app author reaches for every day were never added to markup, so the same wheel was reinvented, again and again and incompatibly, in userland. Ask HTML, natively, for any of these and the answer is still "load a framework":
| Application need | Native HTML answer | What everyone does |
|---|---|---|
| Reusable typed component with a documented API | None (Custom Elements are untyped, imperative) | React/Vue/Svelte component |
| Conditional & repeated markup | None | v-if, {#each}, .map() |
| Declarative reactivity | None | hooks, refs, runes, signals |
| Bind a control to state | None | controlled inputs, v-model |
| Declare a data dependency | None | fetch-in-effect, loaders, resources |
Every cell in the right column is an incompatible language. Web Components addressed packaging and skipped the language problem: a place to put a component but no declarative way to write one.
What HTML Next is
A markup-first authoring language realized by two kinds of conforming implementation that must produce observably equivalent output:
An ahead-of-time compiler lowers HTML Next to idiomatic Vanilla DOM, React, Vue, Svelte, CSS, contracts, and docs: a multi-target converter in the spirit of Mitosis.
A browser runtime reads the same source, lowers it against the live DOM without Custom Elements or dynamic code, and subscribes to its declared dependency graph.
So HTML Next is two things at once: an authoring layer you can use today, through the converter and the polyfill, and a set of platform proposals meant to graduate into HTML itself, feature by feature, the way Declarative Shadow DOM and invoker commands went from userland shim to shipped native syntax.
It is tempting to reach for the TypeScript-to-JavaScript analogy, and it misleads on every point that matters. TypeScript is a superset that deliberately never becomes JavaScript, changes nothing about the runtime, and proposes no additions to the language; adopting it commits a whole file to a new compiler. HTML Next is the opposite on all three counts: its aim is to become native HTML, it is written as real proposed additions to the platform, and it is purely additive markup. You add one feature to an ordinary HTML file, one tag at a time, and everything else stays exactly as it was, a plain HTML file is already valid HTML Next. There is no rewrite and no buy-in.
How HTML Next versions
There is no single umbrella version, no big-bang HTML Next 1.0. The project versions the way the platform itself does today, on three borrowed axes:
CSS stopped shipping monolithic versions after 2.1; it is developed as independent modules, each at its own Level (Selectors 4, Color 5, Grid 2). HTML Next does the same: Components, Templating, Reactivity, and Types are modules, each advancing by Level on its own evidence; none blocks another.
HTML is a Living Standard; new features incubate as proposals (WICG explainers), and JavaScript's move through TC39 stages 0 to 4. HTML Next is a set of proposals at Stage 0 today; maturity is a stage, not a number announced in advance.
Where one label helps a community rally, the precedent is CSS's dated Snapshot: a snapshot is nothing more than a named, dated set of modules each pinned at a specific Level (e.g. Components L1, Templating L1, Reactivity L1, Types L1), not a big-bang release. That is the only sense in which HTML Next carries a version, and it names only what already ships. Big-bang numbered rewrites (XHTML 2.0) die; leveled modules and incubated proposals do not.
The worked example is Web Components. HTML Next's shipping modules (components, templating, reactivity, scoping) route around the platform's broken component mechanism today. The parts a compiler cannot fix, extending native elements and reconciling Shadow DOM, are a later module Level and an upstream platform proposal, because those require platform change.
What HTML Next fixes
The platform made three bets on application authoring: reactivity, style scoping, and Web Components. HTML Next answers each as a module, by level rather than all at once. Components lower to real native elements today; reactivity and style scoping are specified and advancing by level; Web Components is the one it routes around rather than adopts, broken in ways no compiler can repair.
Reactivity
Why it's broken
- HTML has no declarative reactivity, so every framework invented its own (VDOM diffing, proxies, compilers, signals), and they don't interoperate.
- Reactivity is expressed in framework-specific JavaScript, not markup: it can't be inspected, typed once, or ported.
- Most runtime approaches need dynamic code (
new Function) or ship a diffing engine to every user.
HTML Next's answer
- Reactivity is a declarative dependency graph in markup:
<state>,<computed>,<data>, and:/bind:bindings over a small pure expression language. - The graph is statically analyzable: dependencies are read off the parsed expression, not discovered at runtime.
- One semantics, many backends: it lowers to React state, Vue refs, Svelte runes, or a signal-based browser runtime. No
eval, CSP-clean.
Web Components
Why it's broken
- No portable way to extend a native element: customized built-ins (
is=) are formally opposed by WebKit, soextends HTMLButtonElementhas no cross-browser path.2 - The autonomous alternative, an
<x-button>host, forfeits the native button's form submission, role, and focus, rebuilt by hand. - Form participation dies at the shadow boundary; it needs
ElementInternals, which stabilized cross-browser only in 2023.6 - Imperative ceremony, string-only props with no inspectable contract, and cross-boundary styling friction round it out.1
Polyfill today, platform change upstream
- HTML Next needs custom elements not at all: templating and native lowering emit a real
<button>, so native semantics stay the browser's. - The component is typed markup with a declarative contract and compiles to idiomatic React, Vue, and Svelte: portable, not a walled garden.
- What a compiler cannot fix (WebKit's refusal of customized built-ins, form association across a boundary) is platform work for a later module Level and an upstream proposal.
- Its likely shape: templating that opts into an extension of Declarative Shadow DOM, closing the styling and form gaps DSD left open.
Shadow DOM & scoping
Why it's broken
- Shadow DOM gives all-or-nothing encapsulation. Styling across the boundary is painful (
::part,::slotted); global theming and shared styles fight it. - Declarative Shadow DOM and its SSR story arrived years late and remain awkward.
- Forms, focus, and accessibility relationships behave surprisingly across the boundary.
- Most authors want scoping, not isolation, and are forced to take both.
HTML Next's answer
- A component's styles are scoped to it by default: its
<style>affects only its own markup, not the whole page, and with no shadow boundary, the scoping the browser already offers with CSS@scope. Encapsulation without isolation. - Degrades to plain CSS in the light DOM: theming, cascade, and shared design tokens keep working.
- Real isolation becomes an opt-in target capability, never the mandatory tax Shadow DOM makes it today.
- A later Level takes the isolation case further with an extension of Declarative Shadow DOM that fixes DSD's styling and form-participation gaps instead of inheriting them.
The record: Web Components in practice
Whether Web Components failed by design or only because they were never fully leveraged does not matter to an author choosing a component model today. In their shipped form they did not become the web's component layer, and the clearest evidence is the ecosystem's own behavior.
Champions retreated The flagship "components will replace frameworks" project was wound down.
Google's Polymer entered maintenance mode in 2018 and was superseded by Lit (a thin rendering helper) because raw custom-element ergonomics were not enough on their own.8
Framework authors opted out The people who build component models did not build them on this one.
The creator of Svelte set out in 2019 why he does not use Web Components: Shadow DOM forces CSS into JavaScript; the property/attribute split forces boilerplate; slotted content renders eagerly; the registry is one global namespace; and the DOM is "an awkward interface for building interactive applications."1 React, Vue, Svelte, and Solid each built their own model instead.
The extension mechanism is blocked There is no cross-browser way to extend a native element.
Customized built-in elements ship in Chromium and Firefox, but WebKit's formal standards position is to oppose them and not implement them.23 The only spec-sanctioned route to reusing native semantics has no portable path.
Interop lagged a decade The largest UI library could not talk to them properly until 2024.
For most of the feature's life React could not pass an object or array to a custom element, nor listen to its events; the gap was tracked on Custom Elements Everywhere. Full support arrived only in React 19, December 2024, more than a decade after custom elements were proposed.45
Architecture
Three kinds of element
HTML Next keeps three layers strictly distinct; the mistake Web Components made was conflating them.
Conforming implementations
HTML Next is a language specification: it is implemented, not executed. An implementation is a converter or a polyfill; the governing conformance contract is observable equivalence: the same native DOM, state, events, accessibility, and errors for the same source.
The Next Web Working Group owns the specification and this site. The reference implementation (the html repository) is a separate project: the polyfill and component bridge.
Progressive enhancement runs the other way from a hypermedia library: in htmx the server round-trip is the baseline and script enhances it; in HTML Next the rendered HTML is the baseline and the browser enhances it. A server-rendered page delivers its initial content as ordinary HTML that displays, is accessible, and is indexable with no JavaScript.
How far past that first render a no-JavaScript page reaches depends on the kind of reactivity:
- State that maps to a native primitive (a toggle to
<details>orpopover, selection to:checked, validity to constraint validation, relational reactivity to:has()) lowers to HTML and CSS and keeps working with no script. - Genuinely dynamic reactivity (data fetches, values computed over live input, lists over changing data) needs the runtime, or a server-round-trip fallback that is still open.
So the guarantee is a no-JS render, and a no-JS application exactly as far as the reactivity has a native lowering.
Conformance & module levels
Keywords follow RFC 2119, scoped to HTML Next tooling. A tool must emit an explicit unsupported-feature diagnostic, never silent literal fallback, for any construct above its level.
| Module | Level 1: normative today | Direction |
|---|---|---|
| Components | One native-root component per file; typed contract; default slot. Shipping | L2 named/typed slots, as, imports |
| Targets | Vanilla, React, Vue, Svelte, contract JSON, CSS, docs. Shipping | L2 SSR, static/email |
| Browser runtime | One-shot lowering, no Custom Elements, no eval. Shipping | L2 reactive updates |
| Templating | None yet | L1 $each, $if, $match, <value> |
| Reactivity | None yet | L1 state, computed, data |
| Types | string, boolean, number, enum. | L3 URLs, colors, refs, content models |
| Isolation | None yet | Upstream Declarative-Shadow-DOM extension; native-element extension upstream |
Module specifications
Each capability is an independently-levelled module. This list is generated from the site's navigation.
Adoption
A spec convinces no one; four things do, in order.
Author one component; compile it to the framework you already ship, and polyfill it in the browser with no build. Adoption risk is one file, not a rewrite.
Each fix is a grievance a developer already has: reactivity lock-in, Custom Element ceremony, Shadow DOM pain.
No new mental-model tax: it reads like markup, survives the parser, and works under CSP. A component invocation even degrades to its inline children before any runtime runs.
One jaw-drop demo (one file → five targets + live browser) and a name that promises the next HTML.
Governance & the working group
The Next Web Working Group exists today as a GitHub organization. The path to a recognized standards venue, cheapest rung first:
- The org is the specs and the site. Publishes standards; ships no tooling.
- A separate reference implementation, the
htmlpolyfill and component bridge (a multi-target converter, in the spirit of Mitosis). - An explicit stage process, proposal → incubation → Level N, modeled on TC39 stages and WHATWG workstreams.
- A Community Group listing for legitimacy without W3C membership.
- Upstream the wins. A mature module's endgame is a proposal into WHATWG/CSSWG/TC39.
Open questions
Genuine design questions, not yet settled:
| Area | Question |
|---|---|
| Imports | Component-definition and registry-scoping syntax; untrusted-import trust model. |
| Slots | Named & typed slots, fallback content, slot props, complete content models. |
| Data | Request, caching, cancellation, concurrency, and stale-response semantics. |
| Rendering | SSR serialization, hydration ownership, no-runtime fallback, static/email targets. |
| Expressions | and/or/not vs. &&/||/!; missing-data value; object/list literals; safe navigation. |
| Reactive scheduling | Browser scheduling, teardown, and dynamic-index dependency breadth. |
| Parser contexts | SVG, MathML, table, and select insertion modes. |
| Extension | How consumers extend the element and type vocabulary; capability negotiation. |
Shopify Liquid (constrained template language, filter pipelines), Squarespace JSON-T (data-context-first templating), Vue & Svelte (markup-first components, scoped styles, browser-safe binding syntax), Mitosis (one source → many framework targets), and XSLT (declarative tree transformation) are inputs and evidence; none is adopted as the default answer.
References
Informative. Retrieved September 2026; standards positions and browser versions as published.
- Rich Harris. "Why I don't use web components." DEV, 20 June 2019. dev.to/richharris/why-i-don-t-use-web-components-2cia
- WebKit. Standards position on customized built-in elements: oppose. Issue #97, 2022. github.com/WebKit/standards-positions/issues/97
- WebKit Bugzilla 182671. "Implementation (or not) of customized builtins." bugs.webkit.org/show_bug.cgi?id=182671
- Custom Elements Everywhere. Framework interoperability tests. custom-elements-everywhere.com
- React 19. Full custom-elements support, December 2024. react.dev/blog/2024/12/05/react-19
- WebKit. "ElementInternals and Form-Associated Custom Elements" (Safari 16.4, 2023). webkit.org/blog/13711
- WebKit. "Declarative Shadow DOM" (Safari 16.4; Firefox 123, 2024). webkit.org/blog/13851
- Lit. "Lit for Polymer users": Polymer superseded by Lit; in maintenance since 2018. lit.dev/articles/lit-for-polymer-users