@webority/theme 0.6.1 → 0.6.3

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@webority/theme",
-  "version": "0.6.1",
+  "version": "0.6.3",
   "description": "Webority shared design system — Bootstrap 5.3 SCSS overrides, --wui-* tokens, and shared component CSS. The single source of brand chrome for React portals and Razor sites.",
   "license": "SEE LICENSE IN LICENSE",
   "publishConfig": {

package/scss/_components.scss

@@ -75,6 +75,13 @@
     min-height: var(--wui-control-height);
 }
 
+// Tactile press feedback — every variant AND every size (sm/md/lg). Kept
+// separate from the height rule above so sm/lg (which opt out of the shared
+// control height) still get the nudge. A signal, not a depth cue.
+.btn:not(.btn-pill):not(.btn-pill-sm):not(.u-action):not(.btn-icon):active:not(:disabled) {
+    transform: translateY(1px);
+}
+
 .btn-primary {
     // Pin hover/active to the pressed-primary token so a rebrand tracks
     // automatically instead of Bootstrap auto-shading $primary off-spec.
@@ -82,9 +89,27 @@
     --bs-btn-hover-border-color:  var(--wui-primary-pressed);
     --bs-btn-active-bg:           var(--wui-primary-pressed);
     --bs-btn-active-border-color: var(--wui-primary-pressed);
-    &:active:not(:disabled) {
-        transform: translateY(1px);
-    }
+}
+
+.btn-danger {
+    // Pin hover/active to the pressed-danger token so Bootstrap cannot auto-shade the fill
+    // off-spec — the same treatment .btn-primary gets above. That is what stops the label
+    // flipping between states: once the fill stops moving, color-contrast() resolves the
+    // same way on every state.
+    //
+    // The label is deliberately NOT pinned to white. --wui-danger (#F8285A) carries white
+    // at 3.86:1 and --wui-danger-active (#E82646) at 4.38:1, both under the 4.5:1 AA floor,
+    // so forcing white is a serious color-contrast violation — axe flags it on BOTH
+    // surfaces. Bootstrap's automatic choice (the dark label, 5.44:1) is the accessible one
+    // and is what has always shipped.
+    //
+    // If white-on-red is wanted — it is the conventional destructive look — the fix is to
+    // darken --wui-danger to about #C81340 (white 5.80:1), which is a brand decision, not a
+    // per-component override.
+    --bs-btn-hover-bg:            var(--wui-danger-active);
+    --bs-btn-hover-border-color:  var(--wui-danger-active);
+    --bs-btn-active-bg:           var(--wui-danger-active);
+    --bs-btn-active-border-color: var(--wui-danger-active);
 }
 
 

package/scss/wui/_choice.scss

@@ -188,6 +188,30 @@
 .search-select-placeholder {
     color: var(--color-text-subtle);
 }
+
+// AppSelectMini — the compact single-purpose picker (page size, a range switch). It shares
+// every behaviour with AppSelect and differs only in metrics.
+//
+// <wui-select compact> emitted this class and NOTHING styled it, so AppSelectMini rendered
+// byte-identical to a full-size select on both surfaces — the catalogue told people to
+// reach for it when they wanted something compact, and got a 44px control. It was invisible
+// to every gate because the class check only ever scanned the Razor tag helpers, never the
+// elements package that actually emits it.
+//
+// The metrics deliberately match `.select.tpg-select` (the native page-size select in table
+// pagination) so a compact wui select and a compact native select read as one control
+// rather than two sizes of the same idea.
+.search-select-compact .search-select-control {
+    height: 32px;
+    min-height: 32px;
+    min-width: 64px;
+    padding: 0 10px;
+    font-size: 13px;
+    font-weight: 600;
+}
+.search-select-compact .search-select-caret {
+    font-size: 12px;
+}
 // Menu matches the themed-select dropdown: 16px squircle, 4px padding, soft
 // shadow.
 .search-select-menu {

package/scss/wui/_controls.scss

@@ -550,6 +550,39 @@ textarea.textarea:focus {
     min-width: 0;
 }
 // Controls fill their field even though .field aligns children flex-start.
+//
+// The `<wui-*>` entries are load-bearing, not defensive. Every hard interactive control
+// is now `.field > wui-select > .search-select`, so the child combinator below stopped
+// reaching the inner div AND the real flex item — the custom element — was named by no
+// rule at all. With `align-items: flex-start` above, that means it shrinks to its
+// content: a select rendered 164px wide in a 377px column. Neither render parity nor the
+// interaction suite saw it, because BOTH surfaces wrap the same element and are equally
+// wrong, and the fixtures render at full width where nothing has to stretch.
+//
+// `display: block` is here for the same reason and is not redundant with the stretch: a
+// custom element is `display: inline` by default, so outside a flex `.field` — dropped
+// into a plain div, a grid cell, a table cell — it would still collapse. Being a flex
+// item blockifies it; nothing else does.
+wui-select,
+wui-autocomplete,
+wui-multiselect,
+wui-phone,
+wui-datepicker {
+    display: block;
+    width: 100%;
+}
+// AppSelectMini renders <wui-select compact> — a page-size / range picker that is
+// deliberately narrow and does NOT belong to a .field. It has to opt out of the width
+// above, or every toolbar picker stretches across its toolbar.
+wui-select[compact] {
+    display: inline-block;
+    width: auto;
+}
+.field > wui-select,
+.field > wui-autocomplete,
+.field > wui-multiselect,
+.field > wui-phone,
+.field > wui-datepicker,
 .field > .search-select,
 .field > .input-with-unit,
 .field > .input,