LESS Namespaces

What Is a LESS Namespace?

A namespace is just a regular selector (typically an ID like #utilities or a class like .utilities) that contains one or more mixin definitions nested inside it. The mixins are then accessed through the namespace, similar to accessing a property on an object.

Namespaces mainly help organize large mixin libraries. In modern LESS projects, many teams prefer simple, well-named top-level mixins instead, reserving namespaces for genuinely large, categorized libraries.

#utilities {
  .center() {
    display: flex;
    align-items: center;
    justify-content: center;
  }
  .shadow() {
    box-shadow: 0 2px 8px rgba(0, 0, 0, 0.15);
  }
}

.hero {
  #utilities.center();
  #utilities.shadow();
}

Both mixins live inside the #utilities namespace and are called with dot notation from outside it.

Namespace Definition and Call Syntax

#namespace {
  .mixin-a() { ... }
  .mixin-b() { ... }
}

.caller {
  #namespace.mixin-a();
  #namespace > .mixin-b();
}

• Namespaces can be defined with either #id or .class style selectors; both work identically.
• Call a namespaced mixin with dot notation: #namespace.mixin();.
• The > (child combinator) syntax, #namespace > .mixin();, is equivalent and sometimes preferred for readability.
• Namespaces can be nested to any depth, forming a hierarchy of categorized mixins.

LESS Namespaces Cheatsheet

Common namespace definition and access patterns.

Why Use Namespaces?

Namespaces prevent naming collisions in a large shared mixin library, since two unrelated .center() mixins can coexist safely inside two different namespaces without conflicting.

• Group related mixins by feature area (layout, typography, forms, animations).
• Avoid naming collisions between mixins from different libraries or teams.
• Make a mixin's origin explicit at the call site (#layout.center() reads clearly).

Guarded Namespaces

A namespace itself can carry a guard condition, meaning every mixin inside it is only available when that condition is true. This is evaluated the same way as a guard on an individual mixin.

@theme: dark;

#panel when (@theme = dark) {
  .card() {
    background: #111;
    color: white;
  }
}

.box { #panel.card(); } // only works if @theme = dark

Namespaces vs Plain Top-Level Mixins

Modern LESS style guides often favor flat, clearly named top-level mixins (.button-reset(), .flex-center()) over deeply nested namespaces, reserving namespaces for genuinely large, multi-team mixin libraries where naming collisions are a real risk.

• Use plain top-level mixins for small to medium projects.
• Reserve namespaces for large, shared libraries where collisions are likely.
• Avoid nesting namespaces more than 2 levels deep for readability.

Common Mistakes

• Forgetting the dot before the mixin name when calling: #bundle.btn(); not #bundle btn();.
• Over-namespacing a small project's mixins when simple, well-named top-level mixins would be clearer.
• Nesting namespaces so deeply that call sites become hard to read, like #a.b.c.d.mixin();.
• Assuming a guarded namespace's guard is re-evaluated per mixin call instead of once for the whole namespace.

Key Takeaways

• Namespaces group related mixins under a shared #id or .class selector.
• Call namespaced mixins with dot notation (#bundle.mixin();) or the child combinator (#bundle > .mixin();).
• A namespace can carry its own guard, gating access to every mixin defined inside it.
• Reserve namespaces for large, shared mixin libraries; prefer flat, well-named mixins for smaller projects.