Dynamic CSS Grids: Bridging SASS & Runtime Data Attributes

by

Summary

The engineering team attempted to implement a highly dynamic CSS Grid system using SASS mixins paired with HTML data attributes. The goal was to allow frontend developers to control grid positioning and spanning directly from the markup. However, the implementation failed because there was no CSS bridge connecting the runtime values stored in data-* attributes to the compile-time logic of SASS mixins.

Root Cause

The failure stems from a fundamental misunderstanding of the separation between build-time and runtime:

  • SASS is a pre-processor: Mixins are evaluated during the build step. Once the CSS is generated, the SASS logic no longer exists.
  • Data attributes are runtime values: The values in data-col-start and data-col-size only exist in the DOM at browser runtime.
  • Static CSS vs. Dynamic HTML: A SASS mixin cannot “reach out” to an HTML attribute to grab a value unless that value is mapped to a CSS Custom Property (CSS Variable).

Why This Happens in Real Systems

In complex production environments, this happens when there is a disconnect between Design Systems and Implementation:

  • Over-engineering: Developers attempt to create “universal” tools that solve every edge case via pre-processors rather than leveraging native browser features.
  • Abstraction Leaks: Trying to force a static language (SASS) to behave like a dynamic language (JavaScript/CSS Variables).
  • Tooling Silos: The person writing the SASS architecture is often not the same person writing the HTML markup, leading to a broken contract between the two.

Real-World Impact

  • Maintenance Overhead: Developers spend hours trying to “fix” mixins that are logically incapable of performing the requested task.
  • Bloated CSS: If developers try to solve this by generating every possible combination of grid positions in SASS, the resulting CSS file size explodes.
  • Broken UI: Layouts fail to respond to dynamic content or user-driven changes because the positioning is hardcoded at build time.

Example or Code (if necessary and relevant)

To fix this, we must move away from SASS mixins for individual item positioning and use CSS Variables to bridge the gap.

// The Grid Container
@mixin grid($gap: null) {
  display: grid;
  width: 100%;
  gap: $gap;
  grid-template-columns: repeat(12, 1fr);
}

.grid {
  @include grid(1rem);
}

// The Bridge: Mapping data-attributes to CSS Variables
.grid__item {
  // Use the CSS variable, fallback to a default if not provided
  grid-column-start: var(--col-start, auto);
  grid-column-end: span var(--col-size, 1);
}

How Senior Engineers Fix It

A senior engineer recognizes that the logic belongs in the CSS Object Model (CSSOM), not the pre-processor.

  • Leverage CSS Custom Properties: Use var() to allow the HTML/JS layer to inject values into the CSS engine.
  • Maintain a Single Source of Truth: Keep the structural grid definition (the 12-column setup) in SASS, but leave the instance-specific positioning to CSS Variables.
  • Prefer Composition over Complexity: Instead of a complex mixin that tries to do everything, provide a simple utility class or a variable-based approach that is predictable.

Why Juniors Miss It

  • Tool-First Thinking: Juniors often focus on mastering the syntax of a tool (like SASS mixins) without understanding the execution lifecycle of the code.
  • Confusing Compile-time with Runtime: They assume that because a value is “in the code,” the pre-processor can access it.
  • Lack of Architectural Context: They view the problem as a “syntax error” to be solved with more complex SASS, rather than a “structural error” requiring a change in strategy.

Leave a Comment