Make the z-index management open for the developers

[oleq]

ATM we use a ck-z mixin to configure the z-index in the project. The problem is that developers may find them wrong, e.g. because they collide with other web page elements like modals, overlays, etc. but there's no easy way to change them.

Solution 1

Use the power of SASS !default and do something similar to what we did with colors.

Pros:

• Developers can easily change the z-index map to their preferred values.

Cons:

• Devs need to (re–)compile editor and the styles to do this, which requires the entire dev env.
• There's no way to change the values with vanilla CSS.
  • The values are dispersed across the code base. E.g. ck-z( 'modal' ) can be used in many places in the code, and devs who will fight it will need to override dozens of unrelated selectors to get their correct value right.
• For the same reason, there's no way to control it with JS.

Solution 2

Switch to class-driven z-index management. The SASS helper will generate a set of classes like .ck-z_default, .ck-z_modal, with pre-defined values, which then will be used in the templates to assign the desired index.

Pros:

• It's enough to .ck-z_modal { z-index: my value } in the custom styles sheet to override the z-index for the entire project.
  • It's easy to control such styles with JS, if there's such a need.
• Solution 1 still works. If developers decide they don't want to play with custom styles but re-compile the editor (which is a dependency in Webpack), they can override the default map containing z-index values so that generated classes (.ck-z_default, .ck-z_modal, ... ) represent the right values.
• It's still possible to create styles silently via .foo { @extend .ck-z_modal }, like .foo { z-index: ck-z( 'modal' ) }

Cons:

• We need to extend a couple of templates in the JS code, to make them use .ck-z_* classes.

[Reinmar]

Related ticket: https://github.com/ckeditor/ckeditor5-upload/issues/33.

[Reinmar]

Related ticket: https://github.com/ckeditor/ckeditor5-ui/issues/319

[otherblandart]

Any plans to move forward with this? In our implementation we render editors inside containers and give them a max height, but this makes balloon toolbars and certain dropdown menus float above other, outer content when editor content is taller than max-height.

FYI, this can also be seen in the Document Editor demo:

[oleq]

@otherblandart What you described is a different issue not related to z-indexes. Give it a thumbs up if you want to see it fixed. Thanks!