Replace metabox arrows with Dashicon chevrons for greater consistency. #16100
Conversation
|
I do kind of wonder if a half step makes sense. I kind of think no-one but you and me will notice that the dashicon isn't the same as the material chevron. At the same time, it does bug me :D But I also don't want to block this PR as it's a good step towards consistency, so on that note I wouldn't object. But I still wonder, what would it take to make the full step? |
I'm not totally sure. It appeared to me that those controls are basically just inherited from WP-Admin. I think someone would have to rebuild with pure Gutenberg components, which doesn't seem like a huge priority for us at the moment? I wonder if @youknowriad or @noisysocks has some idea (I see they've worked on the Also, @jasmussen, another option would be to swap out the existing chevrons with Material ones in Dashicons itself... we're already using an incongruent one for the back button in fullscreen mode, and I can't think of a great argument for why they should be slightly different. |
There's a larger discussion there, largely summarized in this comment, which suggests mostly that path for WordPress as a whole, Material icons plus dashicons to fill in the gaps. But Dashicons as they are today are incompatible because of the smaller (20x20) pixel grid than Material (24x24). The real solution is of course to refactor out the use of Dashicons in that particular metabox instance, but I would agree that's a larger undertaking. In any case, no real objections, just good to muse about this! :) |
|
In theory, fixing this for reals should just be a matter of changing the So, something like: if ( $current_screen->is_block_editor() ) {
echo '<svg class="toggle-indicator" aria-hidden="true"><path>...</path></svg>';
} else {
echo '<span class="toggle-indicator" aria-hidden="true"></span>';
}(Or maybe you don't need an This would have to be done in Trac and not here in the Gutenberg repo. |
|
I think a good clarifying question here is asking how the project leads see the future of meta boxes? My interpretation was that meta box support in Gutenberg was provided primarily as a way to ease a transition to more Gutenberg-y implementations (e.g. sidebar API, blocks, etc). If that is still the case, they are effectively a deprecated feature and I’m not sure it makes sense to make accommodations and affordances for them. The slight design variations are a reminder that they are not native to Gutenberg, and they can (and will) behave differently from other elements of the interface. |
|
cc. @youknowriad |
This is a fair discussion and good points being raised. I'd agree that they will be deprecated at some future point. But this time is probably a ways off still. For this reason, I would love to see them more aligned to the Gutenberg interface + icons. The quick change to Dashicons chevrons works for me here as providing a bit of consistency in the interim. I'd avoid going to Trac with this in Core. |
|
I guess I'll just voice my objection again — WordPress has a long history of pulling code into the future far beyond its usefulness. With the recent addition of a SlotFill which now allows truly Gutenberg-native panels in the Document Settings panel, there is finally a full end-to-end migration path for custom metaboxes. With this new addition, there is very little justification for someone to use legacy metabox code, and I think making a design affordance for the legacy approach is a mistake. |
I definitely appreciate the sentiment of the objection here, and we definitely want folks to natively implement their custom meta boxes. But from a user's perspective, they generally wouldn't know or care if these boxes are using a legacy approach or not. They look similar enough to the rest of the editor that the inconsistency in the expand/collapse arrows reads as just a design oversight. It's all just a single interface, in the eyes of the user. |
|
A few comments as I see it. Metaboxes are very likely still used by a lot of users in probably many different ways. We still need to continue the support for a few (likely a bunch) years and perhaps find a way to create a better transition of the older code used in the metaboxes to a call it version 2 metaboxes. Go go.... get the new arrows in place for the metaboxes..:) |
|
I also approve of this, and while I understand @chrisvanpatten 's perspective it does look like an unfinished job to the user. @kjellr did anything new happen in the meantime (new UI, icons etc) that should prevent us from merging this? |
|
Size Change: +118 B (0%) Total Size: 842 kB
ℹ️ View Unchanged
|
Yeah, the chevron icon has changed, so the dashicon one is less of a match. The difference is more obvious, but it's still better than what's there today. I'd get some feedback from @mapk or @jasmussen on whether this is an improvement or not. Current:
This PR:
|
|
Thanks for keeping on this. This has been out of mind for me for a while. Since then with some of the G2 efforts, I've been wanting to look at panels, and try to reduce borders and icons whenever possible. I don't have a clear picture of how the sidebar could be refined, but the short is that I would expect it to change further with some of the G2 designs Pablo created in #18667. So we may want to keep this one sitting for a while further :| Alternately — what would it take to fix the problem at the root? Actually use the Icon component, or just bake in the SVGs, in the metabox panels themselves? |
|
Closing this out due to lack of activity and the age of this effort. Feel free to reopen or create a new PR if folks want to continue this work. |
This is a half-step towards closing #15881.
The expand/collapse arrows for custom meta boxes are currently not in sync with the Material chevron icons used in the rest of Gutenberg:
This is because the arrows are Dashicons, brought in via core's
common.css. Since we don't have an iconfont version of the usual expand/collapse arrows we use in Gutenberg, this PR pulls in the closest Dashicon alternatives:The Dashicon chevrons are almost the same as the ones we use. Considering how similar they are (and how small the icons are here), I think it makes sense to switch to these ones until we can implement a more permanent fix.