@uncinq/css-components 1.26.0 → 1.27.0

package/css/components/btn-close.css

@@ -29,6 +29,13 @@
       width: var(--btn-close-icon-size, var(--icon-size));
     }
 
+    /* Not a .btn, so the focus ring is restated: the browser's own one can
+       vanish on a coloured panel */
+    &:focus-visible {
+      outline: var(--focus-outline-width) var(--focus-outline-style) var(--focus-color-outline);
+      outline-offset: var(--focus-outline-offset, 2px);
+    }
+
     @media (hover: hover) and (pointer: fine) {
       &:hover {
         background-color: var(--btn-close-color-background-hover, var(--btn-control-color-background-hover));

package/css/components/btn-menu.css

@@ -30,6 +30,13 @@
       width: var(--btn-menu-icon-size, var(--icon-size));
     }
 
+    /* Not a .btn, so the focus ring is restated: the browser's own one can
+       vanish on a coloured header */
+    &:focus-visible {
+      outline: var(--focus-outline-width) var(--focus-outline-style) var(--focus-color-outline);
+      outline-offset: var(--focus-outline-offset, 2px);
+    }
+
     @media (hover: hover) and (pointer: fine) {
       &:hover {
         background-color: var(--btn-menu-color-background-hover, var(--btn-control-color-background-hover));

package/css/components/drawer.css

@@ -16,8 +16,10 @@
  * Position variants: .drawer-start | .drawer-end | .drawer-top | .drawer-bottom
  * Inline variants:   .panel-inline-* — see components/panel.css
  *
- * Triggers: .js-dialog-toggle[data-target="#id"]
- * Close:    .js-dialog-close inside the panel, Escape, or a click outside
+ * Triggers: popovertarget="id", or commandfor="id" command="show-modal" for a
+ *           <dialog> — native, no script needed; see components/panel.css
+ * Close:    the same with popovertargetaction="hide" or command="close",
+ *           Escape, or a click outside
  */
 @layer components {
   .drawer {

package/css/components/dropdown.css

@@ -10,6 +10,9 @@
  *
  * Trigger:  .js-dropdown-toggle (nextElementSibling must be .dropdown-menu)
  *
+ * Without JavaScript (scripting: none), the menu opens on hover and on
+ * keyboard focus within the .dropdown instead, so its links stay reachable.
+ *
  * Expected HTML:
  *   <div class="dropdown">
  *     <button class="js-dropdown-toggle" aria-expanded="false">Label</button>
@@ -130,6 +133,45 @@
   }
   
 
+  /* ── Without JavaScript ──────────────────────────────────────────────
+   * No script to toggle .show: the menu follows the pointer and the keyboard
+   * focus instead. Scoped to scripting: none, so it never fights the script's
+   * own state when there is one. */
+
+  @media (scripting: none) {
+    /* The toggle opens nothing by itself here: it stops covering its item,
+       so a link next to it stays clickable */
+    .dropdown-toggle::before {
+      content: none;
+    }
+
+    /* Closing waits, so the pointer can cross a gap between the item and
+       its menu — a mega menu below a header, for instance. The menu has to
+       take the pointer meanwhile: once closed, visibility: hidden keeps it
+       out of the way. */
+    .dropdown > .dropdown-menu {
+      pointer-events: auto;
+      transition-delay: 0.4s;
+      transition-property: opacity, transform, visibility;
+    }
+
+    /* Keyboard focus only: a click leaves focus on the toggle, and the menu
+       would stay open once the pointer has gone */
+    .dropdown:is(:hover, :has(:focus-visible)) {
+      > .dropdown-menu {
+        opacity: 1;
+        pointer-events: auto;
+        transform: none;
+        transition-delay: 0s;
+        visibility: visible;
+      }
+
+      > .dropdown-toggle::after {
+        rotate: 180deg;
+      }
+    }
+  }
+
   /* ── Alignment variants ──────────────────────────────────────────── */
 
   .dropdown-menu-end {

package/css/components/modal.css

@@ -14,8 +14,10 @@
  *
  * Per-instance sizing: override --modal-max-width on the element.
  *
- * Triggers: .js-dialog-toggle[data-target="#id"]
- * Close:    .js-dialog-close inside the panel, Escape, or a click outside
+ * Triggers: popovertarget="id", or commandfor="id" command="show-modal" for a
+ *           <dialog> — native, no script needed; see components/panel.css
+ * Close:    the same with popovertargetaction="hide" or command="close",
+ *           Escape, or a click outside
  */
 @layer components {
   .modal {

package/css/components/panel.css

@@ -7,14 +7,19 @@
  * drawer.css sticks them to an edge.
  *
  * The tag picks the strategy, not the class. Either variant can be:
- * - <dialog> opened with showModal() — [open], native ::backdrop, top layer,
- *   and the browser handles Escape, the focus trap and inertness;
- * - any element carrying popover="auto", opened with showPopover() by the
- *   script you provide — same top layer, same ::backdrop, but no role of its
- *   own. Use this when the panel becomes a static region of the page above a
- *   breakpoint (see .panel-inline-*): a <dialog> is exposed as role="dialog"
- *   even when it is only styled as a sidebar, whereas a script can set that
- *   role solely while the panel is open.
+ * - <dialog> opened as a modal — [open], native ::backdrop, top layer, and the
+ *   browser handles Escape, the focus trap and inertness;
+ * - any element carrying popover="auto" — same top layer, same ::backdrop,
+ *   but no role of its own. Use this when the panel becomes a static region
+ *   of the page above a breakpoint (see .panel-inline-*): a <dialog> is
+ *   exposed as role="dialog" even when it is only styled as a sidebar,
+ *   whereas a script can set that role solely while the panel is open.
+ *
+ * Both open without a script, from native invokers on the buttons:
+ * popovertarget="x" for a popover, commandfor="x" command="show-modal" for a
+ * <dialog>, and their closing forms, popovertargetaction="hide" and
+ * command="close". closedby="any" lets a click on a <dialog>'s backdrop close
+ * it too. showModal() and showPopover() remain available to a script.
  *
  * Most selectors here are :where()-wrapped so they carry no specificity: the
  * variants and the host components always win without escalating. The
@@ -27,10 +32,11 @@
  * namespace, so --modal-* and --drawer-* stay the public API.
  *
  * Expected HTML:
- *   <dialog class="modal" id="x" aria-labelledby="xLabel">
+ *   <button commandfor="x" command="show-modal">...</button>
+ *   <dialog class="modal" id="x" aria-labelledby="xLabel" closedby="any">
  *     <div class="header">
  *       <p class="title" id="xLabel">...</p>
- *       <button class="btn-close js-dialog-close"></button>
+ *       <button class="btn-close" commandfor="x" command="close"></button>
  *     </div>
  *     <div class="content">...</div>
  *     <div class="footer">...</div>

package/css/utilities/scrollsnap.css

@@ -20,6 +20,11 @@
  *
  * Item width: --items-min-width (or --max-width-item), capped by
  * --items-carousel-max-width so the next item always peeks in.
+ * --items-carousel-min-width, unset by default, overrides the first for every
+ * carousel at once: set on :root, it gives them all one width whatever their
+ * grid says, and a component re-declaring it on itself keeps its own. It is
+ * only read while the row scrolls, so the grid it turns back into keeps
+ * --items-min-width.
  *
  * Bleed: --container-bleed, published by .container in @uncinq/css-base — one
  * gutter while the container spans the viewport, 0 once it caps, so the row
@@ -55,7 +60,7 @@
   .scrollsnap-md,
   .scrollsnap-lg,
   .scrollsnap-xl {
-    grid-auto-columns: min(var(--items-min-width, var(--max-width-item)), var(--items-carousel-max-width, 75vw));
+    grid-auto-columns: min(var(--items-carousel-min-width, var(--items-min-width, var(--max-width-item))), var(--items-carousel-max-width, 75vw));
     grid-auto-flow: column;
     grid-template-columns: none;
     justify-content: start;

package/docs/content/items.md

@@ -73,4 +73,4 @@ Add a [`.scrollsnap-*`](../../utilities/scrollsnap/) class to the same element.
 <div class="items scrollsnap-md">...</div>
 ```
 
-The carousel reads the same `--items-min-width`, so item width stays consistent between the two modes.
+The carousel reads the same `--items-min-width`, so item width stays consistent between the two modes, unless `--items-carousel-min-width` gives the carousels a width of their own (see [Scrollsnap](../../utilities/scrollsnap/#one-width-for-every-carousel)).

package/docs/overlays/dropdown.md

@@ -70,6 +70,14 @@ The script must also keep `aria-expanded` on the toggle in sync with the state.
 
 Transitions are inside `@media (prefers-reduced-motion: no-preference)`, so the three classes still work with motion disabled; they simply take effect instantly.
 
+## Without JavaScript
+
+With scripting disabled, nothing toggles `.show`, so under `@media (scripting: none)` the menu opens on `:hover` of the `.dropdown` and on keyboard focus inside it (`:has(:focus-visible)`) instead, and the chevron turns with it. The links stay reachable with a pointer and with the keyboard. Keyboard focus rather than `:focus-within`: a click leaves the focus on the toggle, and the menu would stay open after the pointer has gone.
+
+Two more adjustments apply in that mode. The toggle's `::before` no longer covers the whole item, since the toggle opens nothing by itself: a link next to it stays clickable. And the menu waits 0.4s before closing, so the pointer can cross a gap between the item and its menu, as with a mega menu laid out below a header.
+
+The rule never applies when a script runs, so it cannot fight the script's own state. It reaches the menu as a **direct child** of `.dropdown`, like the rest of the contract.
+
 ## Alignment
 
 `.dropdown-menu-end` aligns the menu to the inline end of its trigger rather than the start. It is the only variant, and it goes on the menu, not on the container.

package/docs/overlays/overview.md

@@ -31,4 +31,4 @@ Either variant works both ways, and the choice is an accessibility one rather th
 
 ## No JavaScript ships here
 
-`.modal`, `.drawer` and `.dropdown` all expect a script. The CSS defines the classes and attributes that script must toggle; each page documents the contract it needs.
+`.modal` and `.drawer` open and close without one, from native invokers on their buttons; a script only adds the dialog role, the inert background and the cases the platform leaves out. `.dropdown` expects a script, and falls back to hover and focus when scripting is off. Each page documents the contract it needs.

package/docs/overlays/panel.md

@@ -13,10 +13,11 @@ There is **no `.panel` class.** The selectors read `:where(.modal, .drawer)`, so
 ## Structure
 
 ```html
-<dialog class="modal" id="contact" aria-labelledby="contactLabel">
+<button commandfor="contact" command="show-modal">Contact</button>
+<dialog class="modal" id="contact" aria-labelledby="contactLabel" closedby="any">
   <div class="header">
     <p class="title" id="contactLabel">Contact</p>
-    <button class="btn-close js-dialog-close" aria-label="Close"></button>
+    <button class="btn-close" commandfor="contact" command="close" aria-label="Close"></button>
   </div>
   <div class="content">...</div>
   <div class="footer">...</div>
@@ -35,17 +36,17 @@ The panel itself carries **no padding**. It lives on the three sections instead,
 
 ## Two ways to open a panel
 
-**The tag picks the strategy, not the class.** Either variant works both ways.
+**The tag picks the strategy, not the class.** Either variant works both ways, and both open **without JavaScript**, from a native invoker on the button. See [The JavaScript contract](#the-javascript-contract).
 
-### `<dialog>` with `showModal()`
+### `<dialog>`, opened as a modal
 
-The browser handles Escape, the focus trap and making the rest of the page inert. You get `[open]`, the native `::backdrop` and the top layer for free.
+Opened by `command="show-modal"`, or `showModal()` from a script. The browser handles Escape, the focus trap and making the rest of the page inert. You get `[open]`, the native `::backdrop` and the top layer for free, and `closedby="any"` adds the click on the backdrop.
 
 This is the right choice when the panel is **always** a dialog.
 
-### `popover="auto"` with `showPopover()`
+### `popover="auto"`
 
-Same top layer, same native `::backdrop`, but the element carries no implicit role.
+Opened by `popovertarget`, or `showPopover()` from a script. Same top layer, same native `::backdrop`, but the element carries no implicit role.
 
 Use this when the panel becomes a static region of the page above a breakpoint, which is what the [inline variants](#inline-variants) do. The reason is an accessibility one: a `<dialog>` is exposed as `role="dialog"` even when it is only styled as a sidebar, whereas a script can set that role solely while the panel is actually open.
 
@@ -133,18 +134,24 @@ If you add a property to the panel rule, neutralise it in all four variants. Tha
 
 Pair the suffixes: a panel carrying `.panel-inline-md` needs its button carrying `.panel-trigger-md`, otherwise a button that opens nothing remains on screen at desktop width.
 
-The reason this is a second class rather than something CSS derives on its own is worth knowing, because it looks like a redundancy. Nothing structurally connects a trigger to its panel: the only link is `data-target` matching an `id`, and no selector can compare two attribute values. A positional rule would work only until somebody moved the markup, and a filter button typically lives in the page heading rather than beside the panel it opens. In practice both classes come from the same configuration value, so the pair cannot disagree.
+The reason this is a second class rather than something CSS derives on its own is worth knowing, because it looks like a redundancy. Nothing structurally connects a trigger to its panel: the only link is an attribute — `popovertarget`, `commandfor` or a script's `data-target` — matching an `id`, and no selector can compare two attribute values. A positional rule would work only until somebody moved the markup, and a filter button typically lives in the page heading rather than beside the panel it opens. In practice both classes come from the same configuration value, so the pair cannot disagree.
 
 ## The JavaScript contract
 
-This package ships no JavaScript. `.modal` and `.drawer` expect a script that provides:
+This package ships no JavaScript, and a panel does not strictly need any: the browser opens and closes it by itself, from native invokers on the buttons.
 
-| Hook | Role |
-| --- | --- |
-| `.js-dialog-toggle[data-target="#id"]` | Opens the panel it points at |
-| `.js-dialog-close` | Any element inside the panel that closes it |
+| Panel | Trigger | Close button |
+| --- | --- | --- |
+| `popover="auto"` | `popovertarget="id"` | `popovertarget="id" popovertargetaction="hide"` |
+| `<dialog>` | `commandfor="id" command="show-modal"` | `commandfor="id" command="close"` |
+
+Escape works on both. A click outside closes a popover through light dismiss, and a `<dialog>` once it carries `closedby="any"`. `popovertarget` is Baseline 2024, invoker commands (`commandfor`) Baseline 2025.
+
+A script then adds what the platform does not:
 
-Closing must also work on Escape and on a click outside. With `<dialog>` and `showModal()` the browser already does both. With `popover="auto"` the platform handles light dismiss and Escape too, so in practice the script mainly manages the role and the open call.
+- `role="dialog"` and `aria-modal` on a popover, only while it is open, and an inert background behind it;
+- closing the panel when one of its in-page anchors is followed;
+- opening and closing for markup without native invokers, or for a browser that does not know invoker commands yet, through hooks of its choosing — for instance `.js-dialog-toggle[data-target="#id"]` and `.js-dialog-close`.
 
 One case CSS cannot cover: a panel carrying a `.panel-inline-*` class that is **open** when the viewport crosses the breakpoint. The script has to close it, because nothing in CSS releases the backdrop, the scroll lock and the inert background.
 

package/docs/utilities/scrollsnap.md

@@ -53,13 +53,33 @@ Above its rung, every property is set to `revert-layer` rather than to a second
 
 ```css
 grid-auto-columns: min(
-  var(--items-min-width, var(--max-width-item)),
+  var(--items-carousel-min-width, var(--items-min-width, var(--max-width-item))),
   var(--items-carousel-max-width, 75vw)
 );
 ```
 
 Items take `--items-min-width`, the same value that drives the grid, capped by `--items-carousel-max-width` (default `75vw`). The cap is what guarantees the next item always peeks in, which is the affordance that tells a reader the row scrolls at all. Without it, a wide item on a narrow screen would fill the viewport and the carousel would look like a static card.
 
+### One width for every carousel
+
+`--items-carousel-min-width` is unset by default, so each carousel keeps the width its own grid gives it. Set it to give every carousel the same width, whatever their grid says:
+
+```css
+@layer tokens {
+  :root {
+    --items-carousel-min-width: 25ch;
+  }
+}
+```
+
+It inherits, so it can be set on a section rather than on `:root` to cover only the carousels inside it. A component that has to keep its own width hands it back on itself, which wins over the inherited value:
+
+```css
+.logos { --items-carousel-min-width: var(--items-min-width); }
+```
+
+It is only read while the row scrolls. Above its rung the grid comes back with `--items-min-width`, so the carousels can be narrowed without touching the grids they turn back into.
+
 ## The bleed, and why margin and padding disagree
 
 The row pulls out to the screen edge using `--container-bleed`, published by `.container` in [css-base](../../../css-base/layouts/container/#the---container-bleed-contract). The property inherits, so it reaches the row from a `.container` however far up it sits.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@uncinq/css-components",
-  "version": "1.26.0",
+  "version": "1.27.0",
   "description": "Framework-agnostic CSS component implementations.",
   "license": "MIT",
   "repository": {