-
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
Allow negative values for margin controls #60347
Changes from all commits
84567a6
b3fa79c
5e89477
b790667
5959a63
4d1bba8
da9ba05
e5f328b
1030a29
3903fe1
1af9164
21bed04
6c98a0e
336a9ce
202506d
83d7b95
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -92,6 +92,8 @@ export default function SpacingInputControl( { | |
! isValueSpacingPreset( value ) | ||
); | ||
|
||
const [ minValue, setMinValue ] = useState( minimumCustomValue ); | ||
|
||
const previousValue = usePrevious( value ); | ||
if ( | ||
!! value && | ||
|
@@ -222,13 +224,26 @@ export default function SpacingInputControl( { | |
} | ||
value={ currentValue } | ||
units={ units } | ||
min={ minimumCustomValue } | ||
min={ minValue } | ||
placeholder={ allPlaceholder } | ||
disableUnits={ isMixed } | ||
label={ ariaLabel } | ||
hideLabelFromVision | ||
className="spacing-sizes-control__custom-value-input" | ||
size={ '__unstable-large' } | ||
onDragStart={ () => { | ||
if ( value?.charAt( 0 ) === '-' ) { | ||
setMinValue( 0 ); | ||
} | ||
} } | ||
onDrag={ () => { | ||
if ( value?.charAt( 0 ) === '-' ) { | ||
setMinValue( 0 ); | ||
} | ||
} } | ||
Comment on lines
+234
to
+243
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. For what it's worth, I do think that it's better for UX if you only check for the sign on drag start. It would feel broken if you were dragging in the negative range and then it suddenly disallowed sub-zero dragging in the same drag gesture once you slip back a little over zero. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I did this because then we would be able to drag from a positive to a negative, which is what we are trying to avoid. It would only jump to 0 if on drag stare we were already in the negatives There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The initial logic I suggested on Slack was like this, where the restriction would only kick in if the starting value was non-negative: onDragStart={ () => {
- if ( value?.charAt( 0 ) === '-' ) {
+ if ( value?.charAt( 0 ) !== '-' ) {
setMinValue( 0 );
}
} } It is also more efficient because you won't need the There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I might have not explained myself. We are aiming to avoid people accidentally dragging to negative numbers, only allowing them if you are typing them directly in the input. Dragging should never let you get into the negatives There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes, I get that. My suggestion is specifically about what happens when the value was already negative on drag start. I think you should be able to drag freely until the end of the drag gesture if the drag started from an already negative value. That's just a UX intuition, so feel free to disregard if you feel otherwise! There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Perhaps one approach could be to check in In any case, I think it could be worth tweaking in a follow-up, but in manual testing, the current state of this PR feels good to me. |
||
onDragEnd={ () => { | ||
setMinValue( minimumCustomValue ); | ||
} } | ||
/> | ||
<RangeControl | ||
onMouseOver={ onMouseOver } | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -2,3 +2,8 @@ | |
// This block has customizable padding, border-box makes that more predictable. | ||
box-sizing: border-box; | ||
} | ||
|
||
// We need this so groups with negative margins overlap as expected. | ||
:where(.wp-block-group.wp-block-group-is-layout-constrained) { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Is the doubling-up of class names necessary? Also, should the modifier syntax not be There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Mmmh, the specificity is the same with one or two classes, if we use only the second, I am unsure if that class can be anywhere else but a group block but I prefer to keep it safe. And about the BEM principles, I'm not sure if we are following them or not but that is a class added by the layout code and changing it now is probably more disruptive at this point. |
||
position: relative; | ||
} |
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.
Would this lower bound still make sense if
minimumCustomValue
was > 0?Math.max( 0, minimumCustomValue )
could be more robust in the general case.