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

Overflow hidden on default slot prevents from setting correct height on element #25

Closed
oleh-selivanov opened this issue Apr 3, 2024 · 4 comments · Fixed by #28
Closed
Assignees
Labels
bug Something isn't working enhancement New feature or request

Comments

@oleh-selivanov
Copy link

Hi, I am trying to create Collapse which contains to parts:

  1. Div with non scrollable content
  2. Div with scrollable content, that should have height of 100% of expanded collapse

I have to set overflow: hidden to all items scrollable content is nested in, but setting overflow: hidden to top item inside collapse make it always 0px height. Maybe I missed something. Thanks in advance

<Collapse>
 <div class="flex flex-col h-full overflow-hidden">
  // This is non scrollable
  <div>...</div>

  // This is scrollable
  <div class="overflow-auto h-full flex flex-col">...</div>
 <div>
</Collapse>
@smastrom
Copy link
Owner

smastrom commented Apr 3, 2024

Hi @oleh-selivanov, I can definitely look into it but I would kindly need you to create a reproduction on Stackblitz.

@smastrom smastrom self-assigned this Apr 3, 2024
@oleh-selivanov
Copy link
Author

No problem, gonna share it today

@oleh-selivanov
Copy link
Author

@smastrom
Copy link
Owner

smastrom commented Apr 9, 2024

Hi @oleh-selivanov, sorry for getting back now but I've been a bit more busy than usual and thank you for providing the reproduction.

I played a bit with it and yeah, overflow: hidden on a direct child causes the scrollHeight property of the parent (Collapse) to always be equal to 0 even multiple frames after removing display: none from it. That's why the collapse is not expanding nor collapsing as its "expanded" height is expected to be 0.

While I'm still not sure why those DOM APIs acts like this when this occurs, I figured that since this is a very edge case caused by the content (and not by the package) and that it can easily be worked-around (by setting a specific height on the direct child and then overflow: hidden on the next child, for example), I won't implement any hacky solution in vue-collapsed itself that takes care of this. This won't be fair for all the people that uses this package daily and would also push a bit too far its scope.

However, what I can do and will do in the PR I'm merging is that everytime this occurs, vue-collapsed will force the expansion of the collapse container (without playing any transition) so that nobody will ever get stuck in a situation like yours and will actually be able to see the content, edit and test it.

Thank you again for raising the issue and I'll hope you'll keep enjoying this package! Cheers!

@smastrom smastrom linked a pull request Apr 9, 2024 that will close this issue
@smastrom smastrom added bug Something isn't working enhancement New feature or request labels Apr 9, 2024
smastrom added a commit that referenced this issue Apr 9, 2024
* force onExpanded/onCollapsed for edge cases, fix #25

* bump 1.3.3

* force onExpanded/onCollapsed for edge cases, fix #25, 2

* cleanup
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants