My personal use case: I use the Material Design guidelines and use surfaces or card-backgrounds to in my design. These components have states defined. When I change the corner radius, shadow, outline, or even the whole component itself, all elements that use that component as background should update accordingly.
If you could exclude a layer from an AutoLayout Frame that would already help. So it doesn’t do this:
Auto-Layout is nice, I enjoy not having to resize my background all the time. And it works good for simple buttons, but more complex objects or just having the option to swap out the instance of the background component or deciding one day that I want my top right corners to be cut off at a 45 degree angle are sadly not possible.
It’d be nice to discuss possible solutions to this problem. Do you have ideas how to solve this problem? Me and many others agreed that it would bring Auto Layout to the next level. Especially when it is advised to make components out of everything to keep things atomic.
Yes, that would be awesome, and not only that — just general absolute positioning of objects inside of auto layout would be perfect. Simply switch off auto layout for one element and enable regular constraints. It will have to respect constraints as if its parent frame was resized manually, but instead the frame will be resized as auto layout.
+1 Yes please! I’d like to have this option since day one of switching from Sketch. Autolayout is great but static objects within an AL frame would be awesome. I don’t see any problems with that, just take it out of the AL stack and apply its constraints.
This would be awesome. It seems like this would be a low cost implementation for such a huge win in layout. I agree in treating this as a Support Absolute Positioning in AutoLayout feature. I bet if this was the name of the post this would have a lot more votes right now. I know several people on our UX team have already brought this up internally.
Currently, is it impossible to use auto layout with background as a component.
For exemple: I need to create banners filled with a pattern. I created several patterns on my library as a components. So, I can’t select an asset on the Fill settings menu to use it as a background of my banner with auto-layout properties.
Im finding auto layout with the interactive components great but would what would really make this a Super Power would be to allow stacking of elements inside the auto layout on the z-index.
With the component interaction I can animate the tool tip on hover in and out of the info icon, but if I add that to an auto layout of like in the example the tooltip instead of hovering above all content in that stack would pushes everything down to make room. Yes, I could make two frames to achieve that but animating and placing at a Zindex above everthing in the auto layout would be better for maintaining interactions across a design system.
Describe the problem your experiencing and how your idea helps solve this
It would be very useful to have elements that can respond the legacy layout options within an element which has an auto-layout set up. Basically being ignored from the distribution.
Add as much context as possible (screenshots, Figma files, mockups, etc.)
I can imagine in the layout options of the element there could be a way to set it as floating.
Seems like something that is relatively common in design (e.g. popup x icon to close it or tooltip arrow) and it would be great to have it in Figma.
I voted for this, but actually you could have Frame 1 as a normal frame with Card at the bottom. Dynamic/Text content would sit above Card within an AutoLayout group that’s set to Centre and Scale. Although this isn’t ideal and more pain to set-up.
What I usually do is to leave the Card out and apply Corner radius, background colour, effects, etc. to the AutoLayout frame… which of course causes pain down the line.
Currently I put the Autolayout component in a new group, lock it using the padlock, and then place other shapes/icons on top of the locked layer. Not ideal but works
I feel this pain, right now it is impossible to create complex windows and dialogs that auto layout. But… I don’t like this solution. Having some elements to ignore auto layout will end up a huge mess, where it impossible to understand why one element is positioned the way it is.
The good solution will be to extend Auto Layout to Z-index, similar to what SwiftUI does with ZStack.
I’d love the ability to ignore the auto-layout of a element in an auto-layout group. That ignored element could then be absolutely positioned relative to its parent (the auto-layout group).
