The current source has two different registries:
- 18 shared primitives are the cross-device vocabulary used by capability negotiation.
- 42 Web-only widgets are available in the Web runtime but are not a portability promise for other renderers.
Those counts describe the current checkout, not a permanent API-size guarantee. Before making a portability statement, use the primitive name and target support matrix rather than a widget’s visual resemblance to a native control.
Add a custom name carefully
A blocklet can declare custom primitive names, or ARC can scan a Web Component manifest so DSL and structural validation accept those names. That extends the set of names an author may use. It does not create a renderer implementation on every device, add a degradation chain, or grant the component a privileged data/action capability.
Use a custom type when the target and its component contract are deliberately part of the product. Use a shared primitive when the intended meaning fits an existing portable contract. Do not call a Web-only widget a “primitive” merely because a page needs it.
Keep three component concepts separate
| Concept | Owns | Does not imply |
|---|---|---|
| AUP shared primitive | Portable semantic intent | Identical native presentation everywhere |
| Web widget | A Web runtime capability | Support by every device renderer |
| Web Device component | Reusable site HTML/CSS/interaction presentation | A new cross-device AUP primitive |
Unknown/custom types without a degradation chain pass through unchanged. They are not automatically converted to text. Plan a concrete target acceptance test before publishing a custom-type example.
See Primitive taxonomy and evidence. The site-component layer belongs to the target's Web Device documentation, not to this portable-primitive reference.