it can change the width too
I tested it out but I couldn’t figure out how to ONLY change the height dynamically without the width being effected
maybe you should uncheck the option to keep the proportions?
I did, but the “Width” is a Requiered field and it only takes a % not a static px value. What I want to achieve is the groups height to be always 100% but the width to be a static 75px
Hey Shawn, we are working on an update for this plugin to allow what you want to achieve. I’ll update here once it’s done.
We have just updated the plugin so that it allows independent change of width and height. Please install the latest version, refresh the browser and try again
Seems like something pretty standard that Bubble should be implementing themselves… @emmanuel ??
@raf970 This question/comment has been raised many times over the last couple of years, but the Bubble team doesn’t think it’s necessary. They have given us the “Floating Group” element, but using it comes with its own set of challenges.
I too would LOVE the ability to specify height and width percentages on the Group elements. The height would need to be relative to the parent container/group though (like divs within divs).
When you increase the height, it overlaps the group below it. How do you avoid this or push the group below it down?
I feel like there should be some voting area in Bubble for ideas to implement by the team…
This would really change the game for Bubble applications
Thanks for providing the editor in your post…that has made things so much easier to learn.
I have been able to successfully put this together. I am wanting to use it for a lot of responsive settings on my apps. I do have one issue though, and it only happens when a user is resizing the browser window on a desktop.
What happens is, elements that are getting shrunk on changing the view port dimensions are staying in the smaller form. For example, the page in your app that shows a yellow group transform and translate Y coordinate to be underneath the white group at the top of the page. The yellow box after stays a smaller size.
Specifically, if I load the page on a full screen browser window everything works fine on page load, then when I shrink the browser window the groups are the height of the view port as they should be. The problem occurs when the browser window is expanded to full size again; at this point the white group goes back to being the full height of the view port, but the yellow group does not. It stays the same height as the smaller view port.
I believe this may be because the other element on the page (the white group) is somehow blocking it. I have experienced similar issues with other set ups where a group is to the right of another.
I am curious if you had any issue with this and what it is you had done to fix that issue.
Right now, my only thought is to run the workflows when the page width is different from previous and somehow try to capture the value at certain points for the calculation.
Hope you may have a quick fix.
I just put together a workflow
In theory it works, because when it is recognized that the page width is less than or that it is greater than the state_page_width it does what it is supposed to. The problem is that it doesn’t always recognize the page dimensions have changed.
I moved away from that design entirely, so I’m afraid I don’t have a quick fix to propose for your issue.
Sorry I can’t really be more useful
@Lucien thanks for the response.
Also, was the new design you went to allowing you to set the heights of elements dynamically according to the current view port height? If so, do you mind sharing an editor view to see how you accomplished it.
I’ve been playing around with CSS tools and found they have a current page height so just adding CSS tools to the page allows you to grab that dynamic data.
Yes, I would tend to agree, but mostly, it made everything harder to maintain and modify. The value for users was not in that particular arrangement, so I eventually used a regular scrollable page setup.