-
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
Unset inherited backgrounds on Posts Lists. #37941
Conversation
Size Change: +54 B (0%) Total Size: 1.13 MB
ℹ️ View Unchanged
|
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 PR Joen!
The root problem of this is a tough one and by also reading the issues/discussions about it, there are many angles to it.
I feel like I'm leaning towards the alternative from @oandregal to exclude ul/ol
which are blocks, but I could see a short term solution like this one for core blocks that don't have color
support(?), if we don't find a better alternative soon. That would mean to apply such treatment to all core blocks that fall into this category - there are more than this one and social icons.
@@ -11,6 +11,11 @@ | |||
list-style: none; | |||
padding: 0; | |||
|
|||
// Unset background colors that can be inherited from Global Styles with extra specificity. | |||
&.wp-block-post-template { | |||
background: none; |
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.
I guess in this approach we should also handle text and link color too.
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.
exclude ul/ol which are blocks
If we could find some solid and low-specificity code that worked in the editor and frontend, I'd be fine with that too 👍 👍
But at the same time, I fundamentally don't think the inheritance is necessarily a big problem.
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.
Looking at this block, it's a container of blocks that acts as an intermediary between the query and the posts themselves. It can't be nested with any block other than query.
The only scenario where I see this could be problematic is when a theme tries to target this block specifically for color. For example, if it has a margin/padding and the theme wants to assign the color to this instead of targeting the query. I've looked into some themes (including the default ones that bundle with core) and none does this.
Given that we're blocked as to how to solve the overall issue and this is an uncontroversial fix that moves things forward, I'd think this is something we should merge. I'd still like someone with a lot more theme developer experience than I have to confirm this is fine for themes.
Also, probably extending this to any other inherited property supported by the list block is worth exploring.
Cool, I agree that it's a very trivial fix and mostly harmless. I have edited the description of this PR so that it shouldn't close #37388 when merged. Let's land this and see how things feel! |
Backported to the minor. |
Description
Makes progress on #37388, alternative to #37528, and goes well with #37940.
If you set the List block to have a specific background color in global styles, the ul block is targetted, making that color bleed into the Posts List and Query Loop blocks:
This PR unsets any inherited colors on the
ul
element used:How has this been tested?
Change the background color of the List block in global styles. Then insert a Posts List or Query Loop block, they should still have a transparent background.
Checklist:
*.native.js
files for terms that need renaming or removal).