Components

Use these UI components to construct interactive, layout-level surfaces on BHDicaire.com.

Every component represents a named interface piece with a stable purpose. Reuse existing patterns whenever possible; create new ones only when functional differences are intentional and repeatable. For author-facing Markdown tags, jump to Shortcodes.

Accordion, blockquote, and tab behaviour are authoring shortcodes — details, pullquote, and tabs — not duplicated here. A page opening with a missing-artifacts callout describes a component that is specified but not yet built; the missing artifacts page tracks them all.

Component pages use shared interface metadata so this section can be grouped, filtered, and cross-linked with the shortcode reference over time. The canonical fields are interface_kind, interface_category, interface_status, interface_preview, interface_implementation, interface_consumers, and related_interfaces. Every implemented component has a source-backed interface_implementation map and an Interface manifest; specified components intentionally wait for source evidence. Follow the component migration recipe before adding a manifest.

Every implemented component needs observable evidence. Use component-preview for a self-contained state, including mode="inline" for small utilities. Direct real markup or an active shortcode is valid when an extra frame adds no information. Declare interface_preview: "page" when the current page shell renders the component, "render-hook" when the example is produced by Markdown rendering, or "consumer" with interface_preview_page when real page data supplies the state. Consumer evidence uses component-relationship; specified interfaces use implementation-status until implementation exists. Do not invent decorative mock-ups.