-
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
Image block: Normalize the block toolbar #29205
Conversation
Size Change: +209 B (0%) Total Size: 1.38 MB
ℹ️ View Unchanged
|
Riad my friend, this is so good! 👏 Before: After: The weight this removes from the toolbar is incredible, it's such a better experience: And it also much better helps group sections in relevant categories. The dropdown is offset a bit to the left: But I suspect there isn't any good clean fix for this, and that it's best addressed separately by the effort that also improves it for text buttons. Designwise, this is solid to me! Thank you! |
I think we could consider moving the "A" to the main group before the "replace". What do you think? The icon is not the best it could be. It might be better with a small box around the letter. |
Speaking of, that A is a dashicon. Here's an updated version, in case you end up touching that part:
|
Shouldn't we just update the icon source separately? |
Yes we should: #29212. I realized in doing that, that the icon is really balanced to have a colored bar under it, and works less successfully when used just as a "transform to cover / add text" icon as is done here. Should we make a larger version of the A icon, just for this? Happy to. |
Yes, I think we could use a separate "overlay-text" icon and include the box I mentioned |
That works for me :) |
Cool: #29215 |
I moved the "A" icon in the toolbar but I left the icon itself for your separate PR. |
I think putting zoom, aspect ratio and rotate into one panel is a great start. I'd probably keep apply/cancel separate for now. The whole editing toolbar needs separate love. Here's an older mockup that's beyond the scope of this PR (and probably in need of tweaks): |
f69011d
to
c2ecfbb
Compare
value, | ||
onChange, | ||
controls = DEFAULT_CONTROLS, | ||
isToolbar, |
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.
Do we plan to remove this once we transition?
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 not sure we can, we have a valid use-case for it at the moment: The inspector control of the latest posts block. Also, it might have some impact on third party blocks.
👌 |
@@ -49,6 +50,7 @@ function DropdownMenu( { | |||
menuLabel, | |||
position, | |||
noIcons, | |||
isToolbarButton = 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.
Was this added for convenience? This can already be achieved with this code:
<ToolbarItem>
{ ( toolbarItemProps ) => (
<DropdownMenu toggleProps={ toolbarItemProps } />
) }
</ToolbarItem>
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.
TIL I guess I'll refactor these to avoid the prop :)
Related to #25983
This PR normlizes the toolbar of the image block by following the "meta, block level, inline" order in the block toolbar.
This is the current result
Notes
BlockAlignmentControl
component in addition to the existingBlockAlignmentToolbar
component, the only difference between the two is that one is wrapped with aToolbarGroup
and the other is not. I expect that the more we dive into these normalization, the more we'll see this comes up for all the existing reusable toolbars we have.