Native HTML Components

Research synthesis · July 21, 2026

Native HTML component systems

How to produce uniform, data-driven objects for application-like HTML output using semantic markup, modern CSS, native browser behavior, and the smallest credible runtime.

01
Default architecture

Compile structured data into complete semantic HTML before delivery.

02
Browser boundary

HTML has behavior and structure, but no native loops or arbitrary data binding.

03
Runtime policy

Add JavaScript only for search, persistence, routing, live data, and comparable stateful needs.

Central decision

Use a native-first static component compiler: structured knowledge in, validated and uniform application-grade HTML out.

The final artifact may contain no runtime JavaScript and still provide responsive composition, disclosure, overlays, forms, status indicators, print output, and offline portability.

01 · Component taxonomy

Different mechanisms solve different problems

“Component” is not one browser feature. Reuse, semantics, visual consistency, encapsulation, and runtime behavior are separate architectural concerns.

A Default

Generated components

Build-time renderers

Typed data records are validated and expanded into complete HTML before the artifact reaches the browser.

B Core

Semantic components

Native HTML elements

Elements such as <article>, <aside>, <figure>, and <dl> communicate meaning independently of styling.

C Core

Visual components

CSS contracts

Classes define anatomy. Data attributes define finite states. Custom properties provide design tokens. Container queries handle recomposition.

D Selective

Encapsulated components

Declarative Shadow DOM

Provides style isolation and slots for a static instance. It does not supply data binding, loops, imports, or repeated instantiation.

E Runtime

Behavioral components

Custom elements

Use when an object needs lifecycle callbacks, runtime attribute updates, asynchronous work, domain events, or framework-neutral distribution.

F Missing natively

Data rendering

Loops, binding, and imports

Interoperable HTML still has no native JSON binding, template loop, conditional expression, reusable partial import, or client-side include primitive.

Reuse

Who creates each instance?

  • Build-time generator
  • Server-side renderer
  • Runtime JavaScript

Rendering

What does the browser receive?

  • Complete semantic HTML
  • Inert templates awaiting code
  • Custom elements awaiting upgrade

Isolation

How are styles contained?

  • Scoped naming and cascade layers
  • @scope
  • Shadow DOM at distribution boundaries

02 · Architecture

Compile the knowledge model into the presentation model

The generator is a small compiler pipeline. It validates records, escapes content, selects semantic structures, and emits a complete document with optional progressive enhancement.

Native-first static component compiler architecture Structured data flows through schema validation and typed renderers into semantic HTML, shared CSS, and a self-contained artifact. A small optional JavaScript layer enhances capabilities that cannot be represented declaratively. Structured data JSON / TypeScript records Validation Schema · escaping · policy Renderers Semantic component contracts Self-contained HTML artifact Complete content · shared CSS · metadata Native disclosure · forms · overlays · print Offline portability · no hydration required Optional enhancement layer Search · persistence · routing · live data
The browser receives the final object instances. It does not need to understand the source schema or run the rendering engine.

Knowledge model

Facts remain independent of presentation

interface ResearchFindingV1 {
  schemaVersion: 1;
  id: string;
  claim: string;
  explanation: string;
  confidence: "high" | "medium" | "low";
  classification:
    | "fact"
    | "analysis"
    | "inference"
    | "recommendation";
  sourceIds: string[];
  tags: string[];
}

Presentation model

Instances contain readable content

<article
  class="finding"
  data-confidence="high"
  data-classification="fact">

  <p class="finding__type">Finding</p>
  <h3>Declarative HTML is viable</h3>
  <p>Complete readable content lives here.</p>
</article>

03 · Browser support

Separate required core from progressive and limited features

“Modern browser” is not a sufficient enterprise contract. Each capability should be classified by whether the complete experience depends on it.

Capability July 2026 posture Runtime JS Recommended use
Semantic HTML objects Core No Default structure and accessibility foundation
Shared CSS classes and tokens Core No Default visual component system
<template> Core but inert Required to instantiate in-browser Build input, runtime source, or Declarative Shadow DOM wrapper
Declarative Shadow DOM Progressive No Selective isolation boundary
Autonomous custom elements Core platform Usually yes Runtime component APIs and lifecycle
Customized built-in elements Limited Yes Avoid as an enterprise interoperability foundation
<details> Core No Disclosure and secondary evidence
Grouped <details name> Progressive No No-JS mutually exclusive accordions
<dialog> Core Not always Focused modal or non-modal surfaces
Popover Progressive No Definitions, previews, small menus, contextual help
Invoker commands Progressive No Declarative dialog and command control
Size container queries Core No Component-level responsive recomposition
@scope Progressive No Selector scoping without Shadow DOM
Container style queries Progressive No Token- or state-driven visual adaptation
Customizable select Limited No where available Progressive enhancement only
hidden="until-found" Limited No Optional searchable disclosure, not core navigation
CSS anchor positioning Limited No Enhancement only; do not require for layout
Native HTML includes Unavailable — Handle at build, server, edge, or runtime layer
Native loops and data binding Unavailable — Handle at build, server, or runtime layer

The table is horizontally scrollable within its own boundary on narrow screens. It does not force page-level horizontal overflow.

04 · Native demonstrations

Browser-managed behavior can replace substantial routine JavaScript

The examples below are rendered as real native controls. The theme switch is the only enhancement script on this page.

Disclosure and accordion

Grouped <details name> provides mutually exclusive panels.

Build-time rendering

Data is validated and converted into visible semantic HTML before delivery.

Runtime rendering

JavaScript creates or updates instances after the document loads.

Popover

Contextual information appears in the browser top layer.

Declarative dialog control

Recent invoker commands can open and close dialogs without custom event code.

Methodology

Validation sequence

Separate standards from experiments. Classify browser support. Test no-script behavior. Red-team accessibility, print, overflow, and recovery.

Native metrics

<meter> represents bounded values; <progress> represents task completion.

Static artifact fit 92% 92%
Implementation readiness 4 / 5 4 of 5

Declarative Shadow DOM

The parser creates an encapsulated static instance. No custom-element definition is required.

Encapsulated object

Static isolation works

The instance is isolated, but it was still authored or generated as a complete instance.

Semantic key-value object

A definition list is often a better metadata component than a generic grid of divisions.

Renderer
Build-time TypeScript
Runtime
Optional enhancement only
Primary output
Complete semantic HTML
Isolation
Light DOM by default

05 · Support policy

Three tiers prevent accidental dependence on immature features

The full document must remain understandable and usable at the required core tier. Newer capabilities may enrich behavior without becoming a single point of failure.

Tier 1

Required core

  • Semantic HTML
  • Links, forms, and disclosure
  • Grid, Flexbox, custom properties
  • Cascade layers and container queries
  • Print, SVG, and responsive media
Tier 2

Progressive native enhancement

  • Popover
  • Grouped <details>
  • Declarative Shadow DOM
  • Invoker commands
  • @scope and style queries
Tier 3

Limited or experimental

  • Customizable select internals
  • hidden="until-found"
  • Anchor positioning
  • Typed attr()
  • HTML Modules and template proposals

06 · Red-team findings

The main failures are architectural, not syntactic

Most fragile implementations arise from confusing static presentation with runtime application behavior, or from using CSS and Shadow DOM to solve problems they do not own.

Naming risk

Calling every static artifact a SPA

A long, application-like document is not a conventional SPA unless it performs route, state, and DOM transitions at runtime.

Control: use “single-document application artifact” when runtime behavior is intentionally absent.

Boundary risk

Treating Shadow DOM as reuse

Shadow DOM isolates an existing instance. It does not instantiate a shared template or bind arbitrary data.

Control: use light DOM internally and Shadow DOM only at real distribution boundaries.

Content risk

Encoding meaningful content in attributes

Attributes alone do not create visible, searchable, printable prose. Another renderer is still required.

Control: keep user-facing meaning in semantic descendants.

Interaction risk

CSS-only application state machines

Checkbox and fragment hacks create weak focus behavior, brittle history, hidden controls, and difficult recovery.

Control: use native controls first, then small JavaScript when the interaction is genuinely stateful.

Discovery risk

Search and disclosure conflict

Hidden panels and isolated trees can reduce find-in-page, fragment navigation, copy, and print reliability.

Control: keep primary content in document flow and disclose only secondary detail.

Quality risk

Template consistency without validation

A template does not prevent missing fields, invalid nesting, unsafe HTML, heading errors, or uncontrolled variants.

Control: validate both the input schema and rendered document.

07 · Implementation contract

Standardize the compiler, not only the card styles

A durable system defines the data contract, semantic output, responsive behavior, validation policy, and capability tier for each component.

Use semantic HTML + CSS when

The object primarily presents known content

Best for findings, recommendations, risks, sources, diagrams, comparison rows, and documentation sections.

Use Declarative Shadow DOM when

The object crosses an isolation boundary

Best for third-party embeds, isolated demonstrations, and components inserted into unknown host applications.

Use a custom element when

The object owns a behavioral API

Appropriate for lifecycle, async work, runtime updates, domain events, or cross-framework packaging.

Use small JavaScript when

The capability cannot be represented declaratively

Examples include fuzzy search, persistence, language switching, routing, drag-and-drop, dynamic charts, and live data.

Every component renderer defines

  • Accepted schema and required fields
  • Semantic root and heading-level policy
  • Permitted children and empty states
  • Finite variants and native states
  • Escaping and sanitization policy
  • Responsive and print behavior

Every artifact validation pass checks

  • Keyboard and focus behavior
  • Find-in-page and fragment navigation
  • Print and offline behavior
  • Mobile overflow containment
  • Forced colors and reduced motion
  • No-script completeness and recovery

Recommended operating rule

Ship the smallest runtime that preserves the complete knowledge product.

When JavaScript fails, the reader should lose convenience—not the report, its evidence, or its conclusions.

08 · Sources and provenance

Primary standards and browser-platform references

Browser status evolves. Revalidate progressive and limited features against the current Baseline dataset before treating them as required capabilities.