Primitives Tier 3: decide whether grid is in scope, then build or close

[fsecada01]

Split out of #52 so Tier 1 could ship independently (acceptance criterion 7). Tier 1 landed in #53.

This one is a decide-then-maybe-build, not a build. #52 raised it as open question 2 and did not answer it. The answer should be written down here before any file is created, because the honest answer may be "no."

The problem

Bootstrap, Bulma, Foundation and Fomantic each ship a 12-column grid with its own class vocabulary — col-md-6, is-6, medium-6, eight wide column. Those four are a genuine adapter: same concept, four spellings, exactly what cf-ui exists to absorb.

daisyUI ships no grid. It defers entirely to Tailwind utilities. So the daisy variant of <c-cf.grid> would emit grid grid-cols-12 gap-4 and a column would emit col-span-6 — raw Tailwind utilities, not framework component classes. That is a different kind of thing from the other four, not a thinner version of it.

Measured use in the reference repo: 25 columns + 28 column + 53 width tokens.

Why this is not obviously worth doing

• The abstraction leaks at exactly the point people use it. Responsive breakpoints are where grids actually earn their keep, and the four frameworks disagree about breakpoint names and count. col-md-6 and is-6-tablet are not the same breakpoint. A <c-cf.column span="6" at="tablet"> has to pick a canonical breakpoint set and map it, and any mapping will be wrong for someone.
• The Tailwind literal-class constraint bites hardest here. Every span × every breakpoint has to be spelled out longhand in the daisy template, because Tailwind's scanner reads source text — col-span-{{ span }} is tree-shaken away silently. 12 spans × 5 breakpoints is 60 literal branches per template, and primitives.py would carry the same 60 twice for the parity test. That is a real maintenance surface for a component whose value is questionable.
• Consumers migrating to Tailwind do not want it. The reference-repo migration that motivated Add a primitives layer: button, icon, badge, heading, label across all five themes #52 is Bulma → Tailwind + daisyUI. On the far side of that migration the consumer writes grid-cols-3 directly and a cf-ui grid component is pure indirection.

The case for doing it anyway

A repo that wants to stay theme-switchable cannot write layout in any framework's vocabulary — a CF_UI_THEME flip would break every page's layout while leaving every component intact. If layout is the one thing that does not switch, "switching CSS frameworks means changing CF_UI_THEME in one place" is not quite true.

Acceptance criteria

• A written decision: build it, build a reduced version, or close as won't-do — with the reasoning, so it is not re-litigated.
• If reduced: state what was cut and why (e.g. a fixed set of column counts with no responsive axis is a much smaller surface and covers most measured uses).
• If built: canonical breakpoint set chosen and its per-theme mapping documented, including which frameworks it maps to imperfectly.
• If built: the daisy asymmetry stated plainly in docs/primitives.md — that the daisy variant emits Tailwind utilities rather than framework classes, and what that means for a consumer without Tailwind.
• If closed: docs/primitives.md says layout is out of scope and what to do instead, so the question does not come back as a bug report.

[fsecada01]

Decision: won't-do. cf-ui does not ship a grid. Written up in PR #60, in docs/primitives.md under ## Layout is out of scope.

The short version, because the reason is not the one this issue was filed with.

This issue says "Bootstrap, Bulma, Foundation and Fomantic each ship a 12-column grid" and treats daisyUI's lack of one as the difficulty. Checked against upstream, that premise is wrong in two ways, each fatal on its own:

Fomantic's grid is 16 columns, not 12. A span of 6 means half the row on four themes and three-eighths of it on Fomantic. That is a different concept, not a different spelling — the first axis considered for this package with no single idea underneath it — and it fails silently, since the page still renders at the wrong width.

Bulma's mobile tier is a max-width cap while every other ladder is min-width. So the canonical breakpoint set is not a numbers problem where cf-ui picks the least-wrong value; at="mobile" would have to mean "from here up" on four themes and "below here" on the fifth.

The daisyUI asymmetry this issue led with is real and turns out to be the least of the three problems.

The reduced non-responsive version was considered and rejected too: a layout that stays three columns on a phone is broken rather than simpler, so consumers would reach immediately for the axis that does not work — and Fomantic's column count breaks the reduced version just as thoroughly, because the column count is not the responsive axis. Cutting responsiveness removes the smaller problem and leaves the larger one.

One correction to my own reasoning, kept in the doc rather than dropped: "no two frameworks agree on breakpoints" is false. Bootstrap's md and Tailwind's md are both 768px and Bulma's tablet is one pixel away. That was the strongest thing the build case had, and it is still not enough — agreement at one tier out of five, between two themes out of five, does not make the ladders interchangeable.

The cost is named rather than hidden, per acceptance criterion 5: layout is now a stated exception to "changing frameworks means changing CF_UI_THEME in one place." A consumer who writes class="columns" has written Bulma into their templates, and a theme flip leaves every component correct and every page's layout broken. The docs say what to do instead — the framework's own vocabulary, plain CSS Grid / flexbox for theme-independent layout, or Tailwind utilities if you are migrating there — and say plainly that this is a decision, not a gap.

Closing once #60 merges.