Performance & Reusability

Verze:

17. 02. 2026

Zodpovědná osoba:

Dominik Šlechta

Identical declarations repeated in 3+ components SHOULD be extracted into a mixin or utility class. New utility classes MUST follow the .--name convention and MUST be placed in the global/ folder. @extend SHOULD be avoided in favor of mixins.

Introduction

This standard defines best practices for writing performant and reusable SCSS to minimize redundancy and ensure efficient CSS output.

Selector Performance

  • The universal selector * SHOULD NOT be used outside of global resets.

  • Deeply nested descendant selectors SHOULD be avoided — browsers read selectors right-to-left, so .main-header .content .inner .title span is significantly slower than .main-header__title.

Code Duplication

  • Identical declarations repeated in 3 or more components SHOULD be extracted into a shared mixin or utility class.

  • When a visual pattern repeats across the project, a new modifier class (.--modifier-name) or mixin SHOULD be created.

Mixin vs Utility Class

Use the following guideline to decide between a mixin and a utility class:

  • Mixin — when the pattern needs parameters or variations: @include media($breakpoint), @include pseudo()

  • Utility class — when the pattern is a fixed set of properties that can be applied via HTML: .--flex-centre, .--bg-light

New Utility Classes

New utility classes MUST follow the double-dash prefix convention (.--name) and MUST be placed in the global/ folder.

Avoiding Redundant Output

Use @extend sparingly — it can produce unexpected output with nested selectors. Prefer mixins over @extend for shared styles.