Widget Registry

The problem

Every table on the wiki is a bespoke section frame. I have now hand-written the same one three times:

• adom/stm32f103c8t6 — pinout table
• adom/repo-ownership — the app/owner/rule ownership list
• the footprint-variant tables

Each copy re-implements the same five things: a filter box, click-to-sort headers, distinct-value faceting, content-height reporting to the host, and the theme tokens. They are not identical — they have already drifted in header casing, empty-state wording and sort stability — and a reader cannot tell which behaviours a given table has without reading its source.

Two of the six registered widgets (adom-symbol-variants, adom-footprint-variants) are themselves tables with this logic inlined.

The proposal

Register one generic ::adom-table{src="..."}. Nothing about it is component-specific: it takes a JSON array and renders it.

::adom-table{src="/adom/repo-ownership/render/ownership.json" facet="owner" sort="app" heading="adom applications"}

Accepted shapes — a plain array (columns inferred from the first row), {columns, rows} for explicit order, or {columns:[{key,label,align}], rows} for explicit labels. Attributes: columns heading filter facet sort dim.

The immediate consumer is adom/repo-ownership, whose whole point is being the company's source of truth for who owns what — it should not depend on a one-off frame I maintain by hand.

Related, and why the timing matters

Building this surfaced a real runtime bug: inline <script type="application/json"> data was invisible whenever the widget definition was already registered when the parser reached the element, because connectedCallback fires on the opening tag before children exist. Inline JSON is the documented path for a README (the readme frame is an opaque origin, so fetch is blocked there), so a table widget was going to hit it constantly. Fixed in adom-inc/adom-widget#2.

PR: adom/widgets#1 — https://wiki.adom.inc/adom/widgets/prs/1