XY Grid Class Adoption Threshold for Multi-Developer Projects

Direct recommendation

For a multi-developer Foundation for Sites codebase with varying Sass familiarity, default new component development to XY Grid classes introduced in 6.4. Reserve semantic mixin-based grid for components that are generated, heavily abstracted, or require non-standard column math that cannot be expressed with classes.

Do not mix both paradigms inside the same component. Pick one per component and enforce it in code review.

Criteria for XY Grid classes vs semantic mixins

• Team Sass proficiency: XY Grid requires HTML class knowledge only. Semantic mixins require comfortable use of Sass maps, @include, and understanding of how Foundation builds media queries from $breakpoints.
• Onboarding and velocity: Classes are discoverable in markup and design docs. Mixins are discoverable only in Sass and require reading the component source.
• Design-system cohesion: If you need a strict, documented spacing and column vocabulary across teams, class names provide an explicit contract. Mixins allow semantic names but rely on developer discipline to keep output consistent.
• Breakpoint overrides: Class-based overrides are done in markup with suffixes like cell--large-6. Mixin overrides are done in Sass with map lookups. Mixing the two in the same file increases specificity risk.

Synchronizing breakpoint configuration

Confirmed fact: Both paradigms reference the $breakpoints map defined in _settings.scss. XY Grid maps class suffixes to map keys; semantic mixins use the same map for media query generation.

Steps to keep them in sync without duplication:

1. Define $breakpoints once in a shared configuration partial, e.g. _settings.scss, and import it before any Foundation imports.
2. Never override breakpoints in component partials. Override only in the shared settings file.
3. Import the settings partial in every Sass entry point so both class and mixin code resolve to the same map.
4. Verify parity by rendering a test page with a class-based grid and a mixin-based grid side-by-side and confirming column changes at identical viewport widths. Inspect generated CSS media queries to confirm they match the map values.

Minimum Sass proficiency threshold

Confirmed fact: XY Grid can be maintained with basic CSS class usage and an understanding of responsive suffix conventions.

Likely explanation for maintenance cost: Mixin-based grids require team-wide ability to trace @include foundation-grid-column and related mixins, understand how $breakpoints is consumed, and avoid accidental map mutations that affect the whole project.

Practical minimums:

• XY Grid classes: Basic HTML/CSS, ability to read Foundation docs for suffix naming.
• Semantic mixins: Comfort with Sass maps, imports, and debugging compiled media queries. At scale, at least one senior maintainer who can audit mixin output and prevent divergent breakpoint usage.

Missing diagnostic that would change the recommendation: current Foundation major version and whether your build pipeline already compiles a shared _settings.scss for all apps. If you are pre-6.4 or have per-app settings overrides, the sync steps above need adjustment.