Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[FEAT] Fixed Footer – content fixed to the bottom of the screen #240

Open
Toeler opened this issue Jun 22, 2024 · 9 comments
Open

[FEAT] Fixed Footer – content fixed to the bottom of the screen #240

Toeler opened this issue Jun 22, 2024 · 9 comments
Assignees

Comments

@Toeler
Copy link

Toeler commented Jun 22, 2024

What are you trying to add to Cupertino-Pane?
It would be good if there was a way to add content within a pane that was fixed at the bottom of the screen, no matter the position of the pane breakpoint.

Describe your feature request detailed
My use case is a Reply button/text input that needs to sit at the bottom of the screen when the pane is opened. If the user moves the pane from medium to top then the button/input should remain at the bottom.

I attempted this with the offsetBottom parameter and having the button/input be separate to the pane, which works when the pane is at the top, but when it is scrolled down it is rendered over the top.
I also tried to use fixed positioning on the button/input when within the pane, but the issue is that the fixed positioning on the pane, combined with the transform, means that any children with fixed positioning are relative to the pane, and not the viewport (https://developer.mozilla.org/en-US/docs/Web/CSS/position#fixed_positioning).

Is there an alternative at the latest version?

[ ] Yes (descripe the alternative)
[x] No

Is this related to an issue?

[ ] Yes (Give a link to the issue)
[x] No

@roman-rr roman-rr self-assigned this Jun 22, 2024
@roman-rr
Copy link
Collaborator

roman-rr commented Jun 22, 2024

Thank you @Toeler
I agree, there is a demand for a fixed bottom bar feature. It will be included later. For now, you might try using the topperOverflowOffset ((docs)) to reduce the scroll area viewport to the height of the button. If that doesn't make sense, please create a demo on JSFiddle or a similar platform, and I would be happy to help you.

@Toeler
Copy link
Author

Toeler commented Jun 23, 2024

Hi @roman-rr. Here is a jsfiddle with an example: https://jsfiddle.net/sptjaobe/1/

It looks like your suggestion of topperOverflowOffset does help when the pane is at the top breakpoint. But my requirement is that the button is also fixed to the bottom of the screen when the pane is in the middle breakpoint.

I can see how it might be possible using some of the hacks from the Overflow Top-Middle example. But the requirement to show the button at the bottom of the screen even during the drag wouldn't work with that solution. (Also that hack resets the scroll position, which isn't desirable).

@roman-rr
Copy link
Collaborator

roman-rr commented Jun 23, 2024

Please confirm such scenario @Toeler

  1. Bottom breakpoint: comments not visible. Button not visible.
  2. Middle breakpoint: comments visible, but not scrollable. Button not visible.
  3. Top breakpoint: comments visible, scrollable, button visible and always fixed on the bottom.

This is correct? Or button visible and fixed on middle point to?

@Toeler
Copy link
Author

Toeler commented Jun 23, 2024

@roman-rr My goal is to have the button visible and fixed on the middle breakpoint. And in addition to that, when dragging from middle to top, the button is still fixed to the bottom of the screen.

@roman-rr
Copy link
Collaborator

@Toeler Please check this revision and give me some feedback https://jsfiddle.net/romantonoff/0kz8efsL/

@Toeler
Copy link
Author

Toeler commented Jun 24, 2024

@roman-rr Yes, that is the behaviour I am after. But my preference is that the component that defines the content of the pane also defines and controls the button. With your proposed workaround, I would need the hoist the reply button to the component that shows/hides the sheet and then add logic in there to also show/hide the button.

@roman-rr
Copy link
Collaborator

roman-rr commented Jun 25, 2024

@Toeler Would you like to define bottom bar like so ?

<ion-drawer>
    // some content

    <div class="bottom-toolbar" footer>
      <button class="btn-reply">
          Reply
      </button>
    </div>
</ion-drawer>

When we just set attribute footer and than it will be converted to fixed footer. Is that correct? Or you have other ideas?
Also, how about opacity transition? Is that smooth enough?

@Toeler
Copy link
Author

Toeler commented Jun 25, 2024

@roman-rr If that fits the style of the library then yes I do like that approach the most.
Another alternative could be to pass the class in at a JS level as a property.

As for the transition, that depends on the goals of the library. Yes, I need it visible at Mid and Top but not Bottom, but perhaps somebody else would want it visible at Bottom too.
As a default, I think the opacity transition is great. An option to configure it could be beneficial for those that want to change it.

If you would like, I could work on a PR if you know what the library would like to offer.

@roman-rr
Copy link
Collaborator

@Toeler Welcome to make a PR. You might try to make as you like it, and I will complete it afterwards before merge.

@roman-rr roman-rr changed the title [FEAT] Content fixed to the bottom of the screen on top of the pane [FEAT] Fixed Footer – content fixed to the bottom of the screen Jul 3, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants