I have frequently met this problem earlier, but now I have another good example. When I need to build a form with interactive components, some layers are above the others and my dropdowns can’t open normally. Layers hierarchy is a very logical thing, but very restrictive, especially in auto layout.
yeah auto layout layer order is such a pain! I made a table without autolayout recently and I wanted to allow scrolling, but it causes the rows to overlay the table header when you try to scroll.
I ended. up wrapping all the rows in an auto layout container, and then surrounding the header, footer and this row container in a regular frame. If you need the equivalent of fill container you can just use left+right or top+bottom constraints. So I think you just need to go without auto layout in certain cases, where it makes sense but isn’t essential.
2 Likes
+1
1 Like
Definitely a need, it is the same with tooltips. Having a z-index for those elements would be best.
9 Likes
Here’s a hacky way to reverse the “z-index” ordering of Auto Layout layers:
Not the ideal solution and if you follow the Twitter thread linked from the file above, you can see that there is no easy answer. Figma mentions that a “layer ordering preference” could be a solution.
4 Likes
We really need z-index to be separate from layer order. I find myself detaching layouts frequently for these types of use cases and they’ll be even more common now that component hierarchy is removed from the context of the prototype.
8 Likes
This is why we don’t use overlays in auto-layout frames. We know double 180 hacks, but this causes a lot more problems. Like swapping components with hack and without a hack. Autolayout order in practice and in everyday work makes no sense for us.
2 Likes
May not be ideal, but couldn’t you solve this by manually positioning a prototype “overlay” component?
Issue is that overlays aren’t supported so won’t show if you use the component on another page, or via a library. So you have to redo it every time you want a dropdown and lose all the benefits of interactive components
1 Like
will it work?
I think separating z-index and layer order will not fully cover the issue. The way I see it, the issue here is that an element is expanding and the expanded area is visible below another element.
explained
If you have a set of drop-downs arranged vertically, this is fine. Giving the ‘highest’ element on the Y-axis the highest Z-value will give expected results. Instead of drop-downs, consider a thumbnail gallery. There are 4 square images as in image below. Interacting with images scale them. If the images are given Z-index from left to right - top to bottom, only the top left would work as expected. Top right would scale up and be visible under top right. The bottom images would have both top images over them.
So in this case it wouldn’t be enough to be able to control the z-index, the ordering must also change with the interactions.
suggestion
A (hacky?) solution might be that the last layer interacted with would always appear as the top-most layer. Once another layer is interacted with the previous layer re-positions itself back to its original z-index. This way, a drop-down or scaled image will always appear on top when you click it.
…I’m sure this has issues if there should be interaction with several components simultaneously. But it should work for the use case of a form, where typically you only interact with one field at a time.
Could this be done with three layers:
- bottom layer are the thumbnails
- middle layer are the same thumbnails, not visible, that will be animated
- top layer are thumbnail-size hotspots that trigger a middle thumbnail to show and animate
1 Like
The main issue, as I see it, is with interactive components. Think of a tooltip variant that is triggered when hovering. If the component is inside an autolayout frame and the tooltip overflows the space of the component’s space, then it will be trunkated by the second frame in the layout.
…That is neither the concern of OP nor how it works in current version. You can display a tooltip or a drop-down that exceeds the bounds of its parent frame. Dimensions of layer items will not be altered by interactive components inside auto-layout frames in preview. To intentionally have content grow or expand from interactive components in preview is a highly requested feature, but is not yet released.
You can watch this video to learn how auto-layout and interactive components works in current beta version.
Also need some sort of z-index in Figma. My auto-layout components appear visually at the top where they should, but they are at the bottom in the layer list. Very annoying for interactive components like Dropdowns or stuff like that.
1 Like
Considering how many interactive components work like these drop-down menus, I honestly don’t see how they can release this feature until this is resolved. Interactive components are amazing and they’re just one more reason I’m sticking with Figma; however, with how they operate currently they just aren’t ready for release.
They almost need some kind of override system built into the interactive component variants itself where you can label a particular variant as an overlay “or something similar” that would bring it to the front so that it lays on top regardless of its position. I understand that this isn’t a “quick fix”, but I don’t feel it would be wise to release this feature until this is addressed.
1 Like