Z-index property that is independent from Auto Layout

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

1 Like

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

1 Like

+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.


Снимок экрана 2022-12-05 в 00.46.17
Yep, Z index is vital in case of using auto layout drop-downs


Would love this, as well

1 Like

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.


This problem needs to be solved by Figma, if they don’t want to go the Z-index route then an possible solution could just be to toggle a “Always on top” setting within the prototyping feature.

1 Like

Quoting Billie Joe:

Are we we are, Are we we are the waiting…

without adjustable Z-index, drop downs as table row actions in auto-layout is pretty much not attainable or at least very inconvenient. Absolute positioning might help but will introduce all sort of other nightmares.

At the very least, the ability to reverse the z-index ordering would be helpful. That would probably be a workable solution for most situations, even if it required some hackish nonsense using multiple auto-layout layers.

Edit: I just discovered that the “canvas stacking” feature exists, which does allow you to reverse the order, so at least that option exists.

I have a lot of trouble showing floating elements like tooltips / dropdowns because of this. Dropdown menus are possible to “hack” with tricks like “last on top” in auto layout.
But tooltips that must appear above everything, especially in situations when they’re inside a container that must be clipped, for example, is a nightmare.

We need a Z index option, or at least an option to “display above everything”

Example of tooltip issues attached

This would be very useful! Having similar issues as above when you have droplists and menu components that show on click within a auto-layout table.

Figma, please release this feature. Basically, z-index should override the elements rendering in the layer order. So that a certain element within an interactive component can be seen above other elements even if that component is below other elements within the layers panel.

1 Like

I’m shocked that this hasn’t been resolved yet. :unamused:


This is needed so bad - major problem in building complex auto layout or even using basic position sticky on navigations ect… please fix!!


Need a fix for that too

I need possibilities to create a layout more flexible than this simple flexbox based one.

  • play on z-index independently to the layer order (eg: equal to css position:relative; z-index:2)
  • grid display
  • element margin (yes in addition to the gap of the layout system), with values numbers and “auto”

Plus one. This is really a showstopper for auto-layout in prototypes.


@Figma_Moderation Can this get escalated to the appropriate group. The lack of control on z position (z-index or equivalent) is very prohibitive. The current solutions regarding absolute positioning, stack order, and layer (or frame) order are hacks and work-arounds that don’t even solve the problem entirely. The simple fact is that when something is absolutely positioned, there are times when that thing needs by “on top of” everything else on the screen. Examples of this are everywhere but include dropdown menus, combobox menus, tool tips or other hover indicators, etc. These are common UI elements and, quite frankly, it’s easier to prototype these scenarios up in HTML and CSS than it is in Figma using work-arounds. Some guidance on a solutions would be greatly appreciated by everyone encountering these issues.