I just wanted to share a lot of help I got from @gf_wolfer
In need of clarity on the subject of a side menu with scroll, I turned to the forum and found a thread @gf_wolfer had commented on, but it was closed. I reached out to him in a PM and he readily replied with assistance. I want to pass this along as it has made my life so much easier now.
At first, I tried some other methods that included using javascript and another using CSS. I’ve heard from some that there could potentially be issues and I had experienced them as you needed to set them twice in a workflow and needed timing to work in your favor.
The method that was shared involves no workflows, custom states or conditionals. It is a simple straightforward approach that works. At first, I had some issues with it as I had failed to notice that there was setting on the page.
In order for this to work, you must have your page set to “not fixed width”. I struggled for a while before getting this part figured out.
Set up Page - Set your page height ( 1800 for example ) and width ( 960 ). In reality the width and height don’t matter, however the height is important as we will set other elements on the page to the same height dimension.
Add a group element inside of the floating group element. Make sure to have the bottom of both elements touching. Easy way to do this is on a page with height of 1800 is to set a group inside the floating group with a height of 990 and a X , Y coordinate of 0 , 810
Would you recommend this technique to make the viewport height responsive for all groups acting as “pages” for a mobile app (and not just a sidebar)? That way the “page” is the height of the viewport, and you you can scroll down within the group… This is what I’m trying to achieve, but to no avail.
I designed my app well for phones, and then realized I didn’t adapt it to iPads.
Most workarounds seem to employ a JS workflow action that bring the bottom of the screen up to viewport height, except that seems to only work when the viewport height is smaller than the group “page”. If the viewport height is larger than the group “page”, things like this happen, and the footer appears higher than the viewport height.
Would your solution here work? The floating group would have to be made responsive as well, I thought I saw a thread somewhere that discussed responsive floating groups. .
I would appreciate your thoughts, and if you have any suggestions for dynamic mobile height responsiveness.
There is some stuff with CSS tools you can do to change the height and width of an element. I did some stuff with it in the past and abandoned the idea for several reasons.
Designing for a 100VH page seems tedious and overly complicated as all elements will need to be responsive to the height for it to look right, which I believe would add a lot of math to your design that is unnecessary.
I’ve read Bubble automatically overrides custom css at times. So you’d lose all the design features possibly.
Page height doesn’t seem to be an issue for an entire page to look proper on mobile. Overall I think it is page width that affects it looking like a mobile app.
Most elements are height dynamic when adjust widths. Think about a text paragraph with width of 500 and height of 200 that holds say 500 words. If you collapse the width to 250 what will happen with all the text? It expands downward ( ie: becomes taller in height )
Mobile phones on turned sideways so, a 760 wide screen with 360 height.
I could think of more reasons why I decided against it, but if there is some specific reason for a page to be 100VH across all devices and it isn’t for a complicated page or an entire app, then there are ways to achieve it with CSS or JS.
Check out this editor to see how you can use CSS tools to change height and width of a group.
You can also find ways to get the view port height and width from browser to adjust things, I forget, but go through the forum and you could find it.
For me, responsive design is so complicated I try to keep it as simple as possible. Seems KISS ( Keep It Simple Stupid ) is the “golden rule” for design as I see it on almost every design blog post etc.
Also keep in mind having groups that are hidden and have collapse height when hidden to help with height responsiveness…even for width adjustments in responsive design having groups that are hidden or invisible just for design purposes is helpful.
Thanks for this and your follow-up comments regarding 100vh height.
I’ve been struggling to create something similar to slack / discord… with floating group menus top, left, and right, and an input field on the bottom, surrounding a repeating group of posts in the middle… adjusting height across screens
I was curious if you still felt it’s hard to achieve this with Bubble or if something has changed in the two years since you wrote the above…
I have yet to find a solution and was taken aback when I say your statement saying in essence - rethink your design…
Not sure if I’m missing something, but to get a floating group menu to be scrollable, all you have to do is make the group as tall as the page, and set it to “float vertically relative to both”.
If the content becomes longer than the page height, the floating group will now scroll.
Be sure to checkout the Stripe Integration Course when you are ready to integrate Stripe payments to start monetizing your application via product sales or subscriptions.
I’m still struggling tho. It’s a simple navbar that slides I’m doing and it’s a headache
So I opted for a group 100vh and I use a floating group for the footer which is oustide the nav group because even with CSS I cannot make this group stick to the bottom of my viewport. but now that floating group doesn’t want to stay hidden when I close the navbar it shows up a second later. CSS -webkit-bottom not too sure if that is the problem.
