kuhyx/utils
1
0
Fork 0
mirror of https://github.com/kuhyx/utils.git synced 2026-11-11 13:27:44 +01:00
Code Issues Actions 17 Packages Projects Releases Wiki Activity
795a8eae62
utils/unified-design-system/screen-size.md
Krzysztof kuhy Rudnicki 2574b21acc design-system: add a categorical ramp; web_ui v0.2.0 
awesome-mcp-explorer needs six mutually distinguishable colours for its A-F
grades, and the design system had no answer -- one accent, and semantic roles
that deliberately cluster in one hue wedge. Raised as its own decision (per
PHASE3-PROMPT) and resolved by designing the ramp rather than mapping grades
onto success/warning/danger, which would have collapsed six steps into three.

Chosen by search, not by eye, under four hard constraints:
  - pairwise CIE dE >= 20 under normal vision AND deuteranopia, protanopia and
    tritanopia (worst observed 26.0)
  - >= 3:1 against BOTH backgrounds, since the ramp does not re-theme. This is
    the binding constraint: such colours only exist in L* 44-59.
  - monotonic lightness 58 -> 44, so hue and lightness encode redundantly and
    the ramp survives greyscale as an ordinal scale
  - muted saturation, to sit with the rest of the palette

scripts/ramp_check.py re-runs the whole proof and exits non-zero on a
regression, so this is a gate rather than a paragraph. A seventh hue is not
available (best candidate reaches dE 17.9); group the tail into "other".

This ramp is the only token group that leaves the warm wedge, deliberately:
hue separation is the entire point of a categorical scale.

Also: tokens.test.ts guards every frozen value against drift, and
tokens.md was split (screen-size.md) to hold the 250-line cap.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01U4Rj3s7K2qzrLNgJqqPhno
2026-08-15 14:50:43 +02:00

1.8 KiB
Raw Blame History

Screen size (required)

Split out of tokens.md on 2026-08-15 to hold every file under the shared 250-line cap, when the categorical ramp was added. Both are part of the same token spec — this is a filing change, not a scoping change.

Target Requirement
1366x768 Fully usable. Nothing clipped, nothing unreachable. This is the primary machine.
1024x600 Degrades gracefully — scrolls rather than clips. No hard minimum size above this.

Rules:

  1. Budget the height, don't assume it. 768px is the design target, not 1080. Mixing a proportional content area with fixed chrome (height = 0.7·H above a fixed-height button row) silently works at 1080 and fails at 768 — compute the content budget as available − measured chrome.
  2. Any view that can grow must scroll. Lists, forms, anything whose height depends on data (a day's log, an error string, accumulated history). An unbounded error message is a real overflow source.
  3. Never centre unscrollable content that can overflow. A centre-anchored container clips symmetrically when it is too tall — losing the header and the submit button, with no scrollbar and no indication anything is missing. Top-anchor it inside a scroll container instead.
  4. Clamp width as well. Prose stays at the 40rem/640px cap (rule 21) and single-purpose inputs get a sensible max — a 4-digit number field stretched to 1334px is a violation even though nothing is clipped.
  5. Don't let text scale break layout. Rows that must not overflow use Wrap/ Flexible rather than a bare Row.

1366x768 and 1024x600 are landscape and short. Phone-portrait test sizes do not exercise either constraint, so both belong in the test matrix explicitly.