-
Notifications
You must be signed in to change notification settings - Fork 4.4k
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
Popover: Introduce overflowPadding
prop to support adding an offset
#69555
base: trunk
Are you sure you want to change the base?
Popover: Introduce overflowPadding
prop to support adding an offset
#69555
Conversation
overflowOffset
prop to control maximum height calculationoverflowOffset
prop to support adding an offset between popover and viewport edge
overflowOffset
prop to support adding an offset between popover and viewport edgeoverflowOffset
prop to support adding an offset
b6f0322
to
15888d8
Compare
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.
To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this problem not affect the X axis? The current prop naming and descriptions feel a bit misleading on first glance because it only works on the Y axis.
I'm also wondering if these "padding" values (as Ariakit names it) should actually be set globally in some way, at least at the app level, if not at the wp-components level. I haven't assessed all the use cases, but it seems like this padded behavior is something all popovers would want by default?
overflowOffset
prop to support adding an offsetoverflowOffsetY
prop to support adding an offset
06d0b01
to
18f4007
Compare
I couldn’t find any instances where the popover overflows to the viewport edge along the X-axis. This is likely because, in most cases, the popover does not extend beyond the associated toggle button in that direction.
Additionally, popovers rarely become scrollable along the X-axis, and when they do, it may not provide the best user experience. I'm interested in also knowing your thoughts on this.
I've fixed this in 18f4007
Since most popovers don’t extend to the viewport edge due to their typically limited content, it might be best to handle these scenarios on a case-by-case basis. That said, applying a global padding style or setting the default |
Some quick thoughts:
|
@@ -233,7 +234,9 @@ const UnforwardedPopover = ( | |||
|
|||
// Reduce the height of the popover to the available space. | |||
Object.assign( firstElementChild.style, { | |||
maxHeight: `${ sizeProps.availableHeight }px`, | |||
maxHeight: `${ | |||
sizeProps.availableHeight - overflowOffsetY |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like the size
middleware accepts a padding
prop which we could use instead of manually subtracting the overflowOffset
.
I would also take a look at what Ariakit does and take any inspiration — for example, we could apply the overflow offset to both axis?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the suggestion, @ciampo!
Using the padding
prop within the size
middleware is the best approach. As documented here, it accepts either a single number (applying uniform virtual padding) or an object for specifying padding per side. This is how Ariakit
implements it.
I've incorporated this in commit 5d9491b and renamed the internal prop to overflowPadding
for consistency with Ariakit
.
With this change, we can now apply virtual padding across all sides.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mirka also wanted to make sure you agree with keeping one overflowPadding
prop (instead of having a dedicated one for the Y axis)
overflowOffsetY
prop to support adding an offsetoverflowPadding
prop to support adding an offset
fc04545
to
784fb4d
Compare
@@ -142,6 +142,7 @@ const UnforwardedPopover = ( | |||
inline = false, | |||
variant, | |||
style: contentStyle, | |||
overflowPadding = 0, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mirka I'm torn between a default of 0
and 8
, what are your thoughts?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The offset feature may be useful for certain things, but I just realized it doesn't really help in solving the actual UX issue that prompted this 🙈 #69553 (comment)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You have a point! But specifically for the default value, I'm learning towards 0
as it wouldn't introduce any changes to existing Popover
usages. WDYT?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If it's purely for padding and not for addressing the original UX issue, then I think the default would have to be 0
, yes.
I can't say without doing an audit, but I notice that there are a lot of popovers that become fullscreen (completely filling the viewport with no padding) on mobile widths. So we wouldn't want to mess up those instances, though I'm not immediately sure how those are implemented.
784fb4d
to
0cd2051
Compare
What?
Closes #69553
This PR introduces a new
overflowPadding
prop for thePopover
component, allowing precise control over the offset between the popover container and the viewport edge.Why?
Previously, there was no way to adjust the offset when the popover container reached the viewport edge, often cutting it off or partially obscuring near screen boundaries.
How?
overflowPadding
was introduced.padding
property withinsize
middleware fromfloating-ui
.Testing Instructions
View Options
.Browser Window
.Testing Instructions for Keyboard
Same.
Screenshots
Before
After