BUGFIX: Prevent hideDrawer call on hovering menu

[markusguenther]

Since 8.2 the drawer closes while hovering the menu items. We had some issues with the focus shift over all layers.
Because more or less everything was with z-index 1 in that case.

What I did
The drawer has now a higher z-index. The already existing constants have no more space between. But did not touch the most context bounded constants.

The text of the button now also fills the whole existing space.

How to verify it

Open the drawer menu and hover slowly over the menu items, especially where no test is.

Fixes: #3286

[mhsdesign]

Do you know how this bug was introduced?

And i dont like that the ui constants now differ from their original origin in Neos.Neos https://github.com/neos/neos-development-collection/blob/3d2ddf4a8191aafe8ac536092c9fb64bd8d6a45c/Neos.Neos/Resources/Private/Styles/_CSSVariables.scss#L57

[Sebobo]

And i dont like that the ui constants now differ from their original origin in Neos.Neos https://github.com/neos/neos-development-collection/blob/3d2ddf4a8191aafe8ac536092c9fb64bd8d6a45c/Neos.Neos/Resources/Private/Styles/_CSSVariables.scss#L57

They need to be removed in 9.0 from Neos.Neos IMO.

[Sebobo]

I would like to have a proper system for the z-indices. But as those are currently internal variables, I think we don't have to worry about changing them again at some point?

[mhsdesign]

The variables are exposed via react-ui-components postcss.rc, but fine with me - no one should use these vars besides us :P
So lets review this based on if its working or not ^^

We still have no clue about this no?

Do you know how this bug was introduced?

Im just curious because the fix is a bit magic to me

[crydotsnake]

Tested it, and from the functionality its working.

[crydotsnake]

Do you know how this bug was introduced?

The commit history should give some answers maybe 🤔

It COULD also be that you tried to fix another problem at a different location, and that's how this error came about 🤷🏽.

[Sebobo]

Most CSS problems came from the different behaviour how the old build system composed extended styles. Markus knows the details as he fixed a few of them already.

[markusguenther]

I guess it is complicated to find the real root cause in this case. Guess it is a combination of some changes.
What Sebastian means is that we used composes in the past and that the current way of include for instance the resets styles and then override some of them by use case behave not always the same.

Because in composes, we create a subset of styles and don't overwrite.
The C from CSS is sometimes biting us. But the cascade is also the powerful part of CSS.

[markusguenther]

I would like to have a proper system for the z-indices. But as those are currently internal variables, I think we don't have to worry about changing them again at some point?

That would be awesome. Not so many elements that all use z index 1, and then you have the issues when you need to fix something or extend something.

[mhsdesign]

a i see f22441d was a regression too ;) im just trying to keep track of the things that broke, so in the case we go back to composes we would know what to adjust... but it doesnt seem like a good idea to ever do that? 😅

[markusguenther]

Do you know how this bug was introduced?

And i dont like that the ui constants now differ from their original origin in Neos.Neos https://github.com/neos/neos-development-collection/blob/3d2ddf4a8191aafe8ac536092c9fb64bd8d6a45c/Neos.Neos/Resources/Private/Styles/_CSSVariables.scss#L57

Can open a PR and can adopt them there as well... to be in sync

[markusguenther]

@mhsdesign synced the z-index values neos/neos-development-collection#3975