@apliteni/apliteni-ui 0.73.0 → 0.75.0

package/guidelines/accessibility-floor.md

@@ -6,13 +6,11 @@
 
 **Rule:** Give every pointer target at least 24x24 CSS px.
 
-**Why:** Larger targets are easier to activate accurately.
+**Do:** The dashed square is the hit area the box declares, not a drawing of one.
 
-**Do:** Use a centred 24x24 `::before` hit area for a 19x19 checkbox.
+**Don't:** The target stops where the 19x19 box stops.
 
-**Don't:** Leave a 19x19 target unchanged.
-
-**Except:** WCAG 2.5.8 permits spacing, equivalent controls, inline text, user-agent sizes and essential presentation. Overlays must not reach neighbours.
+**Except:** WCAG 2.5.8 permits spacing, equivalent controls, inline text, user-agent sizes and essential presentation. An overlay must not reach its neighbours.
 
 ## Tap target on a phone
 
@@ -48,27 +46,23 @@
 
 **Rule:** Keep a focus indicator at least 3:1 against every ground it reaches.
 
-**Why:** A solid band remains visible where glow alone may disappear.
-
-**Do:** Use G2’s solid band with a surface-coloured gap around accent-filled controls.
+**Do:** The solid band, with a surface-coloured gap around an accent-filled control.
 
-**Don't:** Use the halo alone as the focus indicator.
+**Don't:** The halo on its own, with no solid band inside it to measure.
 
-**Except:** The band must reach 4.22:1 on flat ground and 3:1 against actual gap and halo pixels.
+**Except:** The band must clear the bar against the gap and halo pixels too, not only against flat ground.
 
 ## Disabled control legibility
 
 <!-- rule: disabled-legibility -->
 
-**Rule:** Paint disabled controls with a different ink/surface pair from enabled controls.
+**Rule:** Give a disabled control its own ink and surface pair, and take the accent off it.
 
-**Why:** Opaque colours keep disabled text and surfaces readable.
+**Do:** Unavailable reads as unavailable with the pointer nowhere near it.
 
-**Do:** Use opaque `--disabled-ink`, `--disabled-surface` and `--disabled-border`.
+**Don't:** Unavailable keeps the live paint, so only the cursor reports the state.
 
-**Don't:** Fade the label and box together.
-
-**Except:** Labels must reach 3:1. Boxless ghosts use `--disabled-ink-bare`, floored at 4.89:1. Disabled controls must look weaker by changing the pair and removing accent. Only the label-free switch track may fade.
+**Except:** A disabled label must stay legible, so the pair changes rather than fades. Only the label-free switch track may fade.
 
 ## Touch field text
 
@@ -76,58 +70,60 @@
 
 **Rule:** Set coarse-pointer field text to 16px without scaling it down.
 
-**Why:** iOS Safari zooms fields below 16px and does not zoom out.
+**Why:** iOS Safari zooms into a field under 16px and does not zoom out. There is no specimen pair because the size answers to the pointer rather than the width, so both halves would draw the desktop size.
 
-**Do:** Apply real 16px text to `input`, `select` and `textarea`, including host fields.
+**Do:** Real 16px text in the field itself.
 
-**Don't:** Scale 16px down with transforms or smaller computed text.
+**Don't:** 16px scaled down, or a smaller computed size.
 
-**Except:** Preserve host fields above 16px with `!important` on a more specific selector. Checkbox, radio, range, colour, file and button types do not zoom. Do not remove pinch-zoom with `user-scalable=no` or `maximum-scale=1`. The host owns the viewport tag.
+**Except:** A host field above 16px keeps its size. Checkbox, radio, range, colour, file and button types do not zoom. Never take pinch-zoom away; the host owns the viewport tag.
 
 ## Body contrast
 
 <!-- rule: body-contrast -->
 
-**Rule:** Aim for body text contrast close to 7:1, not merely 4.5:1.
+**Rule:** Keep body text close to 7:1 at every size, not merely at 4.5:1.
 
-**Why:** Stronger contrast supports comfortable reading at every size.
+**Why:** Stronger contrast supports comfortable reading at every size. There is no specimen pair because a pale example would break this rule in front of the reader.
 
-**Do:** Use body ink at every size, then vary size, weight or spacing for hierarchy.
+**Do:** Body ink at every size, with size, weight and spacing carrying the hierarchy.
 
-**Don't:** Use pale body ink and rely on larger text for hierarchy.
+**Don't:** Pale ink propped up by larger text.
 
 ## Status labels
 
 <!-- rule: status-label -->
 
-**Rule:** Show every status with both a mark and a word.
+**Rule:** Name every status in words, not by its colour.
 
 **Why:** Colour alone is not reliably distinguishable.
 
-**Do:** Pair a status icon with text such as “Paused.”
+**Do:** The word carries the status; the tone fill agrees with it.
+
+**Don't:** A tone fill with the word taken out of it.
 
-**Don't:** Show success using green colour alone.
+**Except:** A status badge needs no glyph or dot. A callout or toast keeps its glyph, because its words sit in a sentence rather than in a fill.
 
 ## Measurable pairs
 
 <!-- rule: measurable-pair -->
 
-**Rule:** Prefer opaque grounds behind text so contrast can be measured.
+**Rule:** Keep text on opaque grounds so its contrast can be measured.
 
-**Why:** Gradients, filters and translucent layers make contrast uncertain.
+**Why:** A gradient, filter or translucent layer puts the ink on more than one ground, so no single pair can be read off it.
 
-**Do:** Place text on an opaque surface with a measurable ink pair.
+**Do:** One opaque ground under the whole sentence.
 
-**Don't:** Place text over a gradient, filter or translucent layer.
+**Don't:** The same sentence crossing a gradient, where each word sits on a different pair.
 
 ## Keyboard first
 
 <!-- rule: keyboard-first -->
 
-**Rule:** Implement keyboard behaviour before pointer behaviour and styling.
+**Rule:** Build keyboard behaviour before pointer behaviour and styling.
 
-**Why:** Keyboard access defines the interaction before visual polish.
+**Why:** Keyboard access defines the interaction before visual polish. There is no specimen pair because this is an order of work: both halves look the same once they are finished.
 
-**Do:** Make focus, order and keyboard actions work before styling controls.
+**Do:** Focus, order and keyboard actions working before anything is styled.
 
-**Don't:** Style pointer interactions before implementing keyboard behaviour.
+**Don't:** Pointer styling first and keyboard behaviour afterwards.

package/guidelines/text-length.md

@@ -6,6 +6,8 @@
 
 **Rule:** Labels, buttons, badges and status text name the field, action or state in a few words.
 
+**Why:** A control is read in the moment before acting, not studied.
+
 **Do:** “Save invoice.”
 
 **Don't:** “Click here to save your invoice.”
@@ -16,6 +18,8 @@
 
 **Rule:** Use one sentence for needed units, dates or limits.
 
+**Why:** The figure above the caption cannot say its unit, its period or what it leaves out.
+
 **Do:** “March revenue in EUR, excluding refunds.”
 
 **Don't:** “An overview of your revenue.”
@@ -26,6 +30,8 @@
 
 **Rule:** Add a short introduction only for a purpose or step the title and controls leave unclear.
 
+**Why:** An introduction that repeats the title costs the reader their place on the page.
+
 **Do:** “Upload a CSV with invoice numbers, dates and amounts.”
 
 **Don't:** “Manage your invoices here.”
@@ -36,6 +42,8 @@
 
 **Rule:** Explain a consequence or next step in one or two sentences.
 
+**Why:** A callout earns its interruption by naming the consequence and what to do about it.
+
 **Do:** “Deleting this workspace deletes its reports. Export them first.”
 
 **Don't:** “Think carefully before proceeding.”
@@ -48,6 +56,8 @@
 
 **Rule:** Cut text readers can decide and finish without.
 
+**Why:** Every spare word is read before it can be discarded.
+
 **Do:** “Exports include only filtered rows.”
 
 **Don't:** “Export quickly and easily.”

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@apliteni/apliteni-ui",
-  "version": "0.73.0",
+  "version": "0.75.0",
   "workspaces": [
     "react"
   ],

package/src/styles/code.css

@@ -91,12 +91,21 @@
 .ui-snippet--reveal .ui-snippet__bar > span { color: var(--chip-success-ink); }
 .ui-snippet--reveal pre { color: var(--chip-success-ink); word-break: break-all; white-space: pre-wrap; }
 
-/* Inline code */
+/* Inline code. The chip paints whichever reading surface its container is not on, so an
+   identifier keeps its chip on the page and inside a card, with no edge of its own. The
+   container hands the surface over in --code-bg; see src/tokens/tokens.css. #537
+
+   The chip READS --code-bg and never declares it, which is why its gap can match its paint
+   and its ring is composed here instead of in the shared recipe: a chip that re-pointed the
+   hand-off would hand the page to itself and paint the page everywhere. Backticks become a
+   chip wherever the kit renders prose (fmt() in site/changelog.mjs), so a link inside one is
+   ordinary markup and gets the gap of the surface it is actually on. */
 .ui-code {
   font-family: var(--font-mono);
   font-size: 0.9em;
-  background: var(--surface); --ring-gap: var(--surface);
+  background: var(--code-bg); --ring-gap: var(--code-bg);
   padding: 2px 6px;
   border-radius: var(--radius-xs);
   color: var(--text);
+  --ring: 0 0 0 var(--ring-gap-width) var(--ring-gap), 0 0 0 calc(var(--ring-gap-width) + var(--ring-width)) var(--ring-color), 0 0 12px 2px color-mix(in srgb, var(--ring-color) 45%, transparent);
 }

package/src/styles/table.css

@@ -123,8 +123,10 @@
 /* The empty state (.ui-empty) — shown when a table/list has no rows — now
    lives in styles/empty.css as a standalone component (illustration support). */
 
-/* Tables share their containing card’s reading surface, including pinned cells. */
-.ui-card { --table-bg: var(--surface); }
+/* Tables share their containing card’s reading surface, including pinned cells. The code
+   chip's hand-off travels with it, so an identifier in a cell keeps the page rather than
+   the card the cell is now painted with. why: src/tokens/tokens.css */
+.ui-card { --table-bg: var(--surface); --table-code-bg: var(--bg); }
 
 /* White in light, base canvas in dark; never a grey or tinted data surface. */
 .ui-table { background: var(--table-bg); --ring-gap: var(--table-bg); }

package/src/tokens/tokens.css

@@ -139,6 +139,16 @@
      --elev-drop under its inner line. why: docs/specification.md#elevation */
   --bg: #0e0d14;
   --table-bg: var(--bg);
+  /* A dark table is flush with the page, so the reading surface an inline code chip has
+     left inside one is the card. Light's table is white, so there it is the page. */
+  --table-code-bg: var(--surface);
+  /* A translucent wash paints BEHIND a chip, so it moves the ground and not the chip: the
+     pair has to be read against the wash composited over whatever opaque surface is under
+     it. Dark's washes lift a near-black ground away from the page, so the page is what the
+     chip has left; light's darken white toward the page, so the card is. Both directions
+     hold over EVERY opaque ground, which is why this is a token and not a context rule.
+     Measured in stories/code-chip.test.js. */
+  --wash-code-bg: var(--bg);
   --surface-2: #161520;     /* non-text sunken marks and tracks */
   --surface: #211e2d;       /* the card */
   --bg-elevated: #2a2639;   /* FLOATING — menus, panels, drawer, modal, toasts */
@@ -319,6 +329,8 @@
      why: docs/specification.md#elevation */
   --bg: #f2f3f6;
   --table-bg: #ffffff;
+  --table-code-bg: var(--bg);
+  --wash-code-bg: var(--surface);
   --surface-2: #e9ecf3;     /* non-text sunken marks and tracks */
   --surface: #ffffff;       /* the card */
   --bg-elevated: #ffffff;   /* FLOATING — menus, panels, drawer, modal, toasts */
@@ -472,9 +484,19 @@
   --prose-dense: 72ch;
 }
 
-/* Recompose only at painted containers; controls inherit the outside gap.
- * One recipe keeps surface propagation cheap and consistent.
- * why: docs/specification.md#the-focus-ring */
+/* An inline code chip is text on a chip, so #455 leaves it two grounds and no grey: the
+ * page and the card. It cannot read the one it is on — a var() inside a custom property is
+ * substituted on the element that DECLARES it — so the painted container hands it the one
+ * it is not using itself, and the chip keeps a step wherever it is written. The page hands
+ * over the card below; every painted container hands over the page, in the recipe under it.
+ * Held by stories/code-chip.test.js. why: docs/specification.md#elevation */
+:root { --code-bg: var(--surface); }
+
+/* Recompose only at painted containers; controls inherit the outside gap, and each hands an
+ * inline code chip the page. One recipe keeps surface propagation cheap and consistent.
+ * .ui-code composes its own ring in src/styles/code.css instead of joining this list: a
+ * chip cannot both paint --code-bg and re-point it, and its gap has to be the surface it
+ * actually paints. why: docs/specification.md#the-focus-ring */
 .amenu,
 .dtsw,
 .rx-modal,
@@ -485,7 +507,6 @@
 .ui-card--accent,
 .ui-card--live,
 .ui-cmdk__panel,
-.ui-code,
 .ui-confirm__panel,
 .ui-drawer__footer,
 .ui-drawer__panel,
@@ -509,8 +530,38 @@
 .ui-toast--solid,
 .vsw__menu {
   --ring: 0 0 0 var(--ring-gap-width) var(--ring-gap), 0 0 0 calc(var(--ring-gap-width) + var(--ring-width)) var(--ring-color), 0 0 12px 2px color-mix(in srgb, var(--ring-color) 45%, transparent);
+  --code-bg: var(--bg);
 }
 
+/* The two painted grounds that are not a plain card, and what each has left to hand over.
+ *
+ * A table paints the page in dark and white in light and follows its card when it is in
+ * one, so its hand-off travels with --table-bg as a token pair (src/styles/table.css
+ * re-points both). A TINTED surface mixes its colour INTO the card, so the card is the
+ * surface it still has: light mixes the tint down from white, which moves a tinted card
+ * toward the page and leaves the page 1.02 away, while the card it is a variant of stays
+ * 1.07-1.14 off in both themes. Measured in stories/code-chip.test.js. */
+.ui-table,
+.ui-table--sticky thead th,
+.ui-table--pinned .ui-table__identity, .ui-table--pinned .ui-table__selection,
+.ui-table--hover:not(.ui-table--zebra) tbody tr:hover td,
+.ui-table--zebra tbody tr:nth-child(even) td,
+.ui-table--zebra tbody tr:hover td,
+.ui-table--zebra.ui-table--hover tbody tr:hover td { --code-bg: var(--table-code-bg); }
+.ui-card--accent,
+.ui-card--live,
+.ui-snippet--reveal { --code-bg: var(--surface); }
+
+/* A wash is not a rung: it is a layer the kit paints OVER one, and it paints behind a chip
+ * rather than under it, so the chip's ground moves and the chip does not. These five take
+ * caller markup — callout() and the success panel hand their body straight through — so a
+ * chip inside one is ordinary product markup rather than a shape anybody hand-places. */
+.ui-callout--info,
+.ui-callout--success,
+.ui-callout--warn,
+.ui-callout--danger,
+.ui-success { --code-bg: var(--wash-code-bg); }
+
 /* A container focused itself paints outside its own surface; descendants only
  * inherit its inside gap again after focus moves to them. */
 .ui-card:focus-visible,