z-index support

How can I control the order of elements from CSS?

VisualElement.BringToFront gets overwritten in certain circumstances, like when a new child is added.

 

As I understand it ... the main reason for z-index to exist is for the many cases where parents CANNOT be drawn before the children.

A year later ... z-index still not supported?

 

I don't know if this is a use case because I cannot switch to UIToolkit yet for this menu (as I need shader support), but I am certain it will.

When you click on one of the levels in this menu, the black background element will rotate on the Y axis, hide the level number, then flip back and grow until it covers the entire screen. I think if I had to put that element in front of the hierarchy, it will make everything else adjust around it (already had issue with another menu and reordering elements).

I would need to use z-index in this instance to make sure the black level background can cover all other UI.

 

That’s true. Thanks for pointing that out.

 

I'm very surprised that you haven't seen this. Maybe there's another way of hacking around it that works (if so, I'd love to know it - I couldn't google anything for it, I guess because z-index is so easy to use that no-one would need a hack?) It's happened on most non-trivial CSS layouts I've made, especially any that are responsive, that work on multiple screen resolutions, that have user-supplied content, etc. How big is your set of test cases?

In my experience of CSS this is a feature that is frequently used in two classes of situation:
1. Fixing edge-cases in UI
2. Doing innovative/exciting UI

Classic example of 2 is the "two images that both overlap each other" trick (e.g. an image inside a border, where parts of the image overlap the border and other parts underlap it).

Classic example of 1 is fine-grained control of overflow - e.g. text that you need to be inside one element but overflow a different element. Or underflow one element and overflow another. USUALLY: because margins / padding are insufficient to allow the text to show through - which is USUALLY because text is labelling something, and labels conceptually need to float above graphics. (*)

My immediate case:
Root rect has a label at top
Child rect has a background color
when root object padding is small / child margins are small: the text gets cut off by the child rect

In CSS, this kind of thing isn't common but happens sooner or later (at least once) on almost every project, but it's trivial to solve: you z-index it and then move on, so quickly you probably forget you even needed it .

(*) if z-index didn't exist, we would have to stop using flexbox for text in most of the UI's we wrote: all text would have to be manually positioned simply so that we could place the text in a separate layer above the graphics layer.

This is what I'm currently doing as a workaround. It so far requires almost 4x as much code to achieve in UIToolkit what would be needed if z-index were supported. It's essentially the same as writing an IMGUI example: we have to manually position everything.

 

As I understand there is still no way to set `z-index` yet.

The workaround proposed here, to change the hierarchy, is out of question if you are using flex layout. For example, you want your element to be in the middle when calculating layout, but visually be in front of other elements.

Use cases like this are countless. Overlays (tooltip, dropdown menu etc.), drag-drop, sticky header...

Even if you are using absolute positioning, you need to watch out for elements added after you changed the hierarchy, and manually put your element at the end of hierarchy again. I think the code loses declarative-ness like this.

 

For what it's worth: implementing this correctly in Unity outside of UIToolkit (i.e. implementing it in UnityUI) took me something like 20 minutes (won't work for UIToolkit - this was my own Flexbox re-implementation). But my point is: I don't think there's a technical reason why UIToolkit violates the specification here, it's not hard to do correctly.

(when the UIToolkit team made posts about: following the official specification isn't important because they (Unity) don't understand the purpose of those features and never use them themselves ... and they argue about my app design and say that it's *me* who's wrong for trying to use the features that are guarnteed, that are required, by the spec ... I lost interest)

 

If there is no way to make z-index work without sacrificing performance to the garbage rendering levels of UnityUI then it is better to make sure it comes with a warning you cant disable.

 

z-index, amongst other desired UI Toolkit updates, would increase my productivity for sure. I find it a bit off that it wasn't planned for from the beginning.

 

Thanks for the explanation. I understand that there are difficulties implementing performant UI and apparently the architectural basis was developed not considering the z-index feature. But I want to ping that this is a crucial feature.

UIToolkit seems to fix layouting of controls compared to the UGUI by using flexbox - that's great and it is a vast improvement. But the absence of the ability to sort controls on the screen the way you want is like a huge flaw in the design of UIToolkit. Like you are not even UI for mobile apps it is UI for games that presume UIs can be twisted and bent as hell.

You asked for the use case. I don't know this is such a basic feature I struggle to make a concrete use case...

Suppose you want to create FTUE (first-time user experience). You need to blacken all UI except for one button or other visual element and on top of it draw a finger and a tooltip.
In UGUI we were doing this with Canvas and override sorting.
What I would do (if z-index existed): added a transparent black overlay, change the z-index of a said button, add a finger and a tooltip on top of it. How would you do that without a z-index? The only way I could think of (which is hacky as hell) is: hide the button using

Code (CSharp):

1. visibility: hidden

, get the position of a button, clone the button, set absolute position, and set position same as hidden button. Z-index is such a straightforward thing and you need to have it.

 

Sounds great!

 

I'm surprised no one mentioned the most obvious use case: tabs!
Tabs have to ordered a certain way, but if they overlap, then we want the selected one to be rendered in front of the others, but we them to stay in the same position (changing the hierarchy would push them to the end of the layout).

See an example:

(The FORMS tab should remain the third, but be rendered in front of the OTHER tab)

I guess we can do some trickery with absolute positioning, a ghost element and some scripting, but having z-index available would make things way simpler...

 

Any news about z-index in USS?

 

At least give us the

order

layout property

 

I am currently working on a project that involves drawing items in a grid. Not having z-index means that items larger than one grid square get rendered behind other UI slots even if their positioning is set to absolute and overflow is set to shown on their parent VE's. In this example the rifle is two inventory slots wide and even though it is positioned correctly it is not drawn correctly because it is clipped by the next inventory slot. Overflow is set to shown so I don't believe clipped overflow is the problem.
Attached also is a screenshot of the UI toolkit debugger showing what size the displayed item should have.

 

Bumping for interest...

With the current implementation of element ordering (no z-axis), is the following the best way to get a pop-up window to appear above all other UI?

- place the UI element as a child of the UI root with absolute position

Let's say I wanted to implement custom drop-down windows, which show a drop-down window when the user clicks on a certain UI element. Would the best way to achieve this be to place the new window as a child of the UI root at an absolute position corresponding to the drop-down selection button?

If anybody has recommendations for implementing custom drop-down windows, or popup windows that appear nearby other UI elements, do share!

 

I guess it is, since UI toolkit developers followed the same approach with the Dropdown element (try it with the debugger, you'll see the dropdown popup appearing as last child of the root)

 

Interesting. In that case, how can I position a new element as a child of root with absolute positioning relative to some element deeper in the hierarchy?

For example, I was thinking of having an "OnFocus" event which places the popup window near/below the element focused (such as a button clicked):

Code (CSharp):

1.     private void OnDropdownFocus(FocusEvent evt)
2.     {
3.         VisualElement element = (VisualElement)evt.target;
4.         var target_position = element.LocalToWorld(element.transform.position);
5.  
6.         popupWindow.style.position = Position.Absolute;
7.         popupWindow.transform.position = popupWindow.WorldToLocal(target_position);
8.         popupWindow.style.display = DisplayStyle.Flex;
9.     }

This isn't working because I don't know which "position" property should be used and how it can be applied to the popup window. Anybody understand how to manipulate the position of UI elements via C# code? The API in the documentation isn't very clear in this regard.

EDIT: I've found that using the style.left / style.right / style.top / style.bottom achieves what I'm looking for:

Code (CSharp):

1.     private void OnDropdownFocus(FocusEvent evt)
2.     {
3.         VisualElement element = (VisualElement)evt.target;
4.         var target_position = element.LocalToWorld(element.transform.position);
5.  
6.  
7.         popupWindow.style.position = Position.Absolute;
8.         popupWindow.style.left = target_position.x;
9.         popupWindow.style.top = target_position.y - (popupWindow.layout.size.y / 2) + element.layout.size.y;
10.         popupWindow.style.display = DisplayStyle.Flex;
11.     }

This code results in the popup window appearing directly below the button pressed:

Before button press:


After button press:


This should be enough to implement a custom drop-down popup comprised of all sorts of custom elements.

 

I'm not sure I get your goal... why don't you use the default dropdown popup? It looks to me that your case can be implemented just with that

 

I initially tried using the default dropdown, but it is very difficult and restrictive to customize and add styles. Especially if I want to make the popup window contain multiple custom elements. Unless I'm missing something and this can be done with the default dropdown.

Also, with the custom dropdown I'm able to programmatically create and populate the dropdown popup via C#, so that the options that appear directly correspond to the actual data used in the game. This way I can add new items/options and the UI will update without needing to manually create a new UI element.

 

There were (are? In all fairnes: last time I checked was almost 6 months ago) fundamental bugs in the design of the UIToolkit dropdown/popup, which made/make it a very poor choice in general if you intend to customize/extend/use for a real game where you want to have custom UI. It works fine for cases where you're doing NOTHING interesting, but even basic nice UI elsewhere (using mouseevent listeners on OTHER VisualElements) causes some horrible interactions with the default dropdown). IIRC the first ones I logged 1.5 years ago and got the eventual response "yes, but ... it would be difficult for us to implement it better, so we're not going to".

(I agree with the UIToolkit team that popups x-platform is hard! (then again: that's what we pay Unity for, so ... not sure why 'it's difficult' was a reason not to do it better). I also agree that *if* you're going to start from a partial implementation of Flexbox, so you're unable to use some of the core features, then yeah - doing popups is going to be extra tough! I wouldn't want to have to do it myself if I could avoid it)

 

Hello,

I've noticed that the link indicated has disappeared (https://portal.productboard.com/xvo8kmgtx7tkv7desh8cyaj7/c/520-depth-ordering).
The whole 'UI Design' section has disappeared actually.

But when scrolling the latest USS documentation (https://docs.unity3d.com/2023.1/Documentation/Manual/UIE-USS-SupportedProperties.html), I could not find it.

Can I know if the feature is present elsewhere or if it will be present in the future ?

There is a lot of use-cases where this would be very useful.

Thank you in advance,

 

I was attempting to create a tabbed UI and assumed that z-index existed as this is CSS/Flex based UI. It looks like there is work in pipeline but I haven't seen any update in a while. I'll just bump this to see if there has been any follow up.
I figure I could hack a solution using something like:

Code (Boo):

1. //Hide
2. tabContent.style.display = DisplayStyle.None;
3. // show:
4. tabContent.style.display = DisplayStyle.Flex;

However it's a little janky compared to what I initially envisioned.

 

I do not know for what problem you had to use this solution, but I had found the same solution (I used both a mix of the display property and the visibility property) for a pop-up menu system and a select VisualElement.

But I clearly remember the popup of the Select (the options) to be displayed behind children of the same parent, even repositionning them in the hierarchy did not work, since it's size could be bigger of the parent element (it's height notably, since you could have a lot of options to choose between, but it's width as well, if the option's name is long), it would be shown behind the siblings of the parent.

So I had to pass a VisualElement as a parameter, one of the top most element of the hierarchy, so that it would be positionned absolutly at the correct position, on top of all other elements, without modifying the layout of the element.

But this made his use inside the UI Builder very complex, since I could not tell which parent I would need to use to insert the popup beforehand, and using a string parameter (to pass the ID of the container), and navigate the hierarchy of the parents to find this element did no seem very elegant.

I think, if the issue I had in this thread is a bug, and if Unity want to fix it, that a z-index could be useful here as well (if shared with the GL draw calls).

This is complexifying the code a lot, for something that could have been solved with a single USS line code.

I had this problem a while ago, and I had found this thread, and I had seen the roadmap, and I thought that it would have been implemented after a few months.

I had this kind of problems when making a similar library in Javascript, and the z-index turn-out to be the best solution.

 

Just started learning Unity a few days ago (been C# programming for years though). Was also very surprised to find no z-index support. Most tutorials online seem to rely on clicking and dragging stuff around and using the editor to change the hierarchy, etc, which is fine for some people, I just prefer to do everything in C# so I see how everything is set up just by looking at the code and not having to use the editor for much. So z-index would be super handy for that, and of course ALL the reasons mentioned in this wonderful thread.

I do not see Depth Ordering on that roadmap either. Is it no longer under consideration, or is it still a "someday after other priorities"? Like.... within a year? just curious. Thanks for your transparency and feedback!

 

Doing this the other way around ... I had an example today where having Flexbox's built-in 'order' feature made it take a few seconds to make the UI, compared to having to corrupt the layout with hacks to make it work without.

(note: since UIToolkit is missing BOTH the required features (either would have been enough to make this work, both would have been better) - z-index and flex-order - you cannot do this in UIToolkit. It works fine if you implement Flexbox correctly though)

Because UnityUI already is hardcoded to do z-index from Hierarchy order, all I needed was to override Unity's 'positioning / flow from hierarchy order' to be set on a per-element basis, and then use Unity Hierarchy to set the z-indexes. This won't work for all cases, but for some UIs its a lifesaver:

 

Old thread but I was just searching for z-index.
Damien said, well just change the hierarchy, and it makes sense. (to an extent - changing the hierarchy is not as trivial as applying a class with a z-index though, so just for the sake of accessibility I disagree)

But for anything in-built, like a progress bar, we can't just change the hierarchy. So having z-index for that would be nice.
Or should we not use built-in elements and rather copy them?

 

3 years later and this is still not in sight, it has been on the road map as "planned" since march 2021, is this crucial feature ever going to get support?

 

@Unity:

PLEASE IMPLEMENT Z-INDEX - NOW !!

 

z-index is also on my wish list

 

To celebrate the one year anniversary of the last Unity employee post in the thread, I would like if my gift could be a new Unity employee post in the thread.

Any news these past 12 months? Any hope for the feature seeing dev time? What are you guys up to instead?

Since UIToolkit is recommended by the docs now for "Multi-resolution menus and HUD in intensive UI projects" so I do think it's fair for us to hope this gets a bit of active attention and communication considering the hierarchy ordering doesn't meet the expectations a lot of HTML/XAML-style UI devs are going to have.

 

Although I would also like to have an update from Unity team about ETA here is their roadmap which states that it's a "planned" feature.

 

I use UIToolkit every day, but I don't believe UIToolkit is ready for those, except for toy examples. Major bugs keep appearing a little bit too often / recently still. I would aim for 6 months from now to play with it, and not to start development until 9-12 months from now if you're using in production.

I don't normally mention my own assets, but ... you can get Flexbox with both z-index and flex-order right now, working great at runtime with live-editing (no offline editing needed), inside UnityUI (see my sig for links). Doesn't use UIToolkit, so bypasses all the issues there.

 

Sounds great.

The case for me is when I have a list of items and a custom "item:hover" psuedostate enlarges the scale (e.g. from 1.0 to 1.1) then I want that item in front of its siblings. Doing that in USS is desirable.

Capturing that moment in C# instead and manually sorting (e.g. "VisualElement.BringToFront") is an undesirable workaround. Doing that in C# is undesirable.

 

This is really great news, thank you very much for picking this up!

I have made 2 drag&drop inventory systems so far with UI Toolkit and i can confirm there are moments when you need z-index. For example: Player clicks on a window that is currently behind another window. So the window that gained focus in the back, should jump to front.

 

Not only tabs, but also buttons or other elements which have interactions with user.
Here is an example, where arrow must be drawn on top of all other elements.

 

Here the most common example of using Z index in UI. All logos, labels decorative parts are set with Z index.
My dialog box is not a parent of header, they are on same level.

 

Well, if they are no the same level (children of the same parent) you can set direction to column-reverse