FSM Full Stack Masterclass
Platform under construction
CSS course badge

Components

Advanced

Component States

Component states describe how a component behaves across normal, hover, focus, active, disabled, loading, selected and error situations.

.tab[aria-selected="true"] { background: var(--green); }
.tab:focus-visible { outline: 3px solid var(--focus); }
.tab[data-loading="true"] { opacity: .55; }

Component mental model

A component is not done until its states are done.

The default state is only one version of a component. Real users hover, focus, press, wait, fail validation and encounter disabled actions.

Good component CSS plans states before launch. Otherwise every edge case becomes an emergency override.

States can come from pseudo-classes such as :hover and :focus-visible, attributes such as disabled and aria-selected, or data attributes from JavaScript.

Default

The ordinary resting state.

Interactive

Hover, focus and active communicate response.

System

Loading, disabled and selected communicate status.

Error

Problem states need clear recovery paths.

Visual model

See the parts of the component before styling the surface.

Default

Ready

The component can be used.

Hover

Invited

Pointer users see feedback.

Focus

Keyboard

Keyboard users see position.

Loading

Waiting

The action is in progress.

Good CSS versus fragile CSS

Stateful component CSS

.tab[aria-selected="true"] { background: var(--green); color: #061018; }
.tab:focus-visible { outline: 3px solid var(--focus); }
.tab[disabled], .tab[data-loading="true"] { opacity: .55; cursor: not-allowed; }

Only the default state exists

.tab {
  background: black;
  color: white;
}

Rules of thumb

Components need systems, not one-off decoration.

List states early

Write down every state before polishing visuals.

Do not hide focus

Focus is a required state, not browser decoration.

Use semantic attributes

disabled, aria-selected and aria-invalid can drive CSS and meaning.

Make loading honest

Prevent duplicate actions and communicate waiting.

Design selected clearly

Selected and hover should not look identical.

Keep transitions subtle

State changes should feel responsive, not slow.

Production thinking

A component is only good when real content and real states still work.

Why does this matter?

States are where a design system proves whether it is real. Static components look fine in screenshots and fail in use.

Accessibility

State styling must match semantic state where possible. Visual selected state without aria-selected can confuse assistive technology.

Production note

Create state checklists for every reusable component before shipping.

SEO note

Component states mainly affect usability, but usability affects whether users trust and complete tasks.

Live code lab

Change the CSS and watch the interface respond.

The preview runs in an isolated iframe. Links and forms stay inside the practice area, so you can experiment without leaving the lesson.

Mini assignment

Try this now.

  • Make hover and selected identical and explain why that is confusing.
  • Remove focus-visible and test the component mentally with a keyboard.
  • Add disabled to one button and style it differently from loading.

Practice assignment

Do this before moving to the next lesson.

  1. Create a component with default, hover, focus and selected states.
  2. Add a loading or disabled state.
  3. Explain which states come from pseudo-classes and which come from attributes.

Try it yourself

Build a stateful tab row

Live preview

Self-check

Before you continue, prove that you understand Component States.

Advanced

Answer these questions before moving on. If a state, long label or mobile width breaks the component, the component is not finished yet.

  1. Can you list the states a component needs?
  2. Can you separate hover, focus and selected visually?
  3. Can you use semantic attributes to drive styles?
  4. Can you design loading without allowing duplicate actions?
  5. Can you create a state checklist before launch?

Senior audit upgrade

Use a state matrix before polishing components.

A component is not finished when the default state looks good. List every state and design the transitions between them.

Interaction states

Default, hover, focus, active and disabled.

System states

Loading, error, success, selected and open.

Content states

Empty, long text, dense data and small screen.

Chapter project

Ship a mini UI kit

Style buttons, cards, navigation, forms, tables, modals, badges and states as one coherent system.

Build

an accessible component set with hover, focus, disabled, loading and error states

Deliverables

  • button
  • card
  • nav
  • form field
  • alert
  • state matrix

Quality checks

  • hover and focus parity
  • disabled and loading states
  • long labels survive

Review question

Can the component be reused on another page without rewriting its CSS?