Aaaaand today again I have an issue that would really profit from a change to this behaviour 
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.
2 Likes
Yep, Z index is vital in case of using auto layout drop-downs
2 Likes
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.
3 Likes
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.
3 Likes
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.
I’m shocked that this hasn’t been resolved yet. 