Patterns: Remove padding from root container to stop it affecting preview #52776
Conversation
glendaviesnz
added
[Type] Enhancement
|
Size Change: +20 B (0%) Total Size: 1.44 MB
ℹ️ View Unchanged
|
|
Actually, I don't think this is going to work as some themes/blocks set margins based on the root container padding being there in order to implement full-width layout, and these break with the padding removed: before: 
after: 
I can't think of a way around this as blocks/themes could be using any number of selectors/styles that are dependant on the padding so not something we can apply resets for as far as I can tell 🤔 @tellthemachines, @andrewserong did you have any thoughts about this from a layout styles perspective? It seems like the safest option is to just accept the additional padding in the previews. |
|
Oh, interesting problem @glendaviesnz! @tellthemachines might have more to add, but I'm wondering if the issue with trying to override A challenge in general, though, is that some patterns might look best with padding removed (i.e. "full bleed" patterns that have a background colour that should be extended to the edges), and others might look best with a little breathing room. For example, to my eyes, the top-most pattern in the screenshots in the PR description looks best with a little padding, but the two directly beneath look nicer without it. Also, I wonder if an alternative that intentionally added a little padding around the whole preview might help to make the pattern preview feel a bit more like it's previewing in the context of how it might look in a site, rather than completely edge-to-edge? That is to say, what if we had padding at the top and bottom of the previews in addition to the left/right? From my perspective, I could imagine padding in the block preview being something that folks might want to sometimes include or sometimes not, so another idea is whether or not it could be configurable / whether to pass in the padding overrides in Just some thoughts, though, I don't feel too strongly about any particular direction — whichever folks are happiest with in terms of design / consistent appearance 🙂
Making changes to padding can be tricky, so I also don't think it'd be a bad thing to accept the additional padding in the previews in the short-term. |
|
Agree that overriding the underlying css var could be a good to try.
Would you mind unpacking that thought a bit? When are you thinking this could be useful?
I had a similar thought, and I wouldn't rule it out, but I suspect we'd continue running into confusion about where the UI ends and the pattern begins. It wouldn't really solve the 'text-butting-up-the-the-preview-edge' issue either because the background would need to contrast the pattern. Additionally we'd need to come up with something that works in all the contexts in which patterns appear – inserter, pattern grid in site view, pattern explorer, etc, which could be tricky. |
Sure! I think there's a couple of parts to my thoughts on this:
I imagine the latter problem is probably a bit tricky to determine automatically, but the main thing I've been thinking of has been that patterns shipped in a theme often look good in previews that are full-width, but synced patterns that I might create directly in my site are possibly going to be chunks of text I want to insert into posts or pages, so might do with some padding? E.g. here's side by side a full width pattern and one made up of text: 
Unfortunately, I'm not too sure what would make for good defaults for these sorts of UIs as we can't really know where folks expect to use their patterns. So I think I'd probably lean toward one of two things: 1) accept that there'll be padding shown where we don't want it (and sometimes an absence when we do want it) , or 2) override the padding, but make it a flag or setting so that it can be switched off if need be. If going with the latter, then the choice might be between having the padding override be opt-in or opt-out? For example the
Definitely tricky given all the different contexts! |
|
I think a big part of the problem for me is the lack of clarity and consistency around the padding. For instance if the active theme doesn't include any global padding, then neither do the previews. This makes the experience inconsistent across themes. The previews are part of the UI, so should behave consistently. I don't personally have an issue with the text patterns filling the preview area because that is an accurate representation of the pattern behavior. I see the thumbnails as shrunken instances of the raw pattern rather than 'previews' of how they might look inserted in a post or page. But if we feel strongly then perhaps we could try @richtabor's suggestion about only allowing the padding on text patterns? I worry this might increase the complexity quite a bit though? |
|
Good observations!
I definitely don't feel strongly about it, and you make a good argument about the text patterns filling the preview area being an accurate representation of the pattern. Also, very much agree that it'd be good to avoid adding unneeded complexity 👍 |
|
This has got a bit stale so going to close for now. |
What?
Overrides any root padding added by a theme in the pattern preview iframe
Why?
Fixes: #52421
How?
Sets padding to
0for.is-root-container.Testing Instructions
In TT2 theme load the pattern preview panel in the inserter and check that there is no additional external padding on the previews -
Featuredis a good category to check.Screenshots or screencast
Before:
After: