Files
store/gui-css-check.json
zeekayandHanzo Dev 8530912979 The store's own .btn rule was doing nothing, so it is gone
`.btn` is not a rule @hanzo/ui ships — it is a stable class HANDLE it stamps on
a control alongside the @hanzo/gui atomics that actually paint it, so a host can
hook buttons from CSS. This app hooked it, to refuse the user-agent underline on
the five `<Button asChild>` controls that render as anchors.

It was refusing nothing. Measured on the built site: 606 `a.btn` elements, and
deleting the rule at runtime leaves every one of them computing
`text-decoration-line: none` — ui's own atomics already set it. And there is no
first-paint window where it could have mattered either: the store renders its
buttons on the client, so `.btn` does not appear in the exported HTML at all.

That left a store-owned meaning sitting on ui's handle for no benefit, which is
the thing to avoid — one class name, one owner. The store now defines nothing
for the handles and hooks none of them, so `btn` joins the other nine in
gui-css-check.json.

Recorded there, and worth fixing upstream: @hanzo/gui 8.0.2's css-check ships a
DEFAULT_ALLOW naming `hanzo-button` / `hanzo-badge` — the handles retired in
'adopt @hanzo/ui 8.0.44 class handles'. The defaults have not caught up, which
is the only reason this repo carries a gui-css-check.json at all. When a gui
release allows btn/badge by default, delete the file.

Also documents why this app imports @hanzo/ui/theme.css and not styles.css:
styles.css ends with a bare unscoped `:root{--background:var(--t189)}` that is
near-white, beaten only by a block scoped to gui's own `t_dark` class — which
next-themes never writes. Import it last and the dark ground goes white with
every check still green. theme.css sets --background to #0a0a0a directly.
Asserted with numbers rather than trusted: dark is rgb(20,20,20) ground on
rgb(255,255,255) ink at 18.42:1, light is rgb(247,247,247) on rgb(5,5,5) at
19.02:1 — the ground flips and both clear AAA.

Co-authored-by: Hanzo Dev <[email protected]>
2026-08-04 18:31:06 -07:00

17 lines
1.3 KiB
JSON

{
"_why": "These are @hanzo/ui's stable class HANDLES. A ui <Button> renders as `btn btn-<variant> btn-<size>` plus the @hanzo/gui atomic classes that actually paint it, and <Badge> does the same; ui ships no rules for the handles on purpose — they exist so a host can hook a control from CSS. Verified inert rather than assumed: stripping every btn-*/badge-* class off a rendered element leaves its computed background, padding and radius unmoved, and deleting the one `.btn` rule this app used to carry changed the text-decoration of none of its 606 anchors. The store therefore hooks nothing and defines nothing for them.",
"_upstream": "This file should be DELETABLE. @hanzo/gui 8.0.2's css-check ships a DEFAULT_ALLOW that still names the retired handles — hanzo-button, hanzo-button--*, hanzo-badge, hanzo-badge--* — from before the rename to btn/badge (see this repo's commit 'adopt @hanzo/ui 8.0.44 class handles'). The defaults simply have not caught up. When a @hanzo/gui release allows btn/btn-*/badge/badge-* by default, drop this file rather than maintaining a second copy of the same list.",
"allow": [
"btn",
"btn-default",
"btn-sm",
"btn-lg",
"btn-outline",
"btn-ghost",
"badge",
"badge-default",
"badge-secondary",
"badge-outline"
]
}