-
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
Units block support in block.json does not work #47519
Comments
I'm unable to reproduce this in Gutenberg 17 and 6.4; I can use vh and vw in the gallery block as indicated below. However, I wonder if we should leave this open because I do notice that the gallery block's support has supports.units but the navigation block has supports.spacing.units Is that intentional?
For example: |
theme.json values work, but block.json does not. |
I've tested it in all major versions since WP6.0, when the gallery block first supported gap. Overriding units in block.json does not originally work, and it does not appear to be a bug or regression. Therefore, I will label this issue as Enhancement. |
Perhaps @glendaviesnz or @ramonjd knows the purpose of these block supports or if they can even be removed from the block.json in the respective blocks. |
Thanks for the ping @carolinan, and for testing @t-hamano I can confirm @carolinan's observation: setting "spacing": {
"units": true // default is [ "px", "em", "rem", "vh", "vw", "%" ]
} Border units are also taken from spacing and therefore controlled by theme.json. And the unit control component has the same default (uses spacing units):
I'd lean on @glendaviesnz's knowledge in relation to spacing units. As for others, typography font size units are hard-coded it appears:
To remain consistent with other settings, should block.json units override theme.json settings? Looking at the code, I suppose it would be possible to grab the block.json overrides where it makes sense: // For units that use spacing.units
const [ availableUnits ] = useSettings( 'spacing.units' ); // theme.json
const blockUnits = getBlockSupport( blockName, 'spacing.units' ); // block.json
const units = useCustomUnits( {
availableUnits: availableUnits || blockUnits || [ 'px', 'em', 'rem' ],
} ); Or maybe the better place would be useSettingsForBlockElement, which states to be a "React hook that overrides a global settings object with block and element specific settings." We'd probably want to audit the places we use custom units to ensure values make sense, e.g., would |
Shouldn't block.json provide defaults, and theme.json override them? |
Sorry, that came out completely wrong. 😄 🙃 I meant block.json supports settings could be the place where a block defines whether it supports something, e.g., units. And you're right, theme.json overrides values of supported settings. |
I'm a bit confused, is the For example, if we want to change only the unit of a specific block, we can define it in {
"$schema": "https://schemas.wp.org/trunk/theme.json",
"version": 2,
"settings": {
"appearanceTools": true,
"spacing": {
"units": [ "px", "%" ]
},
"blocks": {
"core/group": {
"spacing": {
"units": [ "vh", "vw" ]
}
}
}
}
} If this assumption is correct, is the |
It's a good question. I think a blocks' block.json could still define defaults if it makes sense in context. Maybe the Another example, I suspect the gallery block defined @aaronrobertshaw will also have some insight into supports. |
My take on this is the block.json might define more the "available" units rather than defaults. So as you say, the block could cull units that do not make sense for it at all. Theme.json can then still define which units are actually used or shown. #31822 might provide some further context around units.
At a quick glance of that PR and some of the other gallery code at the time of that commit, I couldn't see where the units defined in block.json were actually used. @glendaviesnz might have some extra details buried deep within his memory 🤞 |
This is also relevant if we want to add units that are specific to font sizes. |
@carolinan Chiming in that I noticed a bug today (6.7.1) where it also doesn't completely work for theme.json + dimensions opting in (this testing was for row/stack/group blocks inside a parent stack) see attached screenshot showing it recognizes dvh/dvw for padding and minimum height, but not for the fixed height value (presumably height>fixed height should pull from the same declaration in theme.json since these are all the Dimensions options pulling from Settings > Spacing >
I had a hard time finding anything about Fixed Height in the Documentation for either Dimensions or Group Block. Research:Following the trail of this units opt-in journey led me here and the PR's that are linked within: I'll leave this in this thread unless anyone thinks I should throw another ticket on the pile of 5,000. 😅 |
Please open a separate issue |
Done! #67750 |
Description
Three core blocks currently has a block support in block.json called units: gallery, navigation, and social links.
The purpose of this block support is undocumented, and it is not in the schema for block.json.
Assuming that the intention was to set the default units that the block uses in different controls, the support is not working.
It is possible that this was working when it was implemented, but has regressed.
For example the navigation block declares:
But the block spacing control has the units px, em and rem.
In the gallery block, units are directly under supports, not under spacing.
But only the spacing control uses units, and they are px, em and rem.
If I update these blocks to for example only use the px unit, there is no change in the editor controls.
If spacing units are also added in theme.json, then the theme.json values are used.
Step-by-step reproduction instructions
Screenshots, screen recording, code snippet
No response
Environment info
WP 6.2-alpha-55147
Gutenberg trunk
Please confirm that you have searched existing issues in the repo.
Yes
Please confirm that you have tested with all plugins deactivated except Gutenberg.
Yes
The text was updated successfully, but these errors were encountered: