Component

Text field

Enter text

Required if chrome has input
ContractText field
Job
Enter text
Requirement
must specify if chrome has input
States / rules
Label ≠ placeholder; error; disabled
Specified means
Label always visible
Hardest context
Placeholder-as-label
Example

“Title” label

Counter-example

Placeholder “Enter title…” as label

Baseline vs product decision

Building Blocks baseline supplies

  • Label/value/error relationships.
  • Keyboard and touch operation.
  • States for focus, disabled, error, and data-entry feedback.
  • Responsive rules that preserve label and error meaning.

The consuming product still decides

  • Field copy and data semantics.
  • Validation policy and when feedback appears.
  • Formatting/masking decisions grounded in the data type.
  • Actual Catalog maturity for the product.

Anatomy

This is documentation anatomy, not a public API shape.

01Label

Persistent visible name for the value being collected.

02Input surface

The editable control and its current value.

03Help / description

Optional guidance connected to the field when needed.

04Error / state message

Explains validation or system state and recovery.

05Focus indicator

Shows keyboard location independently of hover.

Preview

Preview — not a published component API.

Usage

Job: Enter text.

Label always visible

When not to use

Do not use placeholder text as the only label.

Variants

The checklist row does not authorize this page to invent a final component API. Where the source rule names a variant, preserve it; otherwise keep the implemented variant set minimal and job-driven.

States & behavior

Label ≠ placeholder; error; disabled

Universal interactive baseline

Default, Hover, Focus, Active/Pressed, and Disabled apply to interactive controls. Error, Loading, Empty, and Success apply where the component takes or reports data.

Hardest-context test

Building Blocks baseline recommendation: Exercise long labels, errors, autofill, dark appearance, zoom, and 375px layouts without losing the relationship between label, input, and recovery.

Accessibility

  • Use native semantics whenever they match the job.
  • Keep keyboard focus visible and distinct from hover.
  • Do not rely on color alone for state.
  • Maintain touch-operable targets and no hover-only actions.
  • For composite/overlay controls, document focus movement, Escape, and return focus as applicable.

Responsive behavior

Document sm/md/lg behavior explicitly: whether the component reflows, collapses, changes density, or stays structurally the same. Preserve touch targets and avoid hover-only behavior.

Theme comparison

The component job and interaction contract stay stable while product expression changes.

Base
Editorial
Native

Tokens

Bind the implementation to semantic roles for surface, text, border, focus, spacing, shape, and motion as needed. Actual token names must come from the implemented Foundation; this demo deliberately does not mint package-level token names.

Code / Storybook

No shared Building Blocks implementation is claimed here.

When this component exists in code, this section should link to its source and Storybook stories for executable states, Controls, viewport, accessibility checks, and interaction tests. The documentation page remains responsible for job, guidance, source contract, product decisions, themes, and Catalog lineage.