-
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
Blocks: Allow the Default Style selector to be hidden. #20620
Conversation
Size Change: +31 B (0%) Total Size: 857 kB
ℹ️ View Unchanged
|
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.
Nice, this is a welcome change, in an example I was working with the extra selector confused things, this makes it cleaner for sure. 👍
A minor edit for the docs to include the default value is true
docs/designers-developers/developers/block-api/block-registration.md
Outdated
Show resolved
Hide resolved
This looks good, but I'm not sure that having it as a new root level setting makes the most sense. There's a few other options I considered:
|
Since this is a new block API let's give it some proper thoughts @WordPress/gutenberg-core |
Personally, I think the default style select control should be moved to the Global Styles UI. |
Giving this some more thought, I agree with @scruffian's point that this isn't really appropriate for a top level setting. I like the idea of putting it in |
799ce62
to
0345223
Compare
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.
Well this definitely looks a lot simpler now!
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 hadn't followed closely to the original implementation in #16465. It doesn't seem clear to me what guidelines a block developer might want to follow when considering whether to allow this option to be presented. Even in the case of the given "Map" block styles, I think it might be reasonable that a user would want to have a consistent default for the blocks they insert.
That said, I also don't feel particularly strongly that this not be within the control of the block to opt out. In that light, the implementation here seems sensible to me.
@@ -716,6 +716,14 @@ attributes: { | |||
alignWide: false, | |||
``` | |||
|
|||
- `defaultStyle` (default `true`): When the style picker is shown, a dropdown is displayed so the user can select a default style for this block type. If you prefer not to show the dropdown, set this property to `false`. |
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.
Noting that the editor setting itself is still marked as experimental:
settings.__experimentalPreferredStyleVariations; |
Which leaves this in an awkward mix of semi-stable support.
Related: #16465
@jorgefilipecosta Do you have a sense whether this is something that will plan to be stabilized? Or at least that even if the setting shape itself changes, the desire for "default style" user control will remain?
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.
@jorgefilipecosta: Pinging you on this question: is there any plan to stabilise this feature?
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.
We still have a considerable amount of work to do on #7551. Allowing the user to change the default styles was just a step.
We also want to allow themes to change default styles #16532.
And we want to allow users to create their block styles from the UI. I think this API should not be stabilized before at least these two follow-ups are merged and tested (as the follow-up work may benefit from a better mechanism to store and pass default styles around the several artifacts we have). So there are no immediate plans for stabilization.
docs/designers-developers/developers/block-api/block-registration.md
Outdated
Show resolved
Hide resolved
I know this would involve a change to the |
If I understand correctly, this is already possible via the At registration-time, it is achieved via the block setting Related: #20620 (comment) |
Of course, I should have read that more closely. Sorry all! I notice there aren't any safeguards against registering multiple defaults, but that's for another day. |
I'm not entirely sure what the deal is with the It would probably be beneficial to formalise that, before it becomes locked in due to general use. |
Co-Authored-By: Marcus Kazmierczak <[email protected]>
e769c12
to
d48cdbc
Compare
@mtias: Can I get your thoughts on this? It's stalled a bit, particularly on what the future of block styles looks like. |
Description
While working on Automattic/jetpack#14852, I came across the Default Style dropdown. I don't think it's applicable to how this block uses styles, it would significantly reduce end user cognitive load if we had an option to hide it.
This PR adds such an option, giving blocks a new
supports.defaultStyle
setting to register with. Setting it tofalse
will remove the default style dropdown.How has this been tested?
Tested against the block in Automattic/jetpack#14852, and against core blocks which don't have this flag set.
Screenshots
A block with custom styles, and the default style dropdown removed:
A block with custom styles, and the default style dropdown kept:
Checklist: