-
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
RSS: Added Colour support #66419
base: trunk
Are you sure you want to change the base?
RSS: Added Colour support #66419
Conversation
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. |
👋 Thanks for your first Pull Request and for helping build the future of Gutenberg and WordPress, @benazeer-ben! In case you missed it, we'd love to have you join us in our Slack community. If you want to learn more about WordPress development in general, check out the Core Handbook full of helpful information. |
"typography": { | ||
"fontSize": true, | ||
"lineHeight": true, | ||
"__experimentalFontFamily": true, |
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 think we can remove the __experimental
prefixes now that #63401 has merged 👍🏻
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.
+1
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.
__experimental prefixes removed in recent commit.
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.
Great to see the RSS block getting some love. I think this will work well in conjunction with #66411
Here's my ghastly example:
"__experimentalFontStyle": true, | ||
"__experimentalTextTransform": true, | ||
"__experimentalLetterSpacing": true, | ||
"__experimentalTextDecoration": true, |
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.
Probably not a big deal, but the underline control in text decoration won't affect .wp-block-rss__item-title > a
elements as they're being directly controlled by this rule:
a:where(:not(.wp-element-button)) {
text-decoration: underline;
}
I'm not sure whether users will expect text decoration to affect all text within the RSS block 🤔
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.
There might be some options here to apply text decoration more effectively.
Individual block support features, e.g. text-decoration, can have their serialization of styles and classes skipped. They can then be manually applied to the appropriate inner elements. For the Global Styles side of that equation, the Block Selectors API allows custom selectors for individual features so they target the same inner elements.
For an example of skipping serialization of onlytextDecoration
, see the Navigation block.
Note: The navigation block skipped that serialization before the Selector's API was implemented so I'm not sure if it covers Global Styles or not.
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 @aaronrobertshaw for the reference and suggestion.
Tried to follow the same way as in the Navigation block. Bu as you mentioned, it doesn't covers Global Styles. We need to tweak more on this.
I have added all the changes in recent commit.
More suggestions are welcome for this scenario.
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.
Great work on all these block support PRs @benazeer-ben and thank you for your patience handling all the edge cases 🙇
I've left some comments piggy-backing on Ramon's earlier review. In particular, we might be able to improve the adoption of text-decoration support as detailed in this comment.
Also, with the block being server-side rendered, there's a small issue with the background color needing to be reset on the inner rendering of the block (once server-side rendering skips block support attributes as proposed in your border and spacing support PR).
The Tag Cloud block has a PR adopting color support and the background reset issue came up there.
These style resets are similar to the ones added in your PR adopting border and spacing support for this block.
While reviewing the Tag Cloud PR, I found the cleanest approach to reset the styles to avoid issues with the server-side rendering was the following:
.wp-block-rss .wp-block-rss {
all: inherit; /* This addresses borders, background colors etc. */
margin: 0;
padding: 0;
}
Yes, this is handling in that PR. |
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.
This is working pretty well for me, thanks again.
Editor
Kapture.2024-11-14.at.13.18.14.mp4
Frontend
I think I left more questions than answers, sorry.
I also noticed in the editor, block attributes are applied to wrapper and server side rendered component.
I'm not sure this is an issue for color and typography, at least from what I can tell, but I assume other styles like border will have to be handled in a way similar to tag cloud, that is, by modifying the attributes sent to the serverside component.
@@ -27,6 +27,41 @@ ul.wp-block-rss { // The ul is needed for specificity to override the reset styl | |||
} | |||
} | |||
|
|||
// The following rules provide class based application of user selected text | |||
// decoration via block supports. | |||
&.has-text-decoration-underline li.wp-block-rss__item a { |
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'm curious about whether we leave out text decoration altogether.
The reason I ask is because here it's being applied to the RSS links only. Is that the intention?
There are other text fields such as date and author and description excerpt.
Should we not allow text-decoration styles on these?
It's tricky, and I don't know the right answer.
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 think there is some merit to omitting the text-decoration support and revisiting it once the general color, border, and spacing supports for the block land.
@benazeer-ben this is also where keeping PRs atomic helps. For example, one PR for color support only, another for typography, means that the issues with text-decoration and typography supports don't hold up the adoption of color supports. Does that make sense?
& :where(a), | ||
& :where(a:focus), | ||
& :where(a:active) { | ||
text-decoration: 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.
While these styles will override the link element's global text-decoration styles, all other typography styles set in Global styles > Typography > Links will affect links within the RSS block, making the behaviour selective and inconsistent.
What would be ideal I guess is for the RSS block's links to inherit from (in order of lowest specificity to highest):
- The links element styles
- Global styles RSS block
- Block styles
I'm thinking we could delete these lines, and, to make sure Global styles RSS block styles overwrite link elements, bump the selector in the block.json under "typography"
, e.g., "__experimentalSelector": ".wp-block-rss .wp-block-rss__item-title a"
That way, RSS block global styles will override any defaults in Global styles > Typography > Links > text decoration, and the block styles are inline anyway and will take priority.
I could be overthinking it too.
What do you think?
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.
to make sure Global styles RSS block styles overwrite link elements, bump the selector in the block.json under "typography", e.g., "__experimentalSelector": ".wp-block-rss .wp-block-rss__item-title a"
The __experimentalSelector
support flag is deprecated and shouldn't be used. Try the Block Selectors API instead.
This approach Ramon has outlined is what I suggested in my earlier comment (well other than using the deprecated flag 😅):
For the Global Styles side of that equation, the Block Selectors API allows custom selectors for individual features so they target the same inner elements.
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 __experimentalSelector support flag is deprecated and shouldn't be used. Try the Block Selectors API instead.
Oh 🤦🏻 Thanks for setting me straight on that one @aaronrobertshaw Went straight over my head.
Carry on.
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.
Appreciate the patience iterating on these PRs @benazeer-ben 👍
I'd like to propose splitting this PR into two. One that adopts color support and another adopting typography support. Any hold-ups to one (looking at you text-decoration
) won't delay the other.
These style resets are similar to the ones added in your PR adopting border and spacing support for this block.
Yes, this is handling in that #66411.
If this PR is dependent on changes in another PR, we need that to be communicated in the PR description and testing instructions.
I know it involves more juggling, but basing this PR off the one it depends on makes things easier for reviewers and testers who lack full context. This way, the branch being tested includes all necessary changes and integrates well with them. Once the other PR is merged, a quick rebase is all that’s needed before merging this one.
+1 |
Co-authored-by: Ramon <[email protected]>
Sure, I will keep this PR only for color support and move typography support from here to a new one. |
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 splitting the PRs up @benazeer-ben
It's a lot easier to test!
Here's what I tested:
✅ RSS titles reflect global styles Link element colors (including hover)
✅ Changes to RSS global styles colors affect all blocks. Links colors overwrite Link element defaults. Background gradients work as expected.
✅ Block-level colors work as expected and take precedence over everything.
✅ Tested the above hierarchy with theme.json (see below)
I think this is good to go if @aaronrobertshaw agrees.
Example theme.json
{
"$schema": "https://schemas.wp.org/trunk/theme.json",
"version": 2,
"settings": {
"appearanceTools": true
},
"styles": {
"elements": {
"link": {
"color": {
"background": "red",
"text": "green"
},
":hover": {
"color": {
"background": "orange",
"text": "teal"
}
},
":active": {
"color": {
"background": "peach",
"text": "cottoncandy"
}
}
}
},
"blocks": {
"core/rss": {
"color": {
"background": "yellow",
"text": "pink"
},
"elements": {
"link": {
"color": {
"background": "aquamarine",
"text": "white"
},
":hover": {
"color": {
"background": "purple",
"text": "black"
}
}
}
}
}
}
}
}
What?
Add color support to the RSS block.
Part of #43245
Why?
RSS block is missing color support.
How?
Adds the color support via block.json
Testing Instructions
NOTE:
This PR is dependent on some style changes in another PR
Screenshots or screencast
Backend:
Frontend: