Image: Add border block support for color, width, and style #31366
Conversation
aaronrobertshaw
added
[Block] Image
|
Size Change: +828 B (0%) Total Size: 1.25 MB
ℹ️ View Unchanged
|
|
Testing by downloading the special Gutenberg plugin. Procedure: I copied the TT1 experimental-theme.json file into Twenty Twenty One theme root folder. Renamed experimental-theme.json to theme.json, and replaced all the contents with: Did a hard refresh. Even installed Autoptimize. Made another post. I have not been able to see the Border panel settings yet. I assume there is something I am not doing right. |
|
@paaljoachim thanks for testing this. It's working ok for me in the TwentyTwentyOne theme.
I think the problem might be the vague testing instructions. I've updated them to include a link to the current theme.json file I last tested with. If you did indeed replace all the Example |
Core Block StylesIn general, there is only the "Rounded" block style by default. This style could be removed after a further iteration to the border block support to allow a greater max border radius value. TwentyTwentyOne Block StylesThe TwentyTwentyOne and TT1 Blocks themes also introduce "Borders" and "Frame" block styles. These styles could be achieved via the border block support (and padding for "Frame" style). The block styles do however give the user a simple, one-click option to set a consistent border. SummaryIf we were to remove the block styles, existing blocks with those styles would keep the Ultimately, I think whether we remove the block styles or not comes down to convenience and simplicity for the user at the price of some overlap and duplication between block styles and the block support features. Happy to hear others' thoughts on this and/or iterate on the block styles in a separate PR. |
There was a problem hiding this comment.
Looks good as far as I can tell! Works as expected and unit tests pass. Might need some more work when it comes to the block styles part. It could be confusing to have the width and color controls there when the border style is set to none (or default, depending on defaults), though.
But, as you said, but that can probably happen later down the line.
|
Thanks for testing and the feedback.
I agree, this would be a nice improvement. One difficulty I've previously run into in this area is there isn't a reliable means to retrieve what the "default" value of any global style is in the normal post editor. In the site editor these are available within the state. As more block support features are adopted, I think the need to address this will increase. Also, there is an open issue to refine the border block support controls #31337. Part of the approach in that was to order the controls in line with the CSS order. Hiding and showing controls might not work well there. Either way, the actual block support controls will need to be refined in a separate PR as suggested. |
|
Hey Aaron. Thank you for working on this amazing PR! It is great to get Border settings in place! Copied your experimental-theme.json file into Twenty Twenty One. This is what I see. Brainstorming. Border style drop down. Selecting "None" should hide the controls below. I noticed that when I move the slider a tooltip shows up, and will stick in place until I click somewhere else.
I went through and checked each Border style type - Solid, Dashed and Dotted. Backend and frontend looked identical. Image Styles. These do not work correctly when Border affects are in place. Such as selecting a dotted frame with a Border width of 40, and Border radius of 30. Example clicking Rounded did not show a rounded image.
Clicking through Rounded (no affect), Borders (no affect) and Frame (made the image smaller). I turned off all adjustments I have made through Border settings also the border color and now the rounded style worked again. The Rounded style is a bit glitchy when experimenting with the Border settings. |
|
Great feedback @paaljoachim! Thanks for taking the time to be so thorough.
There is already an open issue to refine the border support UI. It will actually do away with the I'm actually in the process of working on the refinement of the border support UI. There are some blockers for it though which include:
There is also a second PR adding border support to the group block. Both that and this PR won't land before the border block support UI refinements are complete.
As part of the refinements mentioned above, the both the width and radius RangeControls are being replaced so hopefully this won't be an issue moving forward.
Yes, the specificity of the border block support styles (inline styles) is greater than the CSS class styles applied via the block style e.g. Rounded. In my earlier comment on the block styles I listed some options. We could remove the block style entirely but the block styles do offer a simple one click configuration option for users. Another possibility is upon changing the selected block style we could clear the border support attributes. That might be the best compromise option.
This is due to the Frame block style actually applying padding. Given the width of the block doesn't change its the image that shrinks in this case. All the border styles have been overridden via the deliberate selections in the border panel.
Agreed. Given themes can add their own block styles as well I'm not sure we can remove all possibility of conflict there. Having an agreed upon approach to handling it would certainly help. Especially given this will be the case for all block support provided styles not just borders. |
aaronrobertshaw
force-pushed
the
add/image-border-support
branch
from
fbd6172
to
48a8d1d
Compare
|
@jasmussen This PR has just been rebased to incorporate the recent border support UI changes. Do you feel this is in a place where we can move forward on adding border control to image blocks?
|
|
This is what I see:
I left a few comments on the Cover PR which also apply here. Things like setting a default border style and width if you start with a color, perhaps moving the border panel (if collapsed) to the bottom next to Advanced. I also noticed that the "rounded" style no longer works for when a border radius is applied; I think this speaks to us needing to replace that style variation with a "preset shortcut". I.e. instead of applying On a more high level, about all these border support PRs (thank you for your work!), here's my thinking about them:
|
|
Thanks for the great feedback as always Joen!
I've replied in detail with my thoughts on the suggestions on the Cover block PR. Hopefully, they are clear enough. Essentially, those thoughts boil down to our block supports being overrides for the merged style value coming from theme.json, global styles etc. We don't have access to those merged values in the block editor at present. Try to set any default on the block support provided controls would likely mean blindly overriding theme values the use might be happy with already. I do appreciate the point being made though regarding the flow. At the moment the simpler case is how it currently works which is consistent across block supports. It could also be the option that requires the least re-editing of values by the user depending on their theme.
Good observation. This has actually be spoken about and an issue created to track the discussion. The idea is to explore block style variations as sets of block support style attributes. As you mentioned, the rounded block style is effectively just a shortcut to applying a standard border radius to the image
In technical terms, the border block support can only apply the border radius via inline styles. It will take precedence short of Conceptually, if a user is going to the lengths of expanding the border support panel and configuring an explicit border radius value, that makes sense to me in terms of taking precedence. A rounded style that is kept consistent across images also sounds perfectly reasonable. The block style does offer that consistency until such a time as we have implemented styles as sets of style attributes.
I’m not sure the suggested flow fixes work 100% with how block supports function. If we have to change how all block supports work, these will fast become large issues.
Agreed. That can be discussed and explored separately. We’ll be in a better place to do that once we have the new panel in place.
Each block opting into the support will go require a PR to do so. That will provide the chance to evaluate them as required. By the way, the group block already has been opted into border support. It’s only a matter of whether the theme enables those controls or not. Thanks again for all the considered responses. It definitely helps me work out what I'm missing to progress these PRs. |
aaronrobertshaw
force-pushed
the
add/image-border-support
branch
from
48a8d1d
to
8ed1174
Compare
|
I've rebased this PR and added some baseline border styles in line with the discussion on the Cover block border support PR. This also required adding the same baseline styles for the image crop area. |
aaronrobertshaw
force-pushed
the
add/image-border-support
branch
from
ae570a3
to
24f4d0e
Compare
|
@paaljoachim This PR is ready for further testing and hopefully a final review 🎉 |
aaronrobertshaw
changed the title
There was a problem hiding this comment.
I've taken this for a run in the editor and it works as advertised for me!
✅ In the editor the block border css declarations appear on the img and .wp-block-image__crop-area elements. The border persists during and after cropping.
✅ Image borders for images and gallery images look good on the frontend
✅ Creating huge border widths in a gallery does not collapse columns
✅ styles.blocks['core/image'].border styles are applied appropriately
✅ Global styles updated in the site editor are applied appropriately (and taken precedence over theme.json)
| "radius": true, | ||
| "width": true, | ||
| "__experimentalSelector": "img, .wp-block-image__crop-area", |
There was a problem hiding this comment.
Great work getting this to the finish line @aaronrobertshaw! Tested with a few different block and classic themes, and all working nicely 👍
✅ Crop tools are working nicely in the editor with and without a custom border
✅ Custom border color is working nicely in the editor and site editor
✅ Image border in global styles works well
✅ Deprecation changes look good to me visually
The only visual issue I encountered was with a caption on an image in a gallery block, where that image has a border and radius in global styles the Image block is set to have a border and radius. The linear gradient and absolute positioning of the figcaption mean that it extends over the area of the border radius:
Given the effort already to ensure that the border (and its radius) does not affect the figcaption, and that this is handled for individual blocks with radii, I think this isn't worth attempting to fix in this PR, particularly when separately there's work and recent PRs looking at customising the figcaption.
In the "tiny nits" department, elsewhere there's efforts to remove lodash as a dependency, so in a follow-up at some point, it might be worth us seeing if we can swap out the isEmpty calls for another approach — given the iterations on getting to this stage with this PR, though, definitely not a blocker for landing this one.
So, all in all this LGTM! 🎉
|
I appreciate the reviews @ramonjd and @andrewserong, cheers 🍻
Thanks for raising this edge case. When borders are applied individually to blocks, we can add an additional CSS class to them that allows us to adjust the positioning of the caption. When borders are configured via Global Styles they are targeted via a simple CSS selector and the block won't know whether or not the caption should be repositioned. There could be a few options to explore in follow-ups.
Agreed. This is a side effect of just how old and long-running this PR has been. I'll happily address this in a separate follow-up. |
|
Thank you very much for working on this feature Aaron! It is greatly appreciated! Testing. Clicking the Lock/Unlock icon will open or close the individual sides attributes/properties. Example. I would expect to see the Border icon show as unlocked because I have gone in and adjusted the properties of different sides.
|
bph
added
Needs User Documentation
Fixes: #38801
Depends on:
Part of:
Description
This takes advantage of border block support to add those features to the Image block.
How has this been tested?
Fixture tests and manually.
Note: There is a current bug on
trunkimpacting resetting of controls.Test Instructions
npm run test-unitand ensure the image fixture tests passScreenshots
Screen.Recording.2022-07-15.at.11.31.52.am.mp4
Types of changes
New feature.
Checklist:
*.native.jsfiles for terms that need renaming or removal).