Microsoft/monaco-editor

[Feature Request] Document z-index usage and add some logic to it

Open

#2,844 opened on Dec 20, 2021

View on GitHub
 (5 comments) (3 reactions) (0 assignees)JavaScript (1,283 forks)batch import
editor-corefeature-requesthelp wanted

Repository metrics

Stars
 (14,836 stars)
PR merge metrics
 (Avg merge 6h 26m) (15 merged PRs in 30d)

Description

Context

  • This issue is not a bug report. (please use a different template for reporting a bug)
  • This issue is not a duplicate of an existing issue. (please use the search to find existing issues)

Description

z-index across Monaco appears to not follow any logic. I'm putting a full-screen overlay over the editor and just realized you can still drag the handle between the two halfs of the diff editor. Looking at the CSS it has a z-index of 35:

.monaco-sash {
    z-index: 35;
}

I'm sure I will eventually run into more issue, e.g. with modal overlays or my fixed positioned autocomplete results.

Searching through the Monaco CSS shows z-indexes ranging from 1 to 10000 with no apparent logic (e.g. 5, 10, 40, 41, 50, 100, 2500, 10000).

In the app I'm currently working on I have cleanly structured z-index like this:

:root {
  --z-index-grid-header-footer: 1;
  --z-index-main-menu: 2;
  --z-index-spinner-overlay: 3;
  --z-index-resize-handle: 4;
  --z-index-suggestions: 5;
  --z-index-dialog: 6;
  --z-index-help: 7;
  --z-index-toasts: 8;
}

Now I could go ahead and change them from 10001 to 10008 to make sure they are always on top of Monaco (that's exactly the benefit of having them in a central place). But what if tomorrow Monaco adds an element with a z-index of 20000? Or why not 999999?

Any thoughts on how to make embedding Monaco more predictable? I assume the current state has grown historically and is depth from VS Code. This has caused problems in the past https://github.com/microsoft/monaco-editor/issues/2203

Contributor guide