State class generation (hover, active, disabled) in SASS - Performance & Optimization

Performance: State class generation (hover, active, disabled)

MEDIUM IMPACT

This affects the browser's style calculation and paint phases by adding or removing CSS classes that change element states like hover, active, or disabled.

Applying hover, active, and disabled styles to buttons

SASS

@mixin button-states-good {
  button {
    &.hover {
      background-color: blue;
    }
    &.active {
      background-color: darkblue;
    }
    &.disabled {
      background-color: gray;
      cursor: not-allowed;
    }
  }
}
@include button-states-good;

// JavaScript toggles classes on events instead of relying on :hover/:active pseudo-classes

Using explicit state classes reduces browser style recalculations by controlling state changes via class toggling, which is more performant especially for complex UI.

📈 Performance GainReduces style recalculations and repaints to only when classes change, improving interaction responsiveness.

Applying hover, active, and disabled styles to buttons

SASS

@mixin button-states-bad {
  button {
    &:hover {
      background-color: blue;
    }
    &:active {
      background-color: darkblue;
    }
    &:disabled {
      background-color: gray;
      cursor: not-allowed;
    }
  }
}
@include button-states-bad;

Using nested pseudo-classes directly on many buttons causes the browser to recalculate styles on every hover or active event, triggering style recalculations and repaints.

📉 Performance CostTriggers style recalculations and repaints on each hover and active interaction.

Performance Comparison

Pattern	DOM Operations	Style Recalc	Paint Cost	Verdict
Using :hover/:active/:disabled pseudo-classes	No extra DOM ops	Triggers style recalc and repaint on every hover/active	High paint cost on interaction	[X] Bad
Using explicit .hover/.active/.disabled classes toggled by JS	Class toggling on state change	Single style recalc per class toggle	Lower paint cost, batched updates	[OK] Good

Rendering Pipeline

State class generation affects the Style Calculation and Paint stages because changing classes triggers style recalculation and repaint of affected elements.

→Style Calculation

→Paint

⚠️ BottleneckStyle Calculation is most expensive due to recalculating styles on state changes.

Core Web Vital Affected

INP

This affects the browser's style calculation and paint phases by adding or removing CSS classes that change element states like hover, active, or disabled.

Optimization Tips

1Avoid relying solely on :hover and :active pseudo-classes for complex interactive states.

2Use JavaScript to toggle explicit state classes to batch style changes.

3Minimize style recalculations by reducing frequent pseudo-class triggers.

Performance Quiz - 3 Questions

Which method reduces style recalculations when applying hover and active states?

A Using :hover and :active pseudo-classes in CSS

B Applying inline styles on hover events

C Using explicit state classes toggled by JavaScript

D Using !important in CSS rules

DevTools: Performance

How to check: Record a performance profile while interacting with buttons. Look for style recalculation and paint events during hover and active states.

What to look for: High frequency of style recalculations and paints indicates inefficient state styling; fewer recalculations with class toggling shows better performance.

Practice

1. What is the main purpose of using state classes like :hover, :active, and .disabled in Sass?

easy

A. To change the appearance of elements based on user interaction or status

B. To add animations to elements automatically

C. To create new HTML elements dynamically

D. To load external CSS files conditionally

Solution

1. Step 1: Understand state classes

   State classes like :hover and :active change how elements look when users interact with them.

2. Step 2: Identify their purpose

   They help show different styles for hover, active, or disabled states to improve user experience.

3. Final Answer:

   To change the appearance of elements based on user interaction or status -> Option A

4. Quick Check:

   State classes change look on interaction [OK]

Hint: State classes show style changes on user actions [OK]

Common Mistakes:

• Thinking state classes create new elements
• Confusing state classes with animations
• Believing state classes load files

2. Which of the following is the correct Sass syntax to create a mixin for hover and active states?

easy

A. @mixin states { :hover { color: blue; } :active { color: red; } }

B. @mixin states { &:hover { color: blue; } &:active { color: red; } }

C. @mixin states { .hover { color: blue; } .active { color: red; } }

D. @mixin states { hover { color: blue; } active { color: red; } }

Solution

1. Step 1: Review Sass mixin syntax

   Mixins use @mixin name { ... } and nested selectors use &:state for pseudo-classes.

2. Step 2: Check correct pseudo-class usage

   Correct syntax uses &:hover and &:active inside the mixin.

3. Final Answer:

   @mixin states { &:hover { color: blue; } &:active { color: red; } } -> Option B

4. Quick Check:

   Use & with :hover and :active in mixins [OK]

Hint: Use & before pseudo-classes inside mixins [OK]

Common Mistakes:

• Omitting & before pseudo-classes
• Using class selectors instead of pseudo-classes
• Missing @mixin keyword

3. Given this Sass code, what color will the button text be when hovered?

@mixin states {
  &:hover { color: green; }
  &:active { color: orange; }
  &.disabled { color: gray; cursor: not-allowed; }
}

.button {
  color: black;
  @include states;
}

medium

A. Green

B. Black

C. Orange

D. Gray

Solution

1. Step 1: Understand the mixin states

   The mixin sets color: green on :hover, color: orange on :active, and gray with disabled class.

2. Step 2: Check the hover state

   When the button is hovered, the :hover style applies, changing text color to green.

3. Final Answer:

   Green -> Option A

4. Quick Check:

   Hover changes color to green [OK]

Hint: Hover state color overrides base color [OK]

Common Mistakes:

• Confusing active color with hover color
• Ignoring the disabled class
• Assuming base color stays on hover

4. Identify the error in this Sass code that tries to create disabled state styles:

@mixin states {
  &:hover { color: blue; }
  &:active { color: red; }
  &:disabled { color: gray; cursor: not-allowed; }
}

.button {
  @include states;
}

medium

A. Cannot use mixins inside class selectors

B. Missing semicolon after color: red

C. Using &:disabled instead of &.disabled for disabled class

D. Mixin name should be capitalized

Solution

1. Step 1: Check pseudo-class vs class usage

   :disabled is a pseudo-class for form elements, but here disabled is a class, so &.disabled is correct.

2. Step 2: Verify other syntax

   Semicolons are present, mixin naming is flexible, and mixins can be used inside classes.

3. Final Answer:

   Using &:disabled instead of &.disabled for disabled class -> Option C

4. Quick Check:

   Use .disabled class selector, not :disabled pseudo-class [OK]

Hint: Use .disabled class, not :disabled pseudo-class [OK]

Common Mistakes:

• Confusing :disabled pseudo-class with .disabled class
• Forgetting semicolons
• Thinking mixins need capital letters

5. You want to create a reusable Sass mixin that adds hover, active, and disabled states to any button. The disabled state should make the button look faded and prevent clicks. Which of these mixins correctly implements this behavior?

hard

A. @mixin button-states {
&:hover { background-color: lightblue; }
&:active { background-color: blue; }
&.disabled { opacity: 1; pointer-events: auto; cursor: not-allowed; }
}

B. @mixin button-states {
&:hover { background-color: lightblue; }
&:active { background-color: blue; }
&:disabled { opacity: 0.5; pointer-events: none; cursor: not-allowed; }
}

C. @mixin button-states {
&:hover { background-color: lightblue; }
&:active { background-color: blue; }
&.disabled { opacity: 0.5; cursor: default; }
}

D. @mixin button-states {
&:hover { background-color: lightblue; }
&:active { background-color: blue; }
&.disabled { opacity: 0.5; pointer-events: none; cursor: not-allowed; }
}

Solution

1. Step 1: Check disabled state styling

   The disabled state should fade the button with opacity: 0.5 and prevent clicks using pointer-events: none.

2. Step 2: Verify cursor and selector usage

   Using &.disabled is correct for a class. Cursor should be not-allowed to show disabled status.

3. Step 3: Compare options

   @mixin button-states { &:hover { background-color: lightblue; } &:active { background-color: blue; } &.disabled { opacity: 0.5; pointer-events: none; cursor: not-allowed; } } correctly uses &.disabled, sets opacity to 0.5, disables pointer events, and sets cursor properly.

4. Final Answer:

   @mixin button-states { &:hover { background-color: lightblue; } &:active { background-color: blue; } &.disabled { opacity: 0.5; pointer-events: none; cursor: not-allowed; } } -> Option D

5. Quick Check:

   Disabled state fades and disables clicks with pointer-events none [OK]

Hint: Use pointer-events:none and opacity for disabled state [OK]

Common Mistakes:

• Using :disabled pseudo-class instead of .disabled class
• Not disabling pointer events on disabled
• Setting opacity to 1 in disabled state