LESS Breakpoints

Defining a Breakpoint Scale

A breakpoint scale is simply a small, named set of viewport widths (small, medium, large, extra-large) that every responsive decision in a project should reference, rather than inventing a new pixel value for each component.

In LESS, since there's no native map data structure like Sass maps, breakpoints are typically modeled either as individual variables or as a detached ruleset acting as a key-value store.

// Individual variables approach
@bp-sm: 576px;
@bp-md: 768px;
@bp-lg: 992px;
@bp-xl: 1200px;

// Detached ruleset (map-like) approach
@breakpoints: {
  sm: 576px;
  md: 768px;
  lg: 992px;
  xl: 1200px;
}

Both approaches work; individual variables are simpler, while the map-like ruleset works well with each() for generating utilities.

Querying a Breakpoint Value

@media (min-width: @bp-md) { ... }

each(@breakpoints, {
  @media (min-width: @value) {
    .visible-@{key} { display: block; }
  }
});

• Individual variables are queried directly by name: @bp-md.
• A map-like detached ruleset is queried by iterating with each(), binding @key and @value.
• Both approaches should be defined once, in a shared file, and imported before any component styles.
• Naming conventions (sm, md, lg, xl) should stay consistent with any design tool or documentation your team uses.

LESS Breakpoints Cheatsheet

A common breakpoint scale and its typical use cases.

Generating Responsive Utilities from a Breakpoint Map

A map-like detached ruleset combined with each() can generate an entire family of responsive utility classes, like visibility helpers, from a single breakpoint definition.

@breakpoints: {
  sm: 576px;
  md: 768px;
  lg: 992px;
}

each(@breakpoints, {
  @media (min-width: @value) {
    .hide-@{key} { display: none; }
  }
});

Keeping Breakpoints Consistent with Design Tools

Breakpoint values should match whatever design tool or specification your team uses, Figma frames, a design system's documented grid, or an existing product's established scale, rather than being invented independently in code.

• Confirm breakpoint values with design before hardcoding them into LESS.
• Document each breakpoint's intended device range alongside its variable definition.
• Avoid introducing a new, one-off breakpoint for a single component; extend the existing shared scale instead.

Min-Width vs Max-Width Strategy

Most modern responsive systems use a mobile-first, min-width-only strategy, where base styles target the smallest screen and each breakpoint progressively adds styles for larger viewports, rather than mixing min-width and max-width queries unpredictably.

• Write base styles for the smallest supported viewport first.
• Use min-width queries to progressively enhance for larger viewports.
• Reserve max-width queries for genuinely upper-bounded, range-specific overrides.

Common Mistakes

• Inventing a new, project-specific breakpoint value for a single component instead of using the shared scale.
• Mixing min-width and max-width queries inconsistently, making the overall responsive strategy hard to reason about.
• Letting a breakpoint scale drift out of sync with the design tool or specification the design team actually uses.
• Duplicating the same breakpoint value as separate individual variables and map entries, risking drift between the two.

Key Takeaways

• A shared breakpoint scale is the foundation of a maintainable responsive system.
• LESS models breakpoints either as individual variables or a map-like detached ruleset queried with each().
• A map-like ruleset combined with each() can generate entire families of responsive utility classes.
• A mobile-first, min-width-only strategy keeps responsive logic predictable across a project.