chore(release): version packages

[github-actions]

This PR was opened by the Changesets release GitHub action. When you're ready to do a release, you can merge this and the packages will be published to npm automatically. If you're not ready to do a release yet, that's fine, whenever you add more changesets to main, this PR will be updated.

Releases

@dunky.dev/browser-navigation@0.2.0

Minor Changes

• #46 5a58c2d Thanks @ivanbanov! - Rename @dunky.dev/dom-navigation to @dunky.dev/browser-navigation.

  The util guards the browser's session history — Back, Forward, reload — and
  never touches the DOM, so the old name pointed at the wrong layer. The API is
  unchanged; only the package name moves:

  -import { interceptBackNavigation } from '@dunky.dev/dom-navigation'
  +import { interceptBackNavigation } from '@dunky.dev/browser-navigation'

  @dunky.dev/dom-navigation will receive no further releases.

Patch Changes

• #48 979c3c7 Thanks @ivanbanov! - Fix two interceptBackNavigation bugs around releases:
  • Two guards released in the same synchronous turn no longer strand the
    shared popstate listener: the first release's idle check could detach it
    while the second release's self-caused pop was still in flight, leaving
    that pop uncounted — the next guard's first Back press was then misread as
    self-caused and its onBack never fired.
  • A guard that releases itself inside its own onBack (a legal use of the
    public API) no longer evicts the guard beneath it: the handler now removes
    the answering guard by identity instead of positionally, so lower layers
    stay armed and keep their history entries.

@dunky.dev/dom-dialog@0.1.1

Patch Changes

• #48 c35d1ab Thanks @ivanbanov! - openDialogLayer now warns when focus cannot move into the dialog at all —
  when the initial focus target refuses focus and the dialog window can't take
  the fallback either (typically because it lacks tabindex="-1"). Focus
  stranded outside an open modal breaks the modal dialog pattern; the miss used
  to be silent, now the warning names the fix.

• #46 5a58c2d Thanks @ivanbanov! - Rename @dunky.dev/dom-navigation to @dunky.dev/browser-navigation.

  The util guards the browser's session history — Back, Forward, reload — and
  never touches the DOM, so the old name pointed at the wrong layer. The API is
  unchanged; only the package name moves:

  -import { interceptBackNavigation } from '@dunky.dev/dom-navigation'
  +import { interceptBackNavigation } from '@dunky.dev/browser-navigation'

  @dunky.dev/dom-navigation will receive no further releases.

• Updated dependencies [979c3c7, 6ed64a2, c35d1ab, 5a58c2d]:

  • @dunky.dev/browser-navigation@0.2.0
  • @dunky.dev/dom-focus-trap@0.1.2
  • @dunky.dev/dom-overlay@0.1.2

@dunky.dev/dom-focus-trap@0.1.2

Patch Changes

• #48 6ed64a2 Thanks @ivanbanov! - Make the trap's Tab cycle match what a browser would actually focus.

  Three fixes, all consumer-visible:

  • The trap now intercepts Tab from anywhere in the document. The keydown
    listener moved from the container to the document (capture phase), so a Tab
    pressed while focus is still outside — on the trigger, or on body — wraps
    into the cycle at the edge instead of following native tab order out of the
    trap. Initial focus on open remains the caller's job.
  • Non-rendered elements no longer enter the cycle. Elements hidden via the
    hidden attribute, display: none (own or ancestor), or
    visibility: hidden are filtered out with Element.checkVisibility().
    Focusing a non-rendered element is a no-op, so a hidden element in the cycle
    used to stall the trap on it.
  • A same-name radio group is one tab stop. Per the APG radio group
    pattern, the stop is the checked radio, else the group's first; groups are
    scoped by name and form owner. The trap steps focus itself, so it now
    reproduces the browser's grouping instead of visiting every radio.

@dunky.dev/dom-overlay@0.1.2

Patch Changes

• #48 c35d1ab Thanks @ivanbanov! - Two fixes to how containment and the exit window treat pre-existing markup:
  • Elements marked aria-hidden="false" are now hidden behind a modal layer
    like any other, and the authored value is restored on undo. "false"
    asserts visible — the opposite of author-hidden — so the previous skip left
    such elements exposed to assistive tech behind an open modal. Only a truthy
    aria-hidden (or inert) still counts as the author's own hiding.
  • hideExitingLayer no longer inerts <html> when the supplied boundary is
    not an ancestor of the content. A stale or mismatched boundary used to
    exhaust the ancestor walk at the document root and take the whole page out
    for the exit window; the hide now falls back to the content itself.

@dunky.dev/dom-scroll-lock@0.1.2

Patch Changes

• #48 4208569 Thanks @ivanbanov! - Two lockScroll fixes:
  • Scrollbar compensation is now additive: the footprint is added on top of
    the target's computed padding instead of assigned over it. Previously the
    inline longhand won the cascade and erased any padding-inline-end /
    padding-block-end the target already had (inline or from a stylesheet),
    shifting layout the other way — the lock must not shift layout in either
    direction.
  • Release restores the saved inline styles via style.setProperty instead of
    branching per value: a saved '' (originally unset) removes the
    declaration per CSSOM, so the target returns to exactly what the first
    holder saw.

@dunky.dev/react-dialog@0.3.1

Patch Changes

• Updated dependencies [c35d1ab, 5a58c2d, 4208569]:
  • @dunky.dev/dom-dialog@0.1.1
  • @dunky.dev/react-use-scroll-lock@0.1.2
  • @dunky.dev/react-use-focus-trap@0.1.2

@dunky.dev/react-use-focus-trap@0.1.2

Patch Changes

• Updated dependencies [6ed64a2]:
  • @dunky.dev/dom-focus-trap@0.1.2

@dunky.dev/react-use-scroll-lock@0.1.2

Patch Changes

• #48 4208569 Thanks @ivanbanov! - useScrollLock now treats a null target as "no target yet" and locks
  nothing. Previously null collapsed into "the page body", so passing a
  not-yet-resolved element (e.g. ref.current on the first run) locked the
  page instead of the intended container — and never corrected itself. An
  omitted target still means the page body.

  Pass the element through something reactive so the lock engages once the
  node resolves — in React hold it in state (a ref populating doesn't
  re-render), in Solid pass a signal-backed element (a plain ref read is
  not reactive):

  // React
  const [panel, setPanel] = useState<HTMLElement | null>(null)
  useScrollLock(open, panel) // locks nothing until the node resolves
  
  // Solid
  const [panel, setPanel] = createSignal<HTMLElement | null>(null)
  useScrollLock(open, panel)

• Updated dependencies [4208569]:

  • @dunky.dev/dom-scroll-lock@0.1.2

@dunky.dev/solid-dialog@0.1.1

Patch Changes

• Updated dependencies [c35d1ab, 5a58c2d, 4208569]:
  • @dunky.dev/dom-dialog@0.1.1
  • @dunky.dev/solid-use-scroll-lock@0.1.1
  • @dunky.dev/solid-use-focus-trap@0.1.1

@dunky.dev/solid-use-focus-trap@0.1.1

Patch Changes

• Updated dependencies [6ed64a2]:
  • @dunky.dev/dom-focus-trap@0.1.2

@dunky.dev/solid-use-scroll-lock@0.1.1

Patch Changes

• #48 4208569 Thanks @ivanbanov! - useScrollLock now treats a null target as "no target yet" and locks
  nothing. Previously null collapsed into "the page body", so passing a
  not-yet-resolved element (e.g. ref.current on the first run) locked the
  page instead of the intended container — and never corrected itself. An
  omitted target still means the page body.

  Pass the element through something reactive so the lock engages once the
  node resolves — in React hold it in state (a ref populating doesn't
  re-render), in Solid pass a signal-backed element (a plain ref read is
  not reactive):

  // React
  const [panel, setPanel] = useState<HTMLElement | null>(null)
  useScrollLock(open, panel) // locks nothing until the node resolves
  
  // Solid
  const [panel, setPanel] = createSignal<HTMLElement | null>(null)
  useScrollLock(open, panel)

• Updated dependencies [4208569]:

  • @dunky.dev/dom-scroll-lock@0.1.2