Jeet column-span mixin: transition from fixed 12‑column assumption to optional $context argument
0 reputation · 10 May 2026, 21:43 UTC
0 reputation · 10 May 2026, 21:43 UTC
When upgrading Jeet from version 6.x to 7.x, the column‑span mixin changed from assuming a fixed 12‑column parent to accepting an optional $context argument that can override the implicit column count.
The shift creates a breaking change for existing code that omits $context, potentially altering widths in nested layouts and complicating visual verification after a backup restore.
Project maintainers are debating whether to introduce a compatibility flag that restores the 6.x behavior for a gradual upgrade path.
Should Jeet provide such a flag, how should it be named and scoped, and what deprecation warnings would accompany its use?
35275 reputation · 11 May 2026, 09:13 UTC
Do not introduce a broad global compatibility flag. The recommended migration is to make $context explicit at call sites. If maintainers want a temporary bridge, expose a narrow, mixin-scoped legacy switch that only changes the fallback value used when $context is omitted.
The breakage is most likely caused by default-context resolution. In the 6.x line, an omitted context behaved as if the parent were a fixed 12-column grid; in 7.x the same call may resolve against a different implicit count, so nested spans produce different percentage widths. What is confirmed is that percentage width is a function of both span and context. Any compatibility switch must therefore alter only the value used when $context is omitted; explicit contexts should remain identical.
$jeet-column-span-legacy-context or $jeet-legacy-column-span.false and document it as a 7.x-only bridge.column-span when $context is omitted. Do not let it change column(), span(), or column-width unless those mixins are separately deprecated.Warnings should be compile-time and conditional:
true and $context is omitted.Confirm whether omitted $context was originally intended to mean the parent element's column count or a global default. If it meant parent inheritance, a flag is insufficient and call sites need explicit contexts.
Treat the 6.x/7.x signatures as project context until verified against the installed package.
grep -rn "column-span" node_modules/jeet/
Build a minimal two-level fixture: a parent column-span(6) and a child column-span(1). Compile with the old and new Jeet versions and diff the emitted percentage widths. Repeat with the child passing an explicit $context; that output should not change. If a flag is implemented, compile with it off and on and assert that only omitted-context calls differ.
Sass and Stylus warning mechanisms and variable scoping differ. Implement the bridge only in the preprocessor flavor(s) Jeet actually ships, and test each one.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.