-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
Full Site Editor: Applying background color also updates content padding #36586
Comments
@jameskoster @jasmussen Not quite sure who the right folks are to tag for this, but y'all came to mind. Feel free to let me know if I should be getting in touch with other people 🙂 |
I think the issue is valid and needs a good solution, but that there likely isn't a quick fix to this one. The way I'd like to see it working is that the explicit border that is attached to the To an extent that makes this slightly similar to the Border controls, where when a user sets a border width, a border style should also be applied automatically, otherwise you won't see a border. In that vein, I wonder if #34465 on a technical level can help here as well. CC: @aaronrobertshaw |
#34465 won't help much directly. It aims to leverage access to the Global Styles set via a new proposed API in the block editor. It needs access to those styles as the block editor otherwise wouldn't be able to intelligently determine when it should override a border style or not.
As Joen notes, the padding here is hardcoded through CSS styles rather than the padding block support. Other blocks with similar styles also include the Columns and Group blocks. They were recently updated to lower the specificity of those styles so they would work better with padding block support and global styles. After removing/deprecating the hardcoded padding and opting into padding block support, any block wanting to apply default padding whenever a background color is selected, probably only needs a hook to detect that change and update the padding value within the block's attributes. The block editor would need the API in #34178 so that the default padding applied could honour any global styles selections. Deprecating the hardcoded styles could be tricky but if we can get away with using |
Associated: |
So I'm told this issue is related to something I reported on https://core.trac.wordpress.org/ticket/58071 about an undesired padding for navigation block items on pages where the list block is present: The padding is coming from the List block style rule so it is only apparent when there is a list block on the same page as the navigation block with background color:
Related? Or rather just a conflict between to blocks (list and navigation) and in need of another Issue report? |
Description
Applying background color to blocks (list, paragraph, header template part, etc.) adds padding to the block's content area.
After some investigation, I discovered that this is intentional (example for the list block). It makes sense -- this behavior can be convenient, and it generally formats the content in a more aesthetically pleasing way.
However, when we're modifying site structure, this convenience can be both distracting and confusing. To the unfamiliar, it looks like the content is mysteriously jumping. It's also adding padding that the user didn't explicitly set themselves. I think this behavior warrants discussion for the full site editor, because it definitely took me and others off guard.
Note:
The padding appears in the block editor, but not the site's frontend. Is this a bug?
Step-by-step reproduction instructions
The text was updated successfully, but these errors were encountered: