Tracking: Dimensions Design Tools Consistency #43243
Comments
aaronrobertshaw
added
[Type] Tracking Issue
|
I think we need to be careful about blocks that are server-side rendered.
The problem is that the hooks (
Simply excluding To address this I would like to offer three solutions. Or, are there any other solutions that would be appropriate? 1. Skip serialization{
"supports": {
"spacing": {
"__experimentalSkipSerialization": true,
"margin": true,
"padding": true
}
}
}In this case, inline padding/margin styles are not automatically generated, so they must be generated explicitly in a callback function, as the search block does. 2. Omit padding / margin from attributes of
|
|
Thanks for flagging the issue and laying out the different options @t-hamano! Another potential option is that for blocks that are using the Do you think something like that might work? |
Yes. I checked with you about #43497 that you mentioned in this comment, and I think that approach makes sense. I think the block support Here is my approach as I see it: // Use only margin support in the block wrapper style.
const blockStyles = {
...pickBy( blockProps.style, ( value, key ) => key.match( /^margin/ ) ),
};
// Don't pass margin attribute to ServerSideRender component.
const serverSideRenderAttributes = {
...attributes,
style: {
...attributes.style,
spacing: { ...omit( attributes.style.spacing, [ 'margin' ] ) },
},
};
return (
<div { ...blockProps } style={ blockStyles }>
<ServerSideRender
key="tag-cloud"
block="core/tag-cloud"
attributes={ serverSideRenderAttributes }
/>
</div>
);I believe this approach has two advantages:
|
|
Very interesting thoughts @t-hamano! This is a tricky one. Ideally to best represent what happens on the site frontend, I suppose all the inline styles would be applied to the same element that exists on the site frontend. For example, in the editor, the Tag Cloud block is rendered as a
But, that's a very good point. In order to work properly with overriding layout styles, it does seem that we'd need to have margin be output on the wrapper From my perspective, I think including some extra logic in the block's |
Yes, that makes sense. Let's deal with them individually, along with blocks that have already been merged with block support. Another thing to discuss is how to handle the issue of additional class(es) being rendered as duplicates, as @ndiego submitted in #43653. I think we have three options:
The second plan would be appropriate if we want to respect the match with the front end side. However, since the core class of blocks ( If these directions are solidified, I think it might be a good idea to first proceed with the review of #43653 👍 |
|
An overall update on progress towards design tools consistency has been added to the primary tracking issue, including our goals for WordPress 6.1. |
|
I suggest not adding spacing to the more block which uses the |
|
Small update: as of #45300 there is now a Min Height dimensions block support that we can opt into. That PR has opted in both the Group and Post Content blocks, and I've updated the table in the issue description. @jasmussen flagged on the PR (here: #45300 (comment)) that when we use the Min Height block support, it usually shouldn't be a default control (that is, it should be optional and only exposed via the drop-down menu). There is also a follow-up tracking issue in #45501 to look at tweaks and enhancements for the UI of the Min Height controls. |
|
I have updated the table cell because I found #43243 which adds margins to the Embed block. |
|
Noting this heavily requested negative margins feature request as potentially that could be addressed as part of this wider work: #32644 |
|
Thanks for flagging that issue @annezazu 👍 It is something that has been explored previously (#40464), however, there were a few blockers at the time, and more recently, there was an issue with layout support styles overriding the margin block support styles. That last issue was a blocker to adopting the design tools here as well. Supporting negative margins will likely require some design work to ensure we come up with a nice UX. So while I'm 100% on board with us supporting negative margins in the near future. I think it might be better to keep it separate to the efforts adopting dimensions and spacing design tools as they have a knack for hitting enough roadblocks as is 🙂 @andrewserong's comment on the negative margin feature request issue goes into more detail on what we need to address and provides extra context. |
|
Update: I have added the Footnotes and Details blocks to the list. |
Overview
This issue details the current state of dimensions and spacing block support or design tool adoption across all blocks and tasks required to fill any gaps. Overall design tool consistency efforts are being tracked via the parent issue: #43241.
Guidelines for Adopting Spacing Supports
truerather than["top", "bottom"]box-sizing: border-box. This will be reviewed on a case-by-case basis. (Exceptions likely).Legend
Block Support Adoption
Note: Deprecated blocks have been omitted from this table. e.g. Comment Author Avatar, Post Comment & Text Columns.
Known Issues
Several blocks adopting padding support will also probably need
box-sizing: border-boxadded to their styles. A sweep should be completed before closing this issue.Before the Post Template block can fully adopt spacing supports it may need a bit of a refactor: Post Template: Refactor ad hoc flex container to use layout block support flex type #44557
Merged PRs
The following list details all the PRs merged as part of this effort to increase spacing support.
PRs with pending questions, discussions, or concerns
Possible Follow-Ups
The text was updated successfully, but these errors were encountered: