neba 1.8.1 → 1.9.0

package/dist/tailwind.css

@@ -812,6 +812,77 @@
   margin: 0;
 }
 
+/* ---------------------------------------------------------------------------
+ * ScrollArea's edge fade
+ *
+ * The content is faded out at each edge that has more behind it, and only at
+ * those edges: at the top of a list there is nothing above, so there is no fade
+ * above. Which edges those are is Base UI's answer — it writes
+ * `data-overflow-y-start` and its three siblings onto the root — so all this
+ * does is turn four attributes into four lengths.
+ *
+ * A **mask** rather than a gradient painted over the content, because a
+ * gradient has to fade *to* a colour and there is no such colour here: a scroll
+ * area usually sits on a translucent acrylic sheet, and anything opaque drawn
+ * over its edges would be a bar of paint across the backdrop.
+ *
+ * Two masks composited rather than one, because the two axes are independent
+ * and a single gradient cannot fade in two directions. `intersect` is what makes
+ * the corner where both apply come out as the darker of the two rather than the
+ * sum, which would punch a hole.
+ *
+ * The horizontal pair is mapped through `:dir()` because a gradient's `to right`
+ * is physical and `data-overflow-x-start` is logical — under RTL the start of
+ * the axis is the right-hand edge.
+ * ------------------------------------------------------------------------- */
+
+.neba-scroll-fade {
+  --n-fade-start: 0px;
+  --n-fade-end: 0px;
+  --n-fade-top: 0px;
+  --n-fade-bottom: 0px;
+  --n-fade-left: var(--n-fade-start);
+  --n-fade-right: var(--n-fade-end);
+
+  mask-image:
+    linear-gradient(
+      to bottom,
+      transparent 0,
+      black var(--n-fade-top),
+      black calc(100% - var(--n-fade-bottom)),
+      transparent 100%
+    ),
+    linear-gradient(
+      to right,
+      transparent 0,
+      black var(--n-fade-left),
+      black calc(100% - var(--n-fade-right)),
+      transparent 100%
+    );
+  mask-composite: intersect;
+}
+
+.neba-scroll-fade:dir(rtl) {
+  --n-fade-left: var(--n-fade-end);
+  --n-fade-right: var(--n-fade-start);
+}
+
+[data-overflow-y-start] > .neba-scroll-fade {
+  --n-fade-top: var(--n-fade);
+}
+
+[data-overflow-y-end] > .neba-scroll-fade {
+  --n-fade-bottom: var(--n-fade);
+}
+
+[data-overflow-x-start] > .neba-scroll-fade {
+  --n-fade-start: var(--n-fade);
+}
+
+[data-overflow-x-end] > .neba-scroll-fade {
+  --n-fade-end: var(--n-fade);
+}
+
 /* ---------------------------------------------------------------------------
  * Links
  *
@@ -1496,6 +1567,39 @@
   pointer-events: none;
 }
 
+/* ---------------------------------------------------------------------------
+ * The target under a small control
+ *
+ * A tick is 18px because it is sized against the text beside it, and a finger
+ * is not. WCAG 2.5.8 asks for 24 CSS pixels in both directions, and a Checkbox,
+ * a Radio, a Switch and the × that removes a Chip are all under it at most
+ * steps of the ladder — a bare Checkbox in a table's tick column is the worst
+ * case, because there is no label beside it to press instead.
+ *
+ * What is drawn does not change by a pixel. An empty `::before` grows the box
+ * the pointer is tested against, and only where it is short of the minimum:
+ * `100%` on `top`/`bottom` resolves against the containing block's height and
+ * on `left`/`right` against its width, so one declaration widens each axis by
+ * exactly what that axis lacks. A Switch, already 44px wide at `lg`, grows only
+ * upward and downward. The `min(0px, …)` is what keeps it from ever shrinking
+ * a control that is already big enough.
+ *
+ * `--n-hit` is the floor, so a component that needs the 44px of a touch-first
+ * design can ask for it without a second rule.
+ *
+ * It lives here rather than in a Tailwind arbitrary variant for the reason the
+ * layer below does: `before:[inset:min(0px,calc((1.5rem_-_100%)/-2))]` is
+ * expressible and nobody should have to read it.
+ * ------------------------------------------------------------------------- */
+
+.neba-hit::before {
+  content: '';
+  position: absolute;
+  inset: min(0px, calc((var(--n-hit, 1.5rem) - 100%) / -2));
+  /* Nothing is painted here. The box exists to be pressed. */
+  border-radius: inherit;
+}
+
 /* ---------------------------------------------------------------------------
  * Interaction light
  *

package/dist/types.d.ts

@@ -455,6 +455,22 @@ export interface NebaChartLegend {
     /** Draws each series' current value beside its name. @default false */
     showValue?: boolean;
 }
+/**
+ * A point on a scale, and the colour family a reading takes once it has reached
+ * it.
+ *
+ * The one place in the library where a semantic colour is *computed*, and the
+ * reason it is here rather than in whichever component needed it first: a Meter
+ * and a GaugeChart are the same reading in two shapes, and a page carrying both
+ * must not disagree about where amber starts. Left to the caller that would be
+ * a ternary at every call site, and the fourth one would.
+ */
+export interface NebaThreshold {
+    /** The value from which this family applies, in the reading's own units. */
+    from: number;
+    /** What the bar, or the arc, turns at and above that point. */
+    color: NebaColor;
+}
 /** Style props shared by most components; spread into their own prop types. */
 export interface NebaStyleProps {
     /** @default 'solid' */

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "neba",
-  "version": "1.8.1",
+  "version": "1.9.0",
   "description": "A comprehensive React UI component library — buttons, fields, menus, dialogs, tables and much more — accessible and themeable, sharing one prop vocabulary and a translucent acrylic design language. ESM only, types included, dark mode built in.",
   "type": "module",
   "types": "dist/index.d.ts",
@@ -154,7 +154,7 @@
     "react-dom": "^19.2.8",
     "tailwindcss": "^4.3.3",
     "terser-glob": "^1.2.1",
-    "tsx": "^4.23.12",
+    "tsx": "^4.23.13",
     "typescript": "^6.0.3",
     "typescript-eslint": "^8.68.0",
     "vite": "^8.2.2",