-
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
Border Support: Add support for custom border units #33315
Conversation
Also fixes misalignment of border width UnitControl select caused by incorrect line height on style component legend.
Size Change: +5.88 kB (+1%) Total Size: 1.07 MB
ℹ️ View Unchanged
|
@@ -49,7 +50,9 @@ export default function BorderRadiusControl( { onChange, values } ) { | |||
! hasDefinedValues( values ) || ! hasMixedValues( values ) | |||
); | |||
|
|||
const units = useCustomUnits( { availableUnits: [ 'px', 'em', 'rem' ] } ); | |||
const units = useCustomUnits( { | |||
availableUnits: useSetting( 'border.units' ) || [ 'px', 'em', 'rem' ], |
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.
In #33280 (comment) we consolidated all units into spacing.units
so there's no longer a layout.units
. I wonder if we can do the same here.
See this specific thread for more context #33280 (comment) The concerns were that the relation between both wasn't well understood and the implementation of UnitControl
made layout values dependant on spacing values (layout couldn't have values that spacing also had).
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 can change this to spacing.units
if desired. I'm not sure I follow why we wouldn't potentially want a different set of units for borders.
For example, do vh
and vw
make sense for borders? Would a theme author wish to have a different set of available units for borders as opposed to spacing?
(layout couldn't have values that spacing also had).
Unless I'm missing something, is it not that the supplied units had to be a subset of spacing units? That makes sense to me for borders. If you didn't want em
or rem
for spacing, I can see them also not being desired for border units.
From the linked thread, you mention there that units can only be a subset of spacing.units.
This means that what you pass as units can only be a subset of spacing.units
I'm also fine with a desire to simplify the handling and config of units. If the extra flexibility of different border units isn't worth the cost, I'll change this PR accordingly.
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.
After some further testing, the borders behave ok with all units. I also found I'd missed the global styles' border panel units.
Given that, I've taken the opportunity to switch everything to use spacing.units
while updating the global styles panel.
packages/block-editor/src/components/border-radius-control/index.js
Outdated
Show resolved
Hide resolved
One thing I've noticed is this: if |
Description
legend
element so that it doesn't stretch the border width UnitControl's height.How has this been tested?
Manually.
settings.spacing
changeunits
as follows:"units": [ "px", "em" ]
.px
andem
units.Screenshots
Types of changes
Bug fix.
Checklist:
*.native.js
files for terms that need renaming or removal).