Allow negative values for margin inputs #40464
Conversation
|
Size Change: +67 B (0%) Total Size: 1.23 MB
ℹ️ View Unchanged
|
There was a problem hiding this comment.
Thank you for the modifications @JustinyAhin!
This looks good to me, and seems to work as expected 👍
| } ) { | ||
| inputProps = allowNegativeValues ? { min: -Infinity } : defaultInputProps; |
There was a problem hiding this comment.
@JustinyAhin Won't this overwrite inputProps, making the prop unusable?
There was a problem hiding this comment.
@talldan in which scenario would that happen? Not sure I really understand your question
There was a problem hiding this comment.
Hmmm you have a point @talldan! Apologies, I initially missed this in my initial review.
Should probably be something like this instead:
inputProps.min = allowNegativeValues ? -Infinity : defaultInputProps.min;What do you think?
|
As much as I want negative margin support. I do think we need to consider how a block with a negative margin will interact with those around it in the Editor. It may become extremely difficult to edit, and there are also |
|
Thank you for tackling negative margins @JustinyAhin 👍 Ultimately, I'd love to see negative margins supported and the designs they can unlock realised. At this stage though, I think we might have merged these changes a little prematurely. I agree with @ndiego that allowing negative margins as they are, introduces more potential problems than they solve. There are also a few other minor issues I think needed to have been addressed before merging this PR. With limited testing and explorations so far some of the issues I see include:
Some of the above are obviously trivial and can still be done after the fact. The editor problems though need further exploration. Are we happy with leaving the potentially broken UX in the editor in order to keep negative margins? I'd like to stress supporting negative margins would be great and I personally appreciate the effort put into this but I don't think we should be regressing the editor's UX to achieve it without due consideration. Screen.Recording.2022-04-28.at.3.20.40.pm.mp4 |
This reverts commit a109d31.
|
I opened #40674 to revert this PR if that's what we want to do 👍 |
|
I kindly disagree that this would introduce more problems than it solves. Currently theme and plugin authors have to implement their own solutions because there is no standardized way. This creates more problems in the long run. @aaronrobertshaw in the screen recording, isn’t that the expected behavior? If I was to enter a negative value, I would expect it to work exactly like that. There’s many worse things that users can do to break the page layout very easily. For example align full and align wide. Or the navigation block. It can take users hours to reorganise their block structure, whereas fixing the above issue is a simple matter of removing the negative value from the input. Another thing worth noting is that sometimes negative margins just don’t work. This is not a block editor issue, but CSS in general. At least allowing negative values would work most of the time. Is there anything that can be done to help solve this problem? I know that it’s a deal breaker for many designers. |
|
Thanks @seothemes for taking the time to share your thoughts 👍
The recording also demonstrates that single negative margin values aren't displayed as such in the margin box-control which is not expected behaviour. Whether the overall behaviour shown in terms of block selection was expected or not might be a separate question from whether that behaviour is desirable at the moment. Some initial questions that come to mind around it might be:
I'm sure there'll be a lot of other aspects to consider as we explore how best to add support for negative margins.
Personally, this gives me further pause towards adding another way to break layouts.
This is a good point. My understanding of the general approach in Gutenberg is to try and avoid situations where users are setting values and nothing changes. There are already issues with this in regards to left/right margins depending on the context a block finds itself in. I don't know whether that makes it better or worse with regards to adding negative margins.
There's definitely a demand for negative margin support. I expressed my desire to see it in my earlier comment also. In terms of moving this issue forwards, I think we need to address concerns around how negative margins affect interactions in the editor. Perhaps our best bet is a threaded discussion, to outline what the UX issues are, gather ideas to mitigate them and form a consensus view on where best to place our efforts in generating some proof of concept PRs exploring our ideas. |
|
What a great reply, thank you for describing the challenges so well. I missed the single values part in the screen recording, but that's the important bit. Makes me wonder - should negative values only be allowed on individual sides? What would be the use case of having negative margins on all sides at once? Limiting negative margins to individual sides would help prevent users from breaking layouts.
I don't think z-index is necessary, and would likely overcomplicate things. We don't need to allow for every possible layout, just the basics. I feel like z-index is closer to positioning, and can quickly get out of control. We have z-index controls in Blockify for example, which feels like overkill:
Haha, very good point, and that's the right perspective to have.
Yes, and this would still solve the problem. Themes and plugins should be allowed to do this, whether or not it's added to core. It's just very hard to change and extend from the outside because it's hardcoded. If added to core, maybe require theme support in {
"settings": {
"spacing": {
"negativeMargin": true
}
}
}The new spacing scale does allow for negative values, but that's also applied to padding, which means it's not an option 😢 (#32644 (comment))
I'm not sure how other page builders handle situations where the value has no effect, this goes back to negative margins being a CSS issue, which can't really be solved. Here's how it's done in Webflow for reference:
I guess this topic is bigger than just negative margins. Is the direction of WordPress heading towards no-code, or will it always be "half-code", with the gaps filled by themes and plugins? There seems to be no clear roadmap or intention, unless I'm missing something. |
It may turn out that this would be desired. If negative margins were only allowed for individual sides, we'd need some UI updates regardless. For example, how do we communicate there are different min/max constraints when the control is link/unlinked? How do we avoid confusion and frustration if the user does try to apply a negative margin to all sides?
I'm not sure, however, if we are to solve the issues with negative margins for individual sides, I'd guess we'd be in a reasonable place to allow it for all sides.
It might be worth noting that negative values are allowed within theme.json. This, of course, only helps when styling all of a given block type. If we are needing to allow configuration of margins for individual blocks via the editor, then I'm not sure we can limit it to theme authors after all. This would bring us back to a theme supplying a custom class and CSS to satisfy their specific needs. ...
"styles": {
"blocks": {
"core/group": {
"spacing": {
"margin": {
"top": "-100px"
}
}
}
}
}
It is in some ways and why I believe it was wise to revert this PR and take a moment to work through the issues before we end up having to provide ongoing support to a potentially broken feature. In the lead-up to the 6.1 release, I don't have the bandwidth at the moment to wrangle such a complex topic but if you wish to get some further traction on this, I'd recommend creating a new discussion so broader input and feedback can happen.
There are a number of resources available detailing a roadmap for Gutenberg and WordPress. Whether that is from a long-term view or for the next release. Here are a few you might find interesting: |
|
Thanks again for the very helpful info. Definitely feeling ya on the bandwidth, it's a lot. Appreciate the energy you've already put in. I spent some time on this and came up with a workaround to allow negative margins: negative-margin-gutenberg.movIt's not perfect, negative values need to be entered manually, but that's good in a way. The option is there for designers/developers, but also hidden for beginners. However after doing some testing, I found that negative margins aren't that helpful when it comes to the block editor. Without responsive controls, there's not much that they can be used for. I'm not sure negative margins are the answer. A much better solution would be for core to add a CSS grid block with responsive settings. That would remove the need for negative margins and many other things. Here's a great example https://wordpress.org/plugins/grids/ Below is the code that I'm using for testing negative margins if anyone is interested: import { createHigherOrderComponent } from '@wordpress/compose';
import { addFilter } from '@wordpress/hooks';
addFilter(
'editor.BlockEdit',
'blockify/with-negative-margin',
createHigherOrderComponent( BlockEdit => {
return ( props: blockProps ) => {
if ( supportsNegativeMargin( props?.name ) ) {
const input = document.querySelector( '.components-input-control__input[min="0"]' );
if ( input ) {
input.setAttribute( 'min', '-999' );
}
}
return <BlockEdit { ...props } />;
};
}, 'withMinHeightSettings' )
); |
looks different. not the default gutenberg editor shipped with wp 6.0.2 ?! |
|
@nicmare not sure which version this was on but it still works with 6.1 |
meanwhile with latest wp i have the new interface and can insert negative values which are reflecting in the editor. But when i hit enter or push save button, it gets reset to zero again :-( |
What?
Allow negative values for margin inputs. Fixes #32644
Why?
See #32644 for details.
How?
The PR adds a new
spacingTypeparameter to theBoxControl()function, and allows negative values for the input control in case this parameter is set to "Margin"Testing Instructions