Component — Inline definition

Status: v0.1.0 — Draft.

R1 — Anatomy

• Term rendered inline in body text with a 1px dotted underline (text-decoration: underline dotted currentColor).
• On trigger: floating popover with:
  • Term (bold).
  • 1–3 short lines of definition.
  • Optional "Learn more" link (single, never multiple actions).

R2 — Trigger

Dismisses on:

• Pointer leave (desktop)
• Blur (keyboard)
• Outside-tap (touch)
• Esc (any modality)

R3 — Semantic HTML

• Wrap term in <dfn> element — the HTML element specifically for "defining instance of a term".
• <dfn> made focusable via tabindex="0" so keyboard users can trigger.
• Popover: role="tooltip" with aria-labelledby (term id) and id referenced by <dfn>'s aria-describedby.

R4 — Accessibility

• Definition content also rendered in DOM (visually hidden) immediately after the term so screen-readers receive it without firing visual hover.
• For non-sighted users, <dfn> carries title attr with the definition as fallback if popover JS doesn't load.

R5 — Density limits

• Author SHOULD use sparingly — no more than 1 inline definition per short paragraph (≤ 3 sentences).
• If a paragraph needs 3+ defined terms, switch to a sidebar glossary or a parenthetical inline gloss.

R6 — i18n

• Both term and definition translatable per specs/i18n/contract.kmd.
• Definitions stored with a stable key (term.<slug>.definition) so the same definition can be reused across pages.

R7 — OUIA

Per specs/testing/ouia-test-hooks.kmd:

• data-ouia-component-type="InlineDefinition"
• data-ouia-component-id="<term-slug>" (defaults to slugified term).
• data-ouia-safe="true" always.

Não-escopo

• Auto-link to a separate glossary page (out of v0; the popover is the glossary entry).
• Definition versioning / per-tenant override (specialized scope).