Skip to content

Keep dialog tiers relative to the dialog z-index token - #252

Merged
einari merged 2 commits into
mainfrom
fix/dialog-stack-zindex-respects-tokens
Sep 7, 2026
Merged

Keep dialog tiers relative to the dialog z-index token#252
einari merged 2 commits into
mainfrom
fix/dialog-stack-zindex-respects-tokens

Conversation

@einari

@einari einari commented Sep 7, 2026

Copy link
Copy Markdown
Contributor

Fixed

  • Dialogs now keep an application's --cratis-z-index-dialog override when they are assigned a stacking tier. Assigning a tier previously resolved the dialog's z-index to a bare number built on the built-in 1100 default, discarding the override — so a dialog opened from inside application chrome that the token had been raised above rendered behind it, present in the DOM but invisible.
  • Dropdown, date-picker and tooltip popovers opened inside a dialog now stack relative to that dialog's resolved z-index expression instead of doing arithmetic on a fixed number, so they follow the same override.

einari and others added 2 commits September 7, 2026 21:13
Assigning a dialog a stacking tier resolved its z-index to a bare number
built on the hardcoded 1100 default, which discarded any override of
--cratis-z-index-dialog the application had set. The token was only ever
consulted as the pre-tier fallback, so the moment the tier landed the
override was gone.

That is backwards for a token whose whole purpose is to let an
application place dialogs in its own stacking order. Cratis Studio
raises it to 10100 so dialogs clear the 9999 full-screen overlay its
settings pages live in; with the tier applied, every one of those
dialogs dropped back to 1100 and rendered behind the overlay that
opened it - in the DOM, focusable, and completely invisible.

Resolve a tier to a CSS expression relative to the token instead, and
compose popover offsets onto that expression rather than adding to a
number. The first tier is the token itself, so a lone dialog stacks
exactly where it did before tiering existed.

The specs that measure stacking order parsed those numbers straight out
of the DOM, so they now share a resolveZIndex helper that substitutes
the custom property and folds the calc() arithmetic jsdom does not
evaluate itself.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01D6XsJXFcUfr9FZnf3EuyCp
Nothing exercised the dialog stack registry directly, which is how a
tier resolving to a bare number shipped: every existing spec set the
z-index token to its own default, so a hardcoded 1100 and a resolved
token were indistinguishable.

Cover the registry itself, and add a dialog-level spec that raises the
token the way an application does and asserts the rendered dialog still
clears the chrome it was opened from.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01D6XsJXFcUfr9FZnf3EuyCp
@einari einari added the patch label Sep 7, 2026
@einari
einari merged commit cbcada8 into main Sep 7, 2026
41 of 42 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant