@hanzo/ui 8.27.2 → 8.27.3

package/dist/gallery.html

@@ -1,4 +1,4 @@
-<!doctype html><html lang="en" class="t_dark"><head><meta charset="utf-8"><meta name="viewport" content="width=device-width,initial-scale=1"><title>@hanzo/ui 8.27.2</title><style>/* @hanzo/ui — generated by scripts/gen-css.mjs. Do not edit. */
+<!doctype html><html lang="en" class="t_dark"><head><meta charset="utf-8"><meta name="viewport" content="width=device-width,initial-scale=1"><title>@hanzo/ui 8.27.3</title><style>/* @hanzo/ui — generated by scripts/gen-css.mjs. Do not edit. */
 :root { --hanzo-ui-styles: 1; }
 /* Hanzo Design System — the entry point. Import THIS one file.
  *
@@ -1997,6 +1997,37 @@
   }
 }
 
+/* FOCUS RINGS THE CONTROL A PERSON SEES, WHICH IS THE WHOLE COMPOSER.
+
+   `Composer` is a bordered box holding a field above a toolbar row, so it reads
+   as one control the way a chat composer everywhere does. The field inside it is
+   an ordinary textarea, so the indicator was drawn round the field alone: a
+   second rounded rectangle nested inside the box, stopping above the mic and the
+   send button, which reads as the top half being selected. WCAG 2.4.11 asks the
+   indicator to enclose the control, and the control here is the composer.
+
+   THE FIELD DOES NOT ABSTAIN, and control.ts is right that it must not: gui
+   compiles `focusVisibleStyle` to `:root:root:root:root … !important`, past any
+   sheet, so a field that says `outlineWidth: 0` deletes the indicator on every
+   surface at once. What gui declares is `outline-color: var(--outlineColor)` —
+   a VARIABLE — so the colour is re-pointed for this one field instead, in the
+   same breath as the host taking the ring up. The declaration gui emits is
+   untouched and `focus.test.tsx` still reads it.
+
+   Both rules turn on the SAME condition, which is what makes it safe: where
+   `:has` is unsupported neither applies and the field keeps drawing its own
+   ring, so no browser reaches a state with a focused composer and no indicator
+   anywhere. */
+[data-slot='composer']:has([data-slot='composer-field']:focus-visible) {
+  outline: 2px solid var(--ring);
+  outline-offset: 2px;
+}
+
+[data-slot='composer']:has([data-slot='composer-field']:focus-visible)
+  [data-slot='composer-field'] {
+  --outlineColor: transparent;
+}
+
 [stylesheet-group="0"]{}
 body{margin:0;}
 button::-moz-focus-inner,input::-moz-focus-inner{border:0;padding:0;}

package/dist/glass.css

@@ -486,3 +486,34 @@
     animation: none;
   }
 }
+
+/* FOCUS RINGS THE CONTROL A PERSON SEES, WHICH IS THE WHOLE COMPOSER.
+
+   `Composer` is a bordered box holding a field above a toolbar row, so it reads
+   as one control the way a chat composer everywhere does. The field inside it is
+   an ordinary textarea, so the indicator was drawn round the field alone: a
+   second rounded rectangle nested inside the box, stopping above the mic and the
+   send button, which reads as the top half being selected. WCAG 2.4.11 asks the
+   indicator to enclose the control, and the control here is the composer.
+
+   THE FIELD DOES NOT ABSTAIN, and control.ts is right that it must not: gui
+   compiles `focusVisibleStyle` to `:root:root:root:root … !important`, past any
+   sheet, so a field that says `outlineWidth: 0` deletes the indicator on every
+   surface at once. What gui declares is `outline-color: var(--outlineColor)` —
+   a VARIABLE — so the colour is re-pointed for this one field instead, in the
+   same breath as the host taking the ring up. The declaration gui emits is
+   untouched and `focus.test.tsx` still reads it.
+
+   Both rules turn on the SAME condition, which is what makes it safe: where
+   `:has` is unsupported neither applies and the field keeps drawing its own
+   ring, so no browser reaches a state with a focused composer and no indicator
+   anywhere. */
+[data-slot='composer']:has([data-slot='composer-field']:focus-visible) {
+  outline: 2px solid var(--ring);
+  outline-offset: 2px;
+}
+
+[data-slot='composer']:has([data-slot='composer-field']:focus-visible)
+  [data-slot='composer-field'] {
+  --outlineColor: transparent;
+}

package/dist/styles.css

@@ -1997,6 +1997,37 @@
   }
 }
 
+/* FOCUS RINGS THE CONTROL A PERSON SEES, WHICH IS THE WHOLE COMPOSER.
+
+   `Composer` is a bordered box holding a field above a toolbar row, so it reads
+   as one control the way a chat composer everywhere does. The field inside it is
+   an ordinary textarea, so the indicator was drawn round the field alone: a
+   second rounded rectangle nested inside the box, stopping above the mic and the
+   send button, which reads as the top half being selected. WCAG 2.4.11 asks the
+   indicator to enclose the control, and the control here is the composer.
+
+   THE FIELD DOES NOT ABSTAIN, and control.ts is right that it must not: gui
+   compiles `focusVisibleStyle` to `:root:root:root:root … !important`, past any
+   sheet, so a field that says `outlineWidth: 0` deletes the indicator on every
+   surface at once. What gui declares is `outline-color: var(--outlineColor)` —
+   a VARIABLE — so the colour is re-pointed for this one field instead, in the
+   same breath as the host taking the ring up. The declaration gui emits is
+   untouched and `focus.test.tsx` still reads it.
+
+   Both rules turn on the SAME condition, which is what makes it safe: where
+   `:has` is unsupported neither applies and the field keeps drawing its own
+   ring, so no browser reaches a state with a focused composer and no indicator
+   anywhere. */
+[data-slot='composer']:has([data-slot='composer-field']:focus-visible) {
+  outline: 2px solid var(--ring);
+  outline-offset: 2px;
+}
+
+[data-slot='composer']:has([data-slot='composer-field']:focus-visible)
+  [data-slot='composer-field'] {
+  --outlineColor: transparent;
+}
+
 [stylesheet-group="0"]{}
 body{margin:0;}
 button::-moz-focus-inner,input::-moz-focus-inner{border:0;padding:0;}

package/dist/theme.css

@@ -1994,3 +1994,34 @@
     animation: none;
   }
 }
+
+/* FOCUS RINGS THE CONTROL A PERSON SEES, WHICH IS THE WHOLE COMPOSER.
+
+   `Composer` is a bordered box holding a field above a toolbar row, so it reads
+   as one control the way a chat composer everywhere does. The field inside it is
+   an ordinary textarea, so the indicator was drawn round the field alone: a
+   second rounded rectangle nested inside the box, stopping above the mic and the
+   send button, which reads as the top half being selected. WCAG 2.4.11 asks the
+   indicator to enclose the control, and the control here is the composer.
+
+   THE FIELD DOES NOT ABSTAIN, and control.ts is right that it must not: gui
+   compiles `focusVisibleStyle` to `:root:root:root:root … !important`, past any
+   sheet, so a field that says `outlineWidth: 0` deletes the indicator on every
+   surface at once. What gui declares is `outline-color: var(--outlineColor)` —
+   a VARIABLE — so the colour is re-pointed for this one field instead, in the
+   same breath as the host taking the ring up. The declaration gui emits is
+   untouched and `focus.test.tsx` still reads it.
+
+   Both rules turn on the SAME condition, which is what makes it safe: where
+   `:has` is unsupported neither applies and the field keeps drawing its own
+   ring, so no browser reaches a state with a focused composer and no indicator
+   anywhere. */
+[data-slot='composer']:has([data-slot='composer-field']:focus-visible) {
+  outline: 2px solid var(--ring);
+  outline-offset: 2px;
+}
+
+[data-slot='composer']:has([data-slot='composer-field']:focus-visible)
+  [data-slot='composer-field'] {
+  --outlineColor: transparent;
+}

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@hanzo/ui",
-  "version": "8.27.2",
+  "version": "8.27.3",
   "type": "module",
   "description": "Hanzo UI — the one canonical Hanzo component library, on @hanzo/gui + @hanzo/design. ONE substrate: every component renders through @hanzo/gui primitives, so the same import works on web, native (expo) and desktop (Tauri). Self-contained (theme.css), presentational, host-agnostic, clean-room.",
   "exports": {