I made a similar proposal some time ago. Unfortunately not too many people seem to understand the value of Z-index of Z-stack 😒

@anon21722796 Could any of you please reply on this?

@figma Reply please?

Hey @Slava_Bronevitskiy thanks for sharing this feedback. It’s definitely something the team is aware of and thinking through.

Absolutely necessary feature:

Set z-index for item in auto layout.

So you can send item to backward or forward only visually.

We wana Z-indexing while Flexing and Flexing while Z-indexing!

This is a must. Thanks.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.

Especially when working with auto-layout, positioning elements become so hard because the z-index is tied to the layer order in a way that is impossible to change the z-index without breaking the whole layout (or opting-out of auto-layout completely).

This is a problem mainly with interactive components that have a “pop-up” or something that should appear on top of every other layer, the best example is tooltips!

My suggestion is to solve this as we would solve with CSS, creating a z-index controller that would be set to Auto as default, and if we want we can type any value to force the z-index:

I’ve heard from many people that they were facing positioning issues with auto-layout. What do you guys think about this?

plus one. Z index would be essential

Explicit Z-index property has its pros and cons. For a start, it is going to be a mess. Even more a mess if you are using libraries. It is just too easy to abuse. I know same problem exists in CSS, where you often spend hours trying to figure out why something is not in a place it is supposed to be. I would rather see some entirely different way to solve “pop-up” problem.

For example, ability to position overlay relative to interactive component that invokes it.

Here is my quick mockup:

What do you think?

I think this would help but won’t solve the problem.

For tooltips, for example, we wouldn’t be able to change the text for each tooltip without creating multiple frames outside our main frame. In this case, it would be best to have the button and the tooltip itself in the same component/frame and adjust the z-position manually.

I agree, this would also help for the workflow on my end.

In general having overlays is a problem when using auto layout. So I am always have to find a good combination of contraints with no autolayout and autolayout.

Especially when on hover the hovered element is bigger and maybe even overlapping with items on the left or right, setting the z-index would help a lot!

Currently I have to move these kind of hover-overlays out of the variants canvas to make it work via interaction “open overlay”. This adds again some confusion when it comes to a handoff (to Devs or other Designers). Because suddenly not all states can be found in the variant area.

I wrote a small plugin that can reverse the z-indexes in an auto-layout.

It makes use of a hack using flips and reordering that was mentioned in another thread so a native solution would definitely be preferred, but for the time being this should help when you really need it.

Cool, it does its job, quick and easy. 👍

Hey, @James_Mitchell could you maybe rename this to something more descriptive? Like, ‘Reverse Autolayout Z-index’, for instance?

I can’t quite wrap my head around the fact that plugin names are so much out of the blue sometimes. 🙂 Like, good luck finding some plugins after a few weeks of not using them, then recalling ‘Ah, there was this great plugin I need for that’ and then you stare at that list, completely lost… 😅

@Matt_at_HAUD I’ll have a think. I chose Easy Z because typing ‘ez’ as a quick action returns it as first result, whereas ‘Rev…’ matches too many other things.

If I can’t think of a suitable name I can anyway add a label to the command to make it more searchable / clear.

An absolute position has been implemented recently.

Just ran into this problem. +1 for a z-index property (though I can’t imagine the potential mess/complexity this’ll introduce)

Aaaaand today again I have an issue that would really profit from a change to this behaviour 😦

Are there any updates on this topic? I also came across this problem.

+1 to this. would love to have an option of layer ordering and auto layout behavior being agnostic from one another (but maybe still self contained within its own component? a literal z-index as it behaves in css might be really really messy). advanced layout > canvas stacking can be handy in specific cases, but for example, if i have a dropdown subcomponent component that can either open upwards, or downwards, or both downwards and upwards at the same time, i cannot apply auto layout to a parent component without either the label above the dropdown or the text below the dropdown appearing in front of the actual dropdown subcomponent, but using absolute positioning for the subcomponent is also problematic, as the parent component will no longer react to different sizing options of my subcomponent.

Yep, Z index is vital in case of using auto layout drop-downs

Would love this, as well

I came here looking for ways to make tooltips work inside of an auto-layout frame.

My use case is a tooltip on an element inside of a table. I’ve created the table from nesting auto-layout frames to simulate rows which contain cells. We can now use auto-layout to give the tooltip absolute positioning so it points at the cell; the problem is that the adjacent cells and rows cover up the tooltip.

Having this exact issue right now and its been a struggle. I’m trying to reduce the number of frames I need to chain together a prototype where I have a table that has a button + popover in each row. The first row’s button popover looks great…every row thereafter is broken:

I’ve tried everything I can think of to have z-ordering work as expected and have applied hacks at every place available–the popover component, the button + popover component, within the table…no dice.

I had expected absolute positioning’s z-ordering to work more like in CSS and was surprised when there didn’t seem to be a way to specify the index for an absolute positioned element/component.