DataViews: Try removing outer padding from the component and layouts#73127
Closed
andrewserong wants to merge 1 commit into
Closed
DataViews: Try removing outer padding from the component and layouts#73127andrewserong wants to merge 1 commit into
andrewserong wants to merge 1 commit into
Conversation
andrewserong
added
[Type] Enhancement
|
Size Change: -1.33 kB (-0.05%) Total Size: 2.47 MB
ℹ️ View Unchanged
|
|
Flaky tests detected in e38a77f. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/19221168072
|
Contributor
Not sure it's best to focus on the footer just yet, as it's also supposed to be sticky. I don't think the scrollbar should be to the right of the footer either. I think the right side of dataviews should align better with the modal close button if possible as well. I personally think the modal shouldn't be scrollable, and instead dataviews should implement the scrollbar, but maybe there are other options. This issue is relevant, I created it last time I explored dataview layouts in a modal - Modal: When 'fill' size is used it's difficult to make content take up the full height of the modal. |
Contributor
Author
|
Thanks for taking a look @talldan!
Yes, same — it feels like it should be the inside area of DataViews that scrolls 👍 |
Contributor
That's how dataviews is meant to work, and how it works on the site editor screens: the scrollable element is |
Contributor
Author
|
Thanks for the feedback on this one, folks! I'll close this out in favour of #72989 which seeks to make padding customisable while maintaining backwards compatibility for components not setting a |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What?
Possible fix for: #72336 and an alternative to #72989 (which looked at adding padding as a configurable prop to DataViews)
This PR explores the idea of removing padding from the DataViews component (outer padding that is — internal padding, like the top of the footer, or vertical padding around the grid items is preserved).
When reviewing, I'm very happy for feedback on the overall direction, not just the code changes. This would be a breaking change, so I think we'll want to be fairly careful when considering the change.
Why?
As described in #72336, the existing padding in DataViews means that there is unexpected additional padding when using DataViews (or DataViewsPicker) in contexts where padding already exists, such as Modals.
The idea in this PR and discussed in the issue is to try out removing padding from DataViews itself, so that the consumer is responsible for handling padding.
This presents some challenges and drawbacks, which I'll describe below. But the positive is that (at least in theory) the styling of DataViews can be slightly simpler.
How?
Removing padding from DataViews highlights some challenges and has its drawbacks, including that consumers will need to update their styling to support this change. Outstanding issues include:
overflow: auto, any buttons at the edge of the DataViews now have their focused outlines cut off. This is because there is no longer padding to give it clearance.Testing Instructions
npm run dev:storybookand try out each of the different DataViews and DataViewsPicker stories to see how it looks and feelsTesting Instructions for Keyboard
Screenshots or screencast
🐛 Issue: Scrollbar sits flush with the grid items:
🐛 Issue: List items hover state no longer looks balanced + focus styles on filters / config buttons gets cut off:
🐛 Issue: When displayed in a Card, items no longer extend full width, so each item feels less like "part" of the card:
Modal: Generally looks good, but the top padding on the footer is less than the default padding of the modal, so it looks unbalanced: