origam 2.18.10 → 2.18.11

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.
@@ -440,6 +440,24 @@ defineExpose({
440
440
  .origam-btn {
441
441
  $this: &;
442
442
 
443
+ // ⛔ #933 — `display` was never declared here. The root then fell back
444
+ // to the UA default, which for the `<a>` / `<span>` tags `useLink`
445
+ // renders is `inline`. An inline box ignores `height`, `min-width` and
446
+ // vertical `padding`, and it stretches to the full line box — so a Btn
447
+ // dropped into a plain block parent (`<p>`, `<div>`) rendered as a
448
+ // full-width, 15px-tall strip. Every Btn in this DS *looked* correct
449
+ // only because its parent happened to be a flex/grid container, which
450
+ // blockifies the child: measured on the marketing site, all 9 visible
451
+ // Btn roots computed `display: block` with a `display: flex` parent,
452
+ // and the single Btn inside a `<p>` computed `inline` at 984px wide.
453
+ //
454
+ // `inline-block` is the value the rest of this rule already assumed —
455
+ // `vertical-align: middle` right below only has meaning on an
456
+ // inline-level box. It is also the safest: inside a flex/grid parent it
457
+ // blockifies to `block`, i.e. byte-for-byte today's computed value, so
458
+ // no existing layout moves. `&--block` still overrides it with `flex`.
459
+ display: inline-block;
460
+
443
461
  position: var(--origam-btn---position, relative);
444
462
  vertical-align: middle;
445
463
  flex-shrink: 0;
@@ -355,7 +355,16 @@ defineExpose({
355
355
  }
356
356
 
357
357
  &--nav {
358
- --origam-list---padding-inline: 8px;
358
+ // ⛔ #934 — this used to declare `--origam-list---padding-inline`,
359
+ // a name NOTHING reads. A custom property is not a shorthand: it
360
+ // expands to nothing, so `padding-inline-start/end` above kept
361
+ // resolving to the sheet's `--origam-space---0`. Measured on the
362
+ // marketing appbar menu across all 8 identities: list inline
363
+ // padding `0px/0px`, so the rows ran edge-to-edge inside the menu
364
+ // and their hover surface was clipped by the menu's own corner
365
+ // radius. The two longhands are the names the base rule reads.
366
+ --origam-list---padding-inline-start: var(--origam-space---2, 8px);
367
+ --origam-list---padding-inline-end: var(--origam-space---2, 8px);
359
368
  --origam-list-subheader---font-size: var(--origam-list__subheader---nav-font-size, 0.75rem);
360
369
  --origam-list---indent-padding: var(--origam-list---indent-padding-nav, -8px);
361
370
  }
@@ -626,7 +626,12 @@ defineExpose({
626
626
  }
627
627
 
628
628
  &--nav {
629
- --origam-list-item---padding-inline: 8px;
629
+ // ⛔ #934 — same dead name as `.origam-list--nav` carried:
630
+ // `--origam-list-item---padding-inline` is read nowhere. The base
631
+ // rule reads the two longhands, inside a `calc()` that also folds
632
+ // in indent and density, so they go in here under the same names.
633
+ --origam-list-item---padding-inline-start: var(--origam-space---2, 8px);
634
+ --origam-list-item---padding-inline-end: var(--origam-space---2, 8px);
630
635
 
631
636
  &:not(:only-child) {
632
637
  --origam-list-item---margin-block-end: 4px;
@@ -473,6 +473,44 @@ defineExpose({
473
473
  }
474
474
  }
475
475
  }
476
+
477
+ /*
478
+ * ⛔ MEASURED (Chromium, /why-origam demo, all 8 marketing identities,
479
+ * light + dark, checked + unchecked): `OrigamSelectionControl`'s shared
480
+ * `&--focus-visible` rule draws its outline on
481
+ * `.origam-selection-control__input` — a ~28px square hit-area that is
482
+ * a SIBLING of `.origam-switch-track` (rendered via the `default`
483
+ * slot), never a descendant. The track's `overflow: hidden` therefore
484
+ * can never clip that outline, and because the square hit-area is
485
+ * already taller than the track (24px default / 32px inset) and offset
486
+ * by the thumb's hardcoded ±10px `translateX`, the ring visibly
487
+ * detaches from the track: 8px past its top/bottom edge and 8px past
488
+ * whichever side the thumb isn't currently near (right when ON, left
489
+ * when OFF) on every identity, `material` included — its own
490
+ * screenshot simply wasn't captured while focused.
491
+ *
492
+ * For Checkbox/Radio the square hit-area IS the visible control, so
493
+ * the shared rule is correct there and stays untouched
494
+ * (`OrigamSelectionControl.vue` is not modified). For Switch the
495
+ * visible control is the elongated track, so the ring is moved onto
496
+ * `.origam-switch-track` instead — same two tokens the shared rule
497
+ * already reads (`--origam-border__width---2`,
498
+ * `--origam-color__border---focus`), just retargeted to the shape a
499
+ * switch actually is. Native `outline` already follows an element's
500
+ * own `border-radius` in every supported browser, so the ring traces
501
+ * the track's real shape (pill / rounded / square per `rounded` prop)
502
+ * with no extra CSS.
503
+ */
504
+ &--focus-visible {
505
+ :deep(.origam-selection-control__input) {
506
+ outline: none;
507
+ }
508
+
509
+ :deep(.origam-switch-track) {
510
+ outline: var(--origam-border__width---2, 2px) solid var(--origam-color__border---focus, currentColor);
511
+ outline-offset: var(--origam-space---1, 2px);
512
+ }
513
+ }
476
514
  }
477
515
 
478
516
  &.origam-input {
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "origam",
3
- "version": "2.18.10",
3
+ "version": "2.18.11",
4
4
  "type": "module",
5
5
  "description": "origam — a Vue 3 design system with multi-theme design tokens, CSS-first components and TypeScript types.",
6
6
  "keywords": [