# Changelog ## [0.18.11] - 2026-09-01 ### Changed - Cleaned up an internal reference left in a few source comments by `0.18.10`. No code or type behavior changed. ## [0.18.10] - 2026-09-01 ### Fixed - **`0.18.9`'s `JSX.IntrinsicElements` fix didn't actually reach consumers who deep-import these components** (`import '@iyulab/modern-app/dist/components/ MasterDetailLayout.js'` and similar for `InfoField`/`PageHeader`/`EmptyState`/ `GroupBox`/`InfoSection`/`ActionBar`). The augmentation lived in a separate file pulled in only via a side-effect-only type import, which the declaration bundler stripped from each component's published `.d.ts` as "unused". Each component's JSX augmentation now lives directly in its own source file instead, so it survives declaration bundling regardless of import path. Verified against the actual published tarball this time (`npm pack`), not just the local workspace. ## [0.18.9] - 2026-08-31 ### Fixed - **JSX couldn't type-check `InfoField`, `PageHeader`, `EmptyState`, `GroupBox`, `InfoSection`, `ActionBar`, or `MasterDetailLayout` in a `.tsx` consumer** — these seven have no `/react` wrapper by design (plain String/Number/Boolean properties work as a raw custom element in JSX on both React 18 and 19), but only `HTMLElementTagNameMap` was declared for them; `JSX.IntrinsicElements`, what `.tsx` actually checks against, never was. Every one of them failed `TS2339` the moment a consumer wrote it in JSX. Declared now, and pulled in from each component file itself (not just the barrel), so a deep import for tree-shaking still sees it. ## [0.18.8] - 2026-08-30 ### Fixed - **`SidebarLayout` ignored an explicit `collapsed: false` on a group config** — a group always rendered collapsed regardless of the configured initial state. `SidebarGroup.collapsed` defaults to `true`, and the binding used a boolean-attribute directive, which only ever adds the attribute — it never removes an already-absent one to force `false`, so the default silently won. Switched to a direct property binding, which sets the value regardless of the component's own default. ## [0.18.7] - 2026-08-27 ### Fixed - **`SidebarButton`, `SidebarLink`, and `SidebarGroup` lost their accessible name entirely in compact (icon-only) sidebar mode.** Compact mode hides the visible text label (`part="label"`), and hiding it also removes it from the accessibility tree — with no fallback, a screen reader announced these as unnamed buttons/links. When `label` is a plain string, it is now promoted to `aria-label` while compact; the visible label still drives the name when expanded, so nothing changes there. ## [0.18.6] - 2026-08-24 ### Fixed - **`SidebarLayout`'s sidebar and mobile-header backgrounds now fall back to `--u-bg-color-raised` instead of `--u-panel-bg-color`.** The sidebar is persistent chrome, not a floating overlay (card/menu/dialog) — `--u-panel-bg-color`'s light value is the same white as the page background, so an app that never set `--app-sidebar-bg` got a sidebar visually indistinguishable from the page (and, since `u-group-box` also read `--u-panel-bg-color`, from its own cards too — a three-way collapse). `--u-bg-color-raised` is the token this library already documents for chrome surfaces adjacent to the page background, and `u-group-box` switched to it in `0.18.2`; the sidebar now matches. Visual change for any consumer relying on the unset default — light: sidebar goes from `#FFFFFF` to `#FAFAFA`; dark: `#1E1E1E` to `#2A2A2A`, which also fixes the reported card/input collapse (`u-input`'s background stayed on `--u-panel-bg-color`, so the sidebar now reads one step lighter than form fields instead of identical to them). `--app-sidebar-bg`/`--app-header-bg` overrides still take precedence exactly as before. ## [0.18.5] - 2026-08-23 ### Fixed - **`App.load()` now initializes i18next before checking the `auth` gate.** Same ordering bug as `0.18.4`'s theme fix, one layer down: when `auth.me()` resolves to `null`, `load()` renders the login screen and returns before the shell is built, but `i18next.init()` used to run only after the auth check passed. Any `renderLogin` screen that calls `i18next.t()` for its copy rendered with i18next uninitialized (falling back to raw keys or an empty string, depending on `returnEmptyString`/`returnNull`). i18n setup is pure display configuration independent of auth state, so it now runs unconditionally before the gate alongside theme and icon setup — every render path, including the pre-auth login screen, has translations available. ## [0.18.4] - 2026-08-23 ### Fixed - **`App.load()` now initializes the theme before checking the `auth` gate.** When `auth.me()` resolves to `null`, `load()` calls `auth.renderLogin()` and returns before the shell is built — but `Theme.init()` used to run only after the auth check passed, so any `renderLogin` screen that relies on `--u-*` design tokens (background, spacing, accent colors) rendered with no stylesheet in the document at all. `Theme.init()` and `iconBasepath` setup are pure display configuration independent of auth state, so they now run unconditionally before the gate — every render path, including the pre-auth login screen, has tokens available. ## [0.18.3] - 2026-08-22 ### Fixed - **`SidebarButtonConfig.id`'s docs no longer claim external light-DOM `u-popover` anchoring works.** It doesn't: the rendered `` lives inside ``'s own shadow root, and `for="#id"` lookups never cross a shadow boundary — a popover placed outside the layout can never find the anchor, no matter how the `id` is passed. Documents the recipe that does work instead: assemble the trigger and its `u-popover` together inside a single `type: 'html'` item, with `placement` chosen from the sidebar's own state (a sideways flyout has no room once the sidebar widens on mobile; a vertical one always does). Not a code change — `id` still passes through exactly as before. ## [0.18.2] - 2026-08-19 ### Fixed - **`SidebarLayout`'s mobile-header and sidebar-header toggle buttons now have an accessible name.** Both are icon-only ``s with no `aria-label`, text, or `title` — a screen-reader user only ever heard an unnamed "button". Wired through the same locale registry `MasterDetailLayout.detailClose` already uses (`toggleMobileMenu` / `toggleSidebar`), so translations follow `registerLocale` automatically; default English labels preserve current behavior for everyone who hasn't set a `locale`. ### Added - **`SidebarButtonConfig.id?: string`.** Passed straight through to the rendered `` host, so a consumer can anchor a `u-popover` (or any `for="#id"` pattern) to a sidebar button using only public API — previously the only way to get an anchorable id was to reach into the internal, unexported `` tag name. Unset behaves exactly as before (no `id` attribute) — not a breaking change. ## [0.18.1] - 2026-08-19 ### Fixed - **`GroupBox`'s background no longer matches the surrounding page/sidebar in light mode, or input fields in dark mode.** It referenced the same token as those surfaces (`--u-panel-bg-color`); switched to `--u-bg-color-raised`, which both themes already define distinctly. ## [0.18.0] - 2026-08-17 ### Added - **`SidebarLink` now sets `aria-current="page"` on its inner `` when `selected` is true.** Previously `selected` only drove visual emphasis (a host attribute for CSS) — a screen-reader user had no way to tell which item was the current page. - **`SidebarLayoutConfig.mainAriaLabel?: string`.** When set, it's reflected as `aria-label` on the sidebar's main `