@vegastack/design-tokens 0.7.43 → 0.7.46
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/dist/base.css +37 -25
- package/package.json +1 -1
package/dist/base.css
CHANGED
|
@@ -6,6 +6,8 @@
|
|
|
6
6
|
|
|
7
7
|
FOC-1 one global :focus-visible cue; components restate nothing
|
|
8
8
|
FOC-13 no focus rings anywhere, Tabs included: the cue is a background tint (MK 2026-09-25)
|
|
9
|
+
FOC-14 a border never changes colour on focus or while active; invalid keeps its destructive
|
|
10
|
+
border in every state (MK 2026-09-26)
|
|
9
11
|
FOC-7 the forced-colours fallback for text entry
|
|
10
12
|
MOT-5 the reduced-motion reset (and the one sanctioned !important)
|
|
11
13
|
INT-1 the hand cursor, on a wider selector list than shadcn's --pointer rule
|
|
@@ -60,36 +62,46 @@
|
|
|
60
62
|
@apply font-sans;
|
|
61
63
|
}
|
|
62
64
|
|
|
63
|
-
/* FOC-1 + FOC-13 — the SINGLE focus affordance in the system, and it is NOT a ring
|
|
64
|
-
No focus ring anywhere, Tabs included (MK 2026-09-25)
|
|
65
|
-
|
|
66
|
-
|
|
67
|
-
|
|
68
|
-
|
|
69
|
-
|
|
70
|
-
|
|
65
|
+
/* FOC-1 + FOC-13 + FOC-14 — the SINGLE focus affordance in the system, and it is NOT a ring and
|
|
66
|
+
NOT a border. No focus ring anywhere, Tabs included (MK 2026-09-25), and no border-colour change
|
|
67
|
+
on focus or while a control is active (MK 2026-09-26): every border keeps its resting
|
|
68
|
+
`border-border`/`border-input` colour in every state, and only the invalid state paints its
|
|
69
|
+
destructive border. A keyboard user sees a subtle background TINT — `accent` at 50%, laid over
|
|
70
|
+
whatever fill the control already has as a background IMAGE, so a primary button, a chip, a
|
|
71
|
+
row, a menu item and a text field all show it without any component restating it.
|
|
72
|
+
Text entry takes the same tint (FOC-3). A bare `input`/`textarea` wears it itself; a bordered
|
|
73
|
+
field GROUP (`data-field-group`: InputGroup, NumberField, ChipInput, the combobox chips, the
|
|
74
|
+
panel search row) wears it on the group, and the control inside it stands down so the two
|
|
75
|
+
never stack. The one caret-only surface is a contenteditable document editor (TextEdit,
|
|
76
|
+
`data-focus-cue="caret"`): no border, no fill, the caret is the cue. Components carry no focus
|
|
77
|
+
ring or focus border of their own (FOC-6); `design-lint`'s `no-focus-ring-glow` and
|
|
78
|
+
`no-focus-border` rules reject them, so one cannot creep back through a later upstream pull.
|
|
79
|
+
|
|
80
|
+
Programmatic focus targets (`tabindex="-1"`) take no tint: AppShell's skip-link `<main>`, Base UI
|
|
81
|
+
popups, a step heading focus is moved to. They are not tab stops, and each is a whole region.
|
|
82
|
+
Clicking the empty part of `<main>` focuses it, and the next key press (Shift or ⌘ alone is
|
|
83
|
+
enough) flips it to `:focus-visible` in Chromium. Before this exclusion that painted the entire
|
|
84
|
+
page grey. Combobox chips are the one `tabindex="-1"` control that arrow keys move focus onto,
|
|
85
|
+
so they keep the cue. */
|
|
71
86
|
:focus-visible {
|
|
72
87
|
outline: none;
|
|
73
88
|
}
|
|
74
89
|
:focus-visible:not(
|
|
75
|
-
textarea,
|
|
76
90
|
[contenteditable="true"],
|
|
77
|
-
|
|
78
|
-
|
|
79
|
-
|
|
80
|
-
[
|
|
81
|
-
|
|
82
|
-
[type="submit"],
|
|
83
|
-
[type="reset"],
|
|
84
|
-
[type="color"],
|
|
85
|
-
[type="file"]
|
|
86
|
-
)
|
|
87
|
-
) {
|
|
91
|
+
[tabindex="-1"]:not([data-slot="combobox-chip"])
|
|
92
|
+
),
|
|
93
|
+
[data-field-group]:has(input:focus, textarea:focus):not(
|
|
94
|
+
[data-slot="combobox-content"] *
|
|
95
|
+
) {
|
|
88
96
|
background-image: linear-gradient(
|
|
89
97
|
color-mix(in oklch, var(--accent) 50%, transparent),
|
|
90
98
|
color-mix(in oklch, var(--accent) 50%, transparent)
|
|
91
99
|
);
|
|
92
100
|
}
|
|
101
|
+
[data-field-group] input:focus-visible,
|
|
102
|
+
[data-field-group] textarea:focus-visible {
|
|
103
|
+
background-image: none;
|
|
104
|
+
}
|
|
93
105
|
|
|
94
106
|
/* INT-1 — the hand cursor. shadcn's `--pointer` flag writes
|
|
95
107
|
`button:not(:disabled), [role="button"]:not(:disabled) { cursor: pointer }`; ours is the same
|
|
@@ -128,9 +140,9 @@
|
|
|
128
140
|
outline-offset: 1px;
|
|
129
141
|
}
|
|
130
142
|
|
|
131
|
-
/* Text-entry focus (FOC-3). Every text-entry control signals focus with
|
|
132
|
-
the outline, because a raw text field cannot tell mouse from keyboard. Forced colours
|
|
133
|
-
|
|
143
|
+
/* Text-entry focus (FOC-3). Every text-entry control signals focus with the background TINT and
|
|
144
|
+
strips the outline, because a raw text field cannot tell mouse from keyboard. Forced colours
|
|
145
|
+
drops authored backgrounds outright, so the tint vanishes and `outline-style: none` stays in force — a
|
|
134
146
|
Windows High Contrast user had no caret location at all. This block is UNLAYERED on purpose:
|
|
135
147
|
it beats the component's `outline-none` (a layered utility) regardless of specificity, so the
|
|
136
148
|
fallback is written ONCE here, never per component.
|
|
@@ -151,8 +163,8 @@
|
|
|
151
163
|
NumberField's stepper group, ChipInput, the Combobox input-group — clips with `overflow-hidden`
|
|
152
164
|
so its addons follow the rounded corner. The inner input's own outline is offset outward INTO
|
|
153
165
|
that clip, so it was drawn and then cut, which is how an addon field ended up with no visible
|
|
154
|
-
focus at all under the forced palette. The group carries the outline (it is the element
|
|
155
|
-
|
|
166
|
+
focus at all under the forced palette. The group carries the outline (it is the element that
|
|
167
|
+
wears the tint); the control inside it stands down, so the two never paint a
|
|
156
168
|
double ring. */
|
|
157
169
|
[data-field-group] input:focus,
|
|
158
170
|
[data-field-group] textarea:focus {
|