Hello, I am experimenting with themes and I am facing a slightly annoying issue with docked views.
When having two docks in the shared page settings, e.g. a top one and a left one, with priority set for the top one (top-bottom in the perspective properties).
It works well, except that the z-index of the docked views seems to change slightly when the left one is open, pushing it over the top one until the top dock is clicked, which once again brings it at an higher z-index. The result is that theme added effects, like a box-shadow, gets clipped until the z-index is restored.
This video shows exactly this behaviour in action, with the z-index changing from 11000 to 11010 and back again, and the shadow of the top dock getting clipped.
Since this is an in-line style of an element not accessible in the designer, I suppose it is done somehow behind the curtain. It’s not a “problem” in itself, but I would like to know if it is an issue anybody else faced and if there are workarounds.
Thank you.
What you’re running into is the application of focus to the View you are clicking; as you click each Docked View, you give it focus, resulting in its z-index changing from 11000 (un-focused/blurred) to 11010 (focused). Since the left Docked View in your scenario is receiving focus, it receives a higher z-index than the top dock, and so any styling of the top dock is ALSO at a comparatively lower z-index.
Unfortunately, since we have to maintain control over the z-index for these pieces there’s not much you can directly do to avoid this.
One workaround is to “mask” the overlap by placing an inset box-shadow onto the view which is covering the box-shadow of the top dock. Try placing the following box-shadow style into the root container of the left Docked View: 0 5px 5px -5px #000000 inset. You’ll need to adjust this setting to match the setting you applied to the top Docked View, but if done correctly the left dock will have an inset box-shadow which matches that of the Docked View and so will cover the box-shadow with an equal-yet-inverse box-shadow of its own.
Hello,
thank you for the swift reply, and thank you for confirming this is an expected behaviour.
Your suggestion was one of the things I tried first, sadly when overlapping two shadows the result is less than optimal, and it results in unwanted “dark areas”.
No big deal, I just wanted to be sure I wasn’t missing something. Since the behaviour is expected, I will try to adjust accordingly. I hope the post will be useful for others facing the same issue.
Cheers.
Just as a note, I believe this was the experience in the earliest versions of Perspective, and to prevent it we removed our own application of box-shadow to Docked Views.
1 Like
