@epam/ai-dial-ui-kit 0.15.0-dev.27 → 0.15.0-dev.30

package/dist/CHANGELOG.md

@@ -37,6 +37,8 @@ Versions match the git tags on the `development` branch.
 
 - **`InlineSelect` (2.0) — `triggerClassName`, `triggerLabelClassName` and `onOpenChange`** — the trigger could not be restyled: `InlineSelect` took no class for it, and a caller whose design puts the value in a bordered pill, themed by its own colour properties, had to keep a hand-rolled trigger beside the kit `Dropdown`. `triggerClassName` is merged onto the trigger button after its own classes, `triggerLabelClassName` onto its label (now a `<span>`, so a type-scale or colour class has something to land on), and `onOpenChange` reports the dropdown opening and closing, for a caller that reacts to it beyond what `aria-expanded` styles. All three are additive; nothing renders differently without them. Requested in [ai-dial-chat](https://github.com/epam/ai-dial-chat) for the share popover's access pill.
 
+- **`InlineSelect` (2.0) — controlled `open`, and `listStyle`** — `onOpenChange` reported the dropdown opening, but the caller could not close it: a popover that owns Escape (closing its own menu first and itself only on a second press) had no way to shut the select without shutting itself. `open` makes the open state controlled, the same way `Dropdown`'s already is; without it the select keeps its own. `listStyle` is passed through to the `Dropdown` overlay, which renders in a portal, so custom properties a caller sets on its own wrapper can reach the rows, as they already can for `Dropdown`. Both are additive; nothing renders differently without them.
+
 ### Fixed
 
 - **`Button` and `IconButton` (2.0) — a disabled button's tooltip opens** — `tooltipProps` wraps the button in `<Tooltip asChild>`, but a natively `disabled` button receives no pointer or focus events, so its tooltip could never open. That is exactly the state where a "why is this unavailable" hint matters, and callers worked around it with their own `<span>` wrapper, which no keyboard user could reach either. A disabled button that has a visible tooltip is now marked `aria-disabled="true"` instead of `disabled`: it stays in the tab order and answers hover and focus, so the tooltip opens for mouse and keyboard users alike, and it is still announced as unavailable. Its click is swallowed with `preventDefault`, so neither `onClick` nor a `type="submit"` form submission fires. Without a tooltip, or while `hideTooltip` is set, the button stays natively disabled as before. The disabled look is unchanged, since every 2.0 variant already styles `[aria-disabled="true"]`; the two ghost icon-button rules that styled only `:disabled` now style both. Requested in [ai-dial-chat](https://github.com/epam/ai-dial-chat), where the chat-settings dialog explains why "Apply changes" is disabled.