I don’t know Figma’s reasoning, but to me it makes sense not to collapse empty autolayout frames because if they become size 0 then it would be tedious to put things inside them.
I agree, it makes sense, although the logic is hard to understand. The actual issue I have is related but not the same exactly: when this “empty” Frame is made into a component, it will keep its maximum size even with no displayed content.
It’s an issue when implementing component toggle properties in a component. Say your component has three possible zones: A, B and C, but B and C are wrapped in a Frame in the overall structure. You can’t create toggle properties for B and C without having their wrapper keep its maximum size (and thus the overall component not hugging only A, for instance). The only way to go is to add a fourth toggle property for the wrapper, not ideal.
I think I understand.
A possible workaround might be to put a 0 size frame between B and C. Or at least somewhere in the same frame as B and C, but assuming there’s paddings involved, putting it in-between IMO seems the easiest, but might not be viable if you have more than 2 children. Either way, after that you might have to make adjustments to make it look nice but it could work.
The problem is because a component with autolayout resets it’s size when all it’s children are hidden, but if you put a 0 size frame inside, which isn’t visible either way because it’s so small, it still counts because it’s not hidden, and the component will hug it.
I think am having the same issue:
I have a component with a horizontal Auto-Layout frame with 2 elements that have boolean properties. If I turn off both elements what I want to happen is for the container to collapse.
It makes sense why it doesn’t, technically, but when we were just using variants I could manually hide the container itself when I had a variant with both internal elements hidden. Now if I’m just using the boolean properties I can’t do that.
Yeah im getting this too, the auto layout frames should completely collapse, it makes boolean visibility probs useless in some cases where it should be used
Like to have it the way it is. Hunting zero size frame somewhere buried in layers would be a nightmare
Having this issue to when building a component. Placing a 0px shape does work but not ideal, would much rather have the whole autolayout object collapse to 0.
It also keeps it’s padding even when using the 0px hack which for me causes unnecessary padding/spacing. If the whole thing collapsed then the spacing would go away between the items and not have the extra padding.
I absolutely agree that the frame should collapse in that case.
I understand not wanting the container to collapse. However, logically it should - assuming we expect the design to behave as it would in code.
Additionally, it makes it tremendously difficult to effectively utilize auto-layout with many of the new component prop features - notably boolean show/hide.
I’m also having this issue, building components with boolean visibility. If there are two components in a “wrapper” auto layout frame, even if both children are hidden, the layout would not collapse. One workaround is to use another boolean just for the wrapper, but it’s just one more property to manage. The 0 height frame approach doesn’t work either, because the padding still doesn’t collapse as @Adam_Diestelkamp said.
This makes the new boolean property quite unusable in complex components.
Hello, so is this a bug or not ? If not is there a new “idea” created to promote this feature somewhere ? It’s very annoying, the only way for me is to create a property to collapsed the empty frame and it’s very dirty… 😦
My understanding is Figma is meant to support design for frontend languages. Since collapsing to zero is exactly how frontend languages work (css) then shouldn’t that be the expected behaviour. I don’t have a lot of sympathy with it being “annoying” or “tedious”.
This is indeed a bug we discovered recently. Turning off all the child elements inside a group set to “Hug” should collapse the size of that group to 0px but it doesn’t. @figma please fix this so we can still use our magic properties!
Also running into this issue. Will need to use variants instead of booleans 😦
There’s probably a good reason for not fixing this, but in the meantime it’s incredibly frustrating and means that I end up needing to hack in various ways (add another boolean to the container?) instead of just having this behave logically.
Madness 😦
This has to be a bug, it breaks slotting which is a super important design system technique
Struggling with the same. I would expect the group set to HUG, to have 0px if all it’s children are hidden. It makes it so painful to create components with boolean properties right now.
+1 - I would expect the parent contain with auto-layout applied to have a width or height of 0 if all children are hidden.
Yep this is making booleans frustrating.
CSS collapses to 0, so autolayout should as well. The 0px shape/frame workaround doesn’t work as it requires a 1px minimum height.
+1 agree, removing all content from an autolayout should collapse to zero, as it does in CSS.
I don’t know Figma’s reasoning, but to me it makes sense not to collapse empty autolayout frames because if they become size 0 then it would be tedious to put things inside them.
Why tedious if auto layouts collapse to zero? Easy from Layers tree.
also having an issue with this trying to build extensible, reusable components. Absolute PITA.
Still no fix for this?
It’s really annoying!
For example, if you want to have a side by side supporting text and char count in a text field, one aligned left, the other aligned right, they can both live in the same horizontal space.
But if I hide both of them, the space of the autolayout stays visible. It’s not always one or another, sometimes both need to be out from the component.
I don’t understand, this should have been fixed along with the release of Wrapping and Min/Max Widths at Config, more CSS properties. If the goal is to have more parity with how layouts are handled in code, this should be addressed as soon as possible.
Too painful to have to find a workaround and really detrimental to building robust and scalable design systems.
