Complete the semantic HTML element surface and native control behaviour

[Ernxst]

Problem

Shared browser/desktop components cannot use ordinary table tags or dl/dt/dd, and input type=radio is unavailable. Consumers must substitute generic elements with explicit ARIA roles and implement radio selection, roving tabIndex, and arrow-key navigation themselves.

The JSX declarations at fork commit 535c6b6 still omit these element families. See packages/react/jsx-runtime.d.ts and jsx-dev-runtime.d.ts. Existing h1–h6 and ul/ol/li aliases already help.

Scope

Audit the complete HTML element surface in one pass and publish an explicit supported/missing/deferred inventory. Implement related families together rather than adding one tag per consumer workaround. Start with:

• Tables: table, caption, thead, tbody, tfoot, tr, th, td, colgroup, col; header relationships and row/column spans.
• Description lists: dl, dt, dd.
• Grouping and metadata: fieldset/legend, figure/figcaption, time, output, and other omitted text/content elements identified by the inventory.
• Native form controls, including input type=radio and checkbox: checked/defaultChecked, grouping, disabled state, labels, keyboard activation and focus behaviour.
• Meter/progress elements, coordinated with the separate numeric accessibility issue.

This is more than adding JSX aliases. Each family needs its DOM-compatible attributes, implicit roles, accessible names/states/relationships, applicable keyboard behaviour, and honest layout support. Distinguish semantic table support from browser table-layout support; do not claim the latter solely because roles project correctly. Identify GPUI gaps at their actual layer.

Acceptance

• An inventory accounts for the complete HTML surface, including explicit decisions for intentionally unsupported elements.
• Supported elements typecheck in both JSX runtimes and project correct native accessibility nodes without consumers repeating implicit roles.
• Representative browser/native fixtures verify names, hierarchy, spans, state changes, and keyboard behaviour where applicable.
• Native radio groups handle selection, arrow wrapping, Space and Tab according to browser behaviour without application-authored radio plumbing.
• README documents support and limitations.

Related existing issues: #353 (global ARIA on nodes without roles), #358 (plain input/textarea accessibility), #355 (value-text naming). Reuse those issues rather than duplicating their work.

[Ernxst]

Design input from the #480 profiling, since it constrains what a table element surface should look like here.

A dense table built from ordinary host nodes is the worst case for this renderer. Measured today, 600 rows of 8 columns as a CSS grid draws in 111.7 ms per frame; the same data through <virtual-list> with fixed-width cells draws in 4.9 ms, and stays flat as rows grow. GPUI re-lays out the whole window every frame (zed#24260), so a table's cost scales with total cells, not visible ones.

Two findings that bear on the design:

1. Column track sizing is not the expensive part. max-content columns and fixed 140px columns measured the same (111.7 ms against 112.5 ms). Pinning widths is not an optimisation.
2. Pinning widths is what makes row virtualisation possible. A column track shared across the grid cannot be sized from rows that were never built, so automatic content-sized columns and row virtualisation cannot both hold. Browsers resolve this with table-layout: fixed; virtualised table libraries resolve it by making the table model own column sizes.

So if this surface grows real table elements, the useful question is not only which tags parse, but whether a table of a few hundred rows can be drawn without building every cell. Worth designing for from the start: explicit or precomputed column widths as a first-class option, with virtualised rows reusing that geometry, rather than auto sizing everywhere and retrofitting virtualisation later.

table-layout: auto semantics stay correct for small tables, where building every cell costs nothing.

[Ernxst]

Correcting something implied in my earlier comment: a native table element would not escape the per-node cost, so this issue should not be framed as the answer to #480.

The existing custom elements do not escape it either. packages/native/src/markdown/render.rs:469 builds one gpui div per line inside its loop:

lines = lines.child(div().h(px(m.code_line_height)).flex_none().child(text));

each with its own accessibility value. So a custom element skips the JS retained tree, the reconciler and apply_styles, and still pays element construction, layout and paint — which is where the profiling in #480 says the cost actually is. A 240-row table element built the same way is still ~2000 gpui elements, which is ~18 ms on the measured curve.

What a table element can honestly buy, against the measurements on #480:

• apply_styles, worth 2-3% of a frame;
• a flat arrangement instead of a nested one, worth about ×1.33 at equal node count;
• whatever accessibility annotation costs, measured at +0.49 µs per node, since a native element can derive semantics internally rather than paying per-node role and aria-label handling.

Useful, and not an order of magnitude. An order of magnitude needs either fewer elements — <virtual-list>, which already exists — or direct painting in the manner of Zed's EditorElement, which shapes and paints its own lines and hand-rolls text layout, hit testing, selection and accessibility for that surface. That is a much larger undertaking, and presumably why Zed did it once.

The accessibility point belongs here too. This renderer has no table, tbody, tr, th or td, and the native host surface accepts only div, text and virtual-list. So ARIA roles are the only way a consumer can express table semantics at all — and #480 measures that annotation as per-frame cost. A consuming application carries a lint suppression on its table components whose justification is precisely that there is no table element to use. Whatever this surface becomes, it should let a table express its semantics without paying for them on every frame.

[Ernxst]

Sharpening the previous comment: the existing custom elements have two different shapes, and a table resembles the expensive one.

Prose is about one element per block. markdown/render.rs:391 flattens a block's text into a single accessibility_value and hands it to selectable_text, so a paragraph is roughly one element regardless of length.

Fenced code is per line. The loop I quoted before (render.rs:445-470) is markdown's fenced-code path, not its prose path — it uses code_line_height and the mono font, and builds one div plus text per line.

<code> is per line and denser still. custom_elements/code.rs:193 loops the source lines, and line 230 is:

content = content.child(row.child(ctx.text(line_ix, line.to_string(), Some(runs))));

a row element plus its text child for every line. With the gutter enabled, lines 213-223 add another div holding chrome_text for the line number. So roughly three to four nodes per line with line numbers, against markdown prose's one per block.

A table is structurally much closer to the code case: every cell is content that needs its own geometry, selection key and accessible name. So a table element built the same way is thousands of elements for a few hundred rows, however it is written in Rust, and the saving over host nodes stays what the #480 measurements say it is — apply_styles at 2-3%, arrangement at about ×1.33, and per-node annotation at +0.49 µs — rather than an order of magnitude.

The prose path is the interesting counter-example, though: it shows a custom element can collapse many logical items into one element when the content does not need per-item geometry. Whether any of a table's structure can be collapsed that way — a row as one element rather than N cells — is the question worth asking when this surface is designed, because that is where the order of magnitude would come from.

[Ernxst]

The design question in the previous comment has an answer already in this codebase: <diff> keeps per-row geometry and virtualises, instead of choosing.

custom_elements/diff.rs:1 describes itself as "a virtualized, syntax-highlighted, selectable unified diff", ported from Comet, a real GPUI application. Line 328 is gpui::list(state, move |ix, _window, _app| { ... }), and the header explains why: the scroll path uses gpui::list() "so the closure can capture an Rc and build only visible rows". Every row keeps its own geometry, selection key and accessibility; only the visible ones are built. It also carries two further defences in its props — maxLines to cap the row count (diff.rs:111, 142) and collapsedPaths to collapse whole files.

So the shapes available to a custom element are three, not two:

Shape	Per-item geometry	Items built
Markdown prose (render.rs:391)	No	One element per block
Fenced code, <code> (code.rs:193)	Yes	All of them
<diff> (diff.rs:328)	Yes	Only visible

That makes "how much of a table's structure genuinely needs per-cell geometry" possibly the wrong question. <diff> never had to answer it: it kept full per-row structure and made the count small instead.

One caveat that bears directly on a table. diff.rs:19 records that only the scroll path virtualises — "The default flow path renders the same rows in a column so a parent can be the scroller." A table that wants its parent to own scrolling therefore loses windowing exactly as <diff> does in flow mode. If this surface grows a table element, which side owns the scroller is not a layout detail, it is the difference between building visible rows and building all of them, and it should be an explicit part of the API rather than an emergent consequence.

The contrast with <code> sharpens what to avoid: two dense custom elements in the same codebase, one windowed and one not, and <code> builds three to four nodes for every line of a block however large.

So the template for a table element looks like <diff>: gpui::list for rows, per-row roles and accessible names preserved, an explicit cap for the pathological case, and a documented answer to who scrolls.