-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
Embed Block: Border support added #66386
base: trunk
Are you sure you want to change the base?
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 Unlinked AccountsThe following contributors have not linked their GitHub and WordPress.org accounts: @benazeerhassan1909. Contributors, please read how to link your accounts to ensure your work is properly credited in WordPress releases. 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. |
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.
Thank you for putting this together @benazeer-ben 🙇
I get the feeling this one is going to have to wrangle several edge cases given the various types of content the block can embed e.g. youtube videos, tweets, spotify and audio links etc.
Testing this PR as is, I've run into a couple of issues:
- To support border radius we should probably also support padding on the block. This might need design feedback as discussed on Video: Add border support.
- The current approach in this PR applies the border to the block's wrapper. The embed block can also include a caption. Other blocks such as the image block, apply the border to the actual element that needs the border leaving the caption outside it. I think this would be the expected behaviour here as well.
- When adding border or padding support we need to ensure the block has
box-sizing: border-box
styles so that it will respect any width its parent might be trying to apply to it.
Box sizing issue:
Embed blocks with different content and captions:
Next Steps
To move this PR forward while waiting on some design input regarding border-radius adoption, I think we can:
- Skip serialization of borders on the block wrapper and apply it to the embed's inner wrapper so the caption falls outside it. See Video: Add border block support #63777 for some clues on this approach.
- Add
box-sizing: border-box
to the block. (there's also a separate PR aimed at generically adding this style to blocks but it might be slow to land given the potential to cause visual regressions).
Thanks again for all your work on adopting block supports, it's appreciated 👍
Thanks @aaronrobertshaw for the detailed feedback and details. Implemented skip serialization of borders on the block wrapper and applied it to the embed's inner wrapper. For now padding support also added, if we get some design feedback we can change it accordingly. Please let me know if we need more tweak on this. Screenshare.-.2024-11-15.9_02_39.PM.mp4 |
} | ||
}, | ||
"selectors": { | ||
"border": ".wp-block-embed__wrapper " |
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 convention with these selectors is to explicitly include the block's class. In this case, .wp-block-embed
.
I'm not 100% whether it is required but it does make it clearer the intended target for the styles. That block class is also tweaked when generating block style variation selectors for the block.
One last nit, there's an unnecessary space at the end of that selector. Better safe than sorry, we should clean that up in case theres some theme.json processing somewhere that wasn't expecting it.
@@ -43,12 +43,29 @@ | |||
"supports": { | |||
"align": true, | |||
"spacing": { | |||
"margin": true | |||
"margin": true, | |||
"padding": 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.
This applies the padding to the Embed block's wrapper.
The justification for adding the padding support was so that it could be used to counter border radius and prevent the content from sticking out beyond the border.
This might need to be applied to the inner embed wrapper as well.
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.
Thank you for iterating on this 👍
I've given it a test and there are still a few issues. Most notably:
- Padding is applied to the wrapper so doesn't help with the border radius problem
- The custom selector for borders should probably also have the block class in it to ensure compatibility with block style variations.
- PR description and test instructions no longer match what the PR does
On that last point, I find it handy each time I iterate on a PR to re-test it in full asking myself some questions like:
- Have I changed what the PR does?
- If it does something new, how do I test that?
- If the PR is related to a block, are there different ways to use the block? e.g. testing the embed block with not just a video but all the other embed types.
Answering those questions then means you already have everything you need to update the PR description in a way that ensures things don't get missed and it's easier for reviewers.
Here's what I see when applying both padding and borders to various embeds. I'd expect the padding within the border, not outside it otherwise it's basically just a second margin.
Thank you for your detailed feedback and for testing the PR! 🙏 To keep things straightforward and manageable, how about we focus only on the border support for this PR and hold off on padding and border radius for now? This approach should help us avoid any complications and keep the scope of this PR more focused. Apologies for the confusion caused by the current PR description and test instructions—I’ll make a note to clarify these aspects in future PRs. Your suggestions on updating the PR description through iterative testing are very helpful, and I'll incorporate this approach going forward to ensure clarity and completeness. Thank you again for your patience and insights! |
As the initial intent was to adopt border support including border-radius (which I think is expected by users), padding is a natural inclusion here. I think there is some benefit to introducing both at the same time where testing can cover the whole picture and how the supports interact together.
In some ways I agree, however, there are some curly problems around deprecations and block supports, especially if the application of block supports might require skipping serialization. To me, that risk means it's better to work through the whole process here holistically. Additionally, you've already gone to the efforts of skipping serialization of border styles to apply them to the inner embed wrapper. It's not much more to do the same for padding support. The Some examples of individual features skipping serialization are:
Lastly, adding borders to the Embed block is a bit of a niche use case. This means there isn't a pressing timeline to deliver the feature. We have the luxury to take our time, dot our i's and cross out t's. Are you onboard with that? |
@aaronrobertshaw Thank you for your thoughtful response and for outlining the considerations so clearly. I agree that addressing border and padding together provides a more complete solution, especially given how they interact. The examples of __experimentalSkipSerialization for individual features are very helpful and will guide the implementation. I'll proceed with implementing the feature, ensuring deprecations and block supports are handled properly while keeping the scope clear and test instructions comprehensive. Thanks again for guidance— I’ll keep updated as I progress! |
I’ve started implementing the padding skip serialisation, but I’ve encountered an issue when working with this. Since the embed block includes position absolute style settings for the iframe, skipping padding serialisation and applying manual settings to the inner wrapper does not have any effect. I’d appreciate any suggestions on how to handle these edge cases effectively. Should we consider an alternative approach for blocks with absolute positioning? Thanks in advance for your insights! |
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 highlighting that issue and the detailed info @benazeer-ben 👍
This is a tricky one!
There could be a few options to explore to allow supporting padding e.g. an extra wrapper, using flex/grid positioning, transforms for the iframe. All of those options have their own pros and cons whether that is backward compatibility, needing deprecations, or impacting the aspect ratio support. This would be better suited in a follow-up PR.
Given the complexity uncovered here I think your earlier suggestion to avoid padding support and focus on border styles is a good one. We'll need to omit support for border-radius
also.
Border styles will still need to be applied to the inner wrapper and I don't think that will change. In a follow-up that pursues border radius support, I'd expect that to also be applied to the same element, so we shouldn't be painting ourselves into a corner here.
Let's go with the plan to omit padding and border-radius support so we can at least offer some border support in the short term.
How's that sound to you?
Thank you for the detailed breakdown! I agree with your assessment—introducing padding support, especially given the iframe's positioning complexities, could indeed lead to challenges with backward compatibility and aspect ratio handling. Focusing on border styles while omitting padding and border-radius support for now sounds like a practical approach to deliver incremental improvements without overcomplicating this PR. I’m on board with this plan and will proceed accordingly, ensuring border styles are applied to the inner wrapper as discussed. For border-radius and padding, I agree these can be revisited in a follow-up PR with a more comprehensive approach. |
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.
We're slowly narrowing in on something we can land. Thanks for your patience @benazeer-ben 🙇
I've left a few comments inline on some issues I spotted after the latest updates.
@@ -47,8 +47,24 @@ | |||
}, | |||
"interactivity": { | |||
"clientNavigation": true | |||
}, | |||
"__experimentalBorder": { | |||
"radius": false, |
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 border support is opt-in by default so we shouldn't have to explicitly set it to false
. That said, this does communicate that it was a conscious decision to omit border-radius support so we can leave it..
className={ borderProps.className } | ||
style={ { ...borderProps.style } } |
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 not sure about these new props. Would it be more forward-compatible for them to be combined into something like wrapperProps
? It might also help communicate the intended use for the class name and style.
It might also help get other reviewers if we can update the test instructions to cover this scenario as well as others (e.g. explaining to test with a WordPress post as an embed, youtube video, tweet, spotify link etc.) Even better if you could include some test URLs 🙏
@@ -13,7 +13,7 @@ const attributeMap = { | |||
marginwidth: 'marginWidth', | |||
}; | |||
|
|||
export default function WpEmbedPreview( { html } ) { | |||
export default function WpEmbedPreview( { html, className, style } ) { |
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.
As noted in my earlier comment, these new props might be better combined into a single wrapperProps
prop or something.
Co-authored-by: Aaron Robertshaw <[email protected]>
What?
Adding border support for Embed block.
Fixes #43247
Why?
Embed block is missing border support
How?
Adds the border support via block.json
Testing Instructions
NOTE:
Sample URLs for Testing:
WordPress Post:
https://wordpress.org/documentation/article/embeds/
YouTube Video:
https://www.youtube.com/watch?v=sYNqeahE2rg
Tweet:
https://x.com/WordPress
Spotify Playlist:
https://open.spotify.com/playlist/37i9dQZF1DXcBWIGoYBM5M
SoundCloud Track:
https://soundcloud.com/forss/flickermood
Screenshots or screencast
Screenshare.-.2024-11-26.3_47_53.PM.mp4