My page contains three collapsible groups, each of different height (due to amount of content inside) but all higher than the viewport. Only one group is visible at a time (and I reiterate - others are collapsed).
It is my understanding, that the page height must adjust to the currently visible group height. Instead, the page is always taking the height of the tallest group. (I verified it grouping it together and giving groups BG colour - the parent group height is equal to the tallest inside group height.)
In my world, this is wrong. Anyone has a solution? Workarounds are also welcome.
P.S. Just want to add that this becomes really important in mobile apps, where one group can be really tall, and another - the viewport size. The page will remain as tall as the tall group. Looks like a bug of the app.
Hi @sudsy. Well, I mentioned in my second sentence and reiterated in the third - the groups are collapsible. But it was still easy to miss and Bubble is way more screwed than that The solution from @patricia has worked.
If you are looking to experience some strange things and then witness a miracle - may I suggest that you reproduce first my issue, and then Patricia’s fix. It’s an enlightenment
Ahhh, I glossed over the word “parent”. Didn’t realize the 3 groups were nested within another. Will try again to reproduce, as I’d like to understand the issue.
No, they are not nested. Try to create three groups of different height. Make one of them at least twice as tall as the shortest one. Your overall page height will be automatically adjusted to the tallest group height. Now, hide the tallest group and show the shortest. Your page height will remain as tall as the tallest (now hidden) group.
The fix is - to add a group within all shorter groups, that makes the difference between their height and the heights of the tallest group. This will eventually make all groups on the first level same height. But when you start hiding them, the page height will start adjusting to the current visible group height (minus the vertical holder group height).
I think I might have made a mistake by putting the three groups next to each other (for explanation’s clarity), In my case, the groups overlap. Wanna try that? If it’ doesn’t behave as I described, I will be happy to break it for you
Ohhh, I see. Yeah, that’s a whole different can of worms. I try to avoid overlapping groups.
Thus far, I’ve been able to achieve my desired layout and responsive behavior without overlapping issues.
I’m sure I could simply “break it”, but I’d prefer to understand why the overlap is needed.
EDIT: Ok, I think I finally fully understand. Thanks for taking the time to fill in the gaps. Indeed, I see why the overlap is needed and why @patricia’s solution is needed. This is indeed a common need for SPA-like applications. It’d be nice if the hack wasn’t needed but at least there’s a work-around.
@ryparken, I’ve taken a closer look at this, and it seems that if the groups are stacked instead of overlapped, the issue is avoided entirely. Here’s an example (with edit mode link).
Stacking (arranging in “Y space” instead of “Z space”) seems like a much cleaner approach, as it eliminates clutter and complexity - i.e. no need for “bandaid” elements. I’ve seen other posts discussing the merits of stacking versus overlapping, but that was mostly pertaining to ease of editing. It seems potential layout issues might be a compelling reason to opt for stacking instead of overlapping as well.
I’d be curious to know if it works in your situation.
I am aware of stacking and use it in my app too. Stacking does indeed solve the problem (except some cases with RG groups). However, it is mostly useful within groups of total height equal to the viewport (600-900 pixels).
In my case, I have a single page app which contains 4 large groups (equivalents of pages) that take the entire page width. Each of these groups is approximately 600 pixels tall with one being 900 pixels tall. If I stack them, I would get myself 3000 pixels tall page, which would very inconvenient to work with. Also, I sometimes have to extend my pages vertically. If it’s one of the top three groups, I would also have to move the other groups down.
So far, overlapping groups that resemble pages work well. Also, I mentioned I had problems with stacking groups with one of the groups containing a repeating group. For some reason the repeating group was adding extras spaces BENEATH itself equal to the height of the row. So if I had 10 rows 30 pixels height, I would have extra 300 pixels white space below the group. Totally bizarre.
Up until today, I preferred overlapping as well, but being aware of this issue (which I hadn’t previously encountered), I think I’m changing my approach. I’m something of a minimalist, so I prefer simpler when/where possible.
I understand your preference for navigating the editor, but I’ve found that when navigating via the elements tree or the element search box, Bubble instantly jumps to the clicked item - even if the page is tens of thousands of pixels tall - so scrolling’s a complete non-issue. I much prefer simplicity and fewer potential layout issues.
The solution from 
But no worries and thanks for helping any way!
Done
