-
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
Show child layout controls by default #49389
Merged
Merged
Changes from all commits
Commits
Show all changes
2 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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'm sorry I don't understand why we had to change the default values here? Yeah, there's a small potential of changing the UI for existing blocks, but for me "true" makes more sense as default values for all of these.
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 other words, a user of
DimensionsControl
shouldn't have to define the "defaultControls" prop in order to have a working component.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.
If you're worried about the changes for blocks, we can just update the
block.json
of the affected blocks?The other piece of feedback I have is that we should be consistent in behavior between all the
*Panel
component (we have 4 right now I believe)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.
Any thoughts on this? I'm actually not really satisfied that this PR changed the behavior of default controls in one Styles UI component but not the others, I'm also not convinced that this is the right behavior. Global styles are not customizable by the user, so they shouldn't need to pass any "defaultControls" prop, while the "blocks" (block inspector) are the ones that can customize the default controls, so they should be the ones providing a custom value for the defaultControls prop.
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.
It's a good question @youknowriad. When reviewing this one, I quite liked the idea of the panel itself defining the defaults, and then the site editor/global styles as an exception specifying that it wants to display all the controls. In that way, the defaults at the component level follow the expected behaviour in the block editor. But I can see the goal in preferencing things one way or the other.
Either way, I agree that it'd be good to make sure it's consistent across the different panels. If we're to do that, do you have a preference for how to proceed while maintaining displaying the child layout controls by default?
I've also left a similar comment on the styles UI documentation PR (#49720 (comment)) so that these discussions are connected.
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.
The main reason I went with this option was to not change things for third party blocks. Previously, the default was none of the controls would display except for global styles, but the default setting for the controls was to display all. Blocks outside of global styles weren't displaying controls because the defaults were being silently overridden by an empty object, which is non-ideal. But that's how things have been for a while, and if we change the default behaviour now, any custom blocks using these block supports will suddenly have a bunch of controls displaying by default that they didn't have before.
Personally, I'd love to have everything display by default, because having to look for controls in dropdowns is excruciatingly painful UX, but I'm concerned about changing things around for extenders with no warning.
I'm happy to make the same change for the other block supports as long as we're clear this is the way we want to go.
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 agree that it's not idea to change behavior on block authors but maybe we can make some small adjustments as it's not entirely a breaking change, things still work, they may just be hidden or visible. I think a dev note in this case would be cool.
Maybe we should try to make the change with the least disruption to block authors while making sure the default values are decent and consistent across the components. what would that be?
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'd be happy to make them all visible by default all the time, but perhaps best defer to @WordPress/gutenberg-design 😄