Input

Inputs are flexible, theme-aware, and designed to adapt to both general and specific use cases (like emails, pricing, or location).

🧭 When to Use an Input

Use an Input when you need a single-line text field where the user can type or edit information.
Inputs are ideal for forms, filters, account creation, search, and basic data capture.

Avoid using Inputs for long-form content or messages—use a Text Area in those cases.

🧩 Input Composition

Each Input includes:

• Label – Explains the purpose of the field

• Field – The container that reflects interaction state (hover, active, etc.)

• Input Element – The editable text field

• Hint Text (optional) – Helps guide the user or clarify validation rules

Each of these parts can be swapped or styled independently, but they are bundled together to ensure visual and structural consistency.

🎨 Input Types (Samples)

These types reflect common use cases and may include built-in prefixes, suffixes, or masking logic:

• Default – A generic, catch-all input

• Email – May include an envelope icon or validation formatting

• Domain – Typically used with “.com” suffix or domain-only formatting

• Price – Includes currency symbol (pre-element) and optional decimal enforcement

• City – May support autocompletion or paired with geolocation icons

These samples are styled using token-based variants in Figma and serve as patterns to duplicate and customize.

🚥 Input States

Default – The standard state, including active, hover, and filled variants handled via the Field component.
Error – Visually distinct with a red border, optional error icon, and helper text beneath (e.g., “Please enter a valid email”).

State-specific styling is inherited from the Field layer, keeping logic consistent across all form components.

♿ Accessibility Considerations

From a design perspective:

• Maintain clear labels above each Input

• Use color and text to indicate errors or help—not color alone

• Ensure focus states are highly visible, especially for keyboard users

From a code perspective (if implemented):

• Link Label and Input using for and id

• Connect helper or error text using aria-describedby

• Use aria-invalid="true" when the Input is in an error state

• For inputs with icons or extra elements, use aria-hidden="true" on purely decorative items

✅ Best Practices

• Don’t rely solely on placeholder text—it disappears on interaction

• Group related inputs using shared spacing and layout tokens

• Keep hint text short and helpful. If you need to explain more, consider tooltips

• Pre-fill Inputs where possible to reduce friction

• For Inputs like email or price, validate early and communicate clearly