z-index support

which means we will also get css features like shadow, glow, blur etc?

You can have an idea of what we are working on in the roadmap, and vote on what you think we should work on and if it is not in there you can event submit it.
https://unity.com/roadmap/unity-platform/ui

I must say it is not currently 100% up to date as some things that are listed in “under consideration” are easier to land (and needed) for full z-index support so we may have already been working on them.

At this point, it is safe to assume z-index won’t land in unity 6 as the feature cutoff has been crossed a long time ago.

1 Like

Thanks for the update, I’ll b happy if it arrives in Unity 7 next year and not Unity 8 :wink:

Please do enlighten me then.

1 Like

Joining the bandwagon for z-index ! Nothing more to add, I’m just facing a case where z-index would be the best solution here.

1 Like

New year - new request for z-index.

Hey Unity, how about completely different tree doing the display order? Because there is no need for flex hierarchy to dictate its order for something that has nothing to do with flex.

Also how linear custom sorting is impossible to implement for years?

Other thing is 2D environment where you cant directly control the display order is a sad dream of a madman and if you told anyone to make games in such creation he would gently tell you to pound sand

Otherwise your doing a great job with toolkit!

Z-index is definitely one of the most requested feature for UI Toolkit. We’re constantly revisiting how it fits with the current model. There are always weird interactions between z-index and other features, such as masking, which would negatively impact performances if implemented “to the spec”.

Not exactly sure I understand the suggestion. You can always append an extra child to your root element that will display everything “on top”. UI Toolkit will always render the elements in a depth-first fashion, so that the last sibling is guaranteed to be rendered after the others.

I’m not sure what is meant by “linear custom sorting”. You can sort the elements under a given parent with VisualElement.Sort(), but I assume you’re referring to something else.

1 Like

Hey! Thanks for the reply.
The problem is there is currently one hierarchy tree that manages both placement areas of elements and display order and 98% of time its a simplest and fastest solution to build stuff quickly but once you try to add any more complex decorations or dynamic behaviours it forces some hacky solutions to keep display order in check and then forces code to manage state of those solutions.

Which could be completely avoided if i could just flip-flop the display order.

“linear custom sorting” is just an term for display order (being like a list or one thing after the other)

I have not much of an idea about internals of the ui toolkit but current solution just moves the complexity somewhere else instead of solving it in the place where it occurs. I dont know maybe its a correct trade-off but for sure an annoying one.

Conceptually place where you render things and in which order you do it shouldnt have anything to do with each other.

Metaphorically you could defeat the big monster so the users dont have to fight with its smaller ugly heads that its popping all over the place further along the line.

The only case i see for not making it is if it would really be impossible to weave it into other features but still then you could introduce api to controll it at the price of such features.

Also why not make just another tree fused into the uxml, to rule the display order? Maybe make it activatable as a module from some boolean but still, one tree for placement, one for the display order? Some way to make it manageable

Thanks for your comments!

Regarding this:

UI Toolkit already has a separate tree-like structure that dictates the low-level render command order. This isn’t exposed, but it will internally be used for z-index.

The tricky part is determining which style should generate a new stacking context, and which should not. The web standard has some behavior that conflicts with a high-performance system:
a) A transform generates a stacking context, and we don’t necessarily want that
b) The overflow:hidden style doesn’t generate a stacking context, so even though an element with z-index isn’t rendered at the same time as the “physical” tree, it may be affected by the clipping/masking of its physical parent. We may want to diverge from that behavior as well.

Exposing the render tree itself isn’t something we have considered. It is quite low-level and wouldn’t translate well for a public API. So, we will have to provide alternate ways to control the render order, such as z-index.

cursed edge cases as always :smiley:

so for now “ghost pseudo z-index bump” is the way

where we erase visuals from element but leave the layout, and then create its ghost visual high enough above in the tree that it renders above the desired element.

anyway i wish you pleasant wrestle with code and good luck at solving anything it is your working on :stuck_out_tongue:

2 Likes

Edge cases, they’re everywhere. I know it’s been a long time without much z-index movement. We’re currently focused on bigger parity features to officially match what uGUI can do (ie. World Space, Custom Shaders, and Animation) - while also maintaining what we already shipped and fixing bugs. This does not mean we have forgotten about z-index (or the problem it’s trying to solve). We will address it.

7 Likes