Unable to reset only font size from Typography block settings

[Clorith]

Description

When choosing a font size in the new Typography selector, there is no way to return to the default value, without resetting all typography settings.

For comparison, the letter case setting lets you return to the default value by tapping the selected value once more to un-select it.

Initially reported at https://wordpress.org/support/topic/wordpress-5-9-beta-2-cant-reset-font-size/

Step-by-step reproduction instructions

1. Open a post
2. Select a paragraph block
3. In the block settings, choose a font size in the selector
   4.There is now no way to un-select

Screenshots, screen recording, code snippet

No response

Environment info

• WordPress 5.9-RC4

Please confirm that you have searched existing issues in the repo.

Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

Yes

[jasmussen]

Is this flow working for you?

There seems to be a bug with the panel, though, as the "plus" icon should be an ellipsis when there's a property there already, but I could be missing something. CC: @ramonjd @aaronrobertshaw

[aaronrobertshaw]

Thanks for the ping @jasmussen and for submitting the issue @Clorith 👍

There seems to be a bug with the panel, though, as the "plus" icon should be an ellipsis when there's a property there already, but I could be missing something. CC: @ramonjd @aaronrobertshaw

I think there might be some confusion over when the panel's icon should be a plus or a vertical ellipsis.

The icon was changed to include the plus icon in #34107 with the aim to encourage users to explore that menu for additional options when all optional controls are hidden.

This code change illustrates that intent.

The primary use case for this was when the panel's initial state would be empty due to all controls being optional. In the case of the typography panel however the font-size picker is a default control and is shown all the time. As such it doesn't currently impact which icon (plus or vertical ellipsis) is shown.

I'm not sure what the best course of action is here. I can appreciate the desire to encourage exploration of other options within the panel's menu, particularly when they are not displayed by default. In addition to this, neither the plus or the vertical ellipsis icons indicate that the control can be reset via the menu.

This dual-purpose nature of the menu in the ToolsPanel design has been an ongoing point of discussion (example 1, example 2, among others).

Is this flow working for you?

The ability to reset only the font-size works for me. I believe the issue here is the assumed knowledge of the panel's design as mentioned above.

My suggestion would be to close this issue and open one specific to improving the UX of the ToolsPanel.

[Clorith]

That's not a very discoverable route if I have to hit the plus (to me indicating "add a new field"), then hitting the minus next to the attribute i want to clear.

For comparison, if you add the Letter Case attribute, you can click the same value twice to un-select it, which is a much more discoverable, and even an established pattern, in selection-scenarios.

I'm still thinking this is its own bug, and not part of an overarching ToolsPanel UX overhaul, as the behavior differs between the elements with the same kind of control.

[aaronrobertshaw]

That's not a very discoverable route if I have to hit the plus (to me indicating "add a new field"), then hitting the minus next to the attribute i want to clear.

I agree. The discoverability of this could be improved and the use of the plus icon refined. Perhaps it would be better for it to only be used in place of the vertical ellipsis when the panel would be completely empty. cc @ramonjd for thoughts

My understanding of why the reset functionality was moved to the items within the panel's menu, is that as we got more and more controls available in the sidebar it became overly cluttered with reset buttons. For a control that could be toggled off without the need for a separate reset button, the menu item should be just an extra method of resetting the control's value.

For comparison, if you add the Letter Case attribute, you can click the same value twice to un-select it, which is a much more discoverable, and even an established pattern, in selection-scenarios.

The difference between the underlying components for the font-size picker and letter case controls do highlight the problem you are describing.

The font-size picker is more than just the toggle group, which is essentially a radio button group under the hood hence not being able to deselect. It also needs to handle possibly complex CSS values, long lists of preset font-size options, or custom values. This means a font-size selection might have been made via the custom value field or select control (depending on font-size presets) and couldn't be toggled off by deselecting something back in the toggle group view (if available).

In contrast, the letter-case control is simple and its possible values are pretty static allowing for the ability to toggle a selection off.

I believe @ntsekouras would know more about the reasoning behind the current iteration of the font-size picker as well as all the tricky edge cases it must withstand.

Perhaps we could rename this issue and update its description to better reflect the problem being discussed?

As it stands currently, we can reset only the font size from the typography block settings.

[ntsekouras]

I agree with all of you that the discoverability/handling of reset could be improved. In general we should aim for consistency and as far as I know the plan is to also change the other control like letter case to use the same internal component (ToggleGroupControl) with font size picker.

The font-size picker is more than just the toggle group, which is essentially a radio button group under the hood hence not being able to deselect.

I don't believe there would be any problems regarding the font size control's values, but this comes down to the ToggleGroupControl that's being used. I'm not aware of any accessibility issues that may exist with having a radio group 'deselect' as an option or some other implication but I'd like the thoughts of @ciampo or @mirka about this.

[aaronrobertshaw]

I know the plan is to also change the other control like letter case to use the same internal component (ToggleGroupControl) with font size picker.

I was aware of this being raised previously and at the time being dismissed (at least temporarily) because of issues that radio button groups introduce. It would be good if the ToggleGroupControl could allow the toggle off behaviour out of the box and therefore be used more widely in these controls as proposed. Even if that means conditionally not using the RadioGroup component internally.

I don't believe there would be any problems regarding the font size control's values, but this comes down to the ToggleGroupControl that's being used.

My comments regarding the values and presets were meant more to indicate that the font-size picker is more than just a toggle group control and so depending on how the picker is currently being displayed you might not have the toggle group to even toggle off as a means of resetting.

I'm not aware of any accessibility issues that may exist with having a radio group 'deselect' as an option or some other implication

I was of the impression that once a radio group selection had been made, normal user interaction couldn't toggle off any selection. Also, our RadioGroup component's readme states that it should have a default option already selected which we can't do without adding extra options to the control and also gaining access to merged theme.json and global styles within the block editor.

I'm likely missing something that others working in this area have already considered so happy to defer.

[ciampo]

Thank you for the ping!

To me this is an expected consequence of the switch to the ToolsPanel UX pattern (which caused the removal of the Reset buttons), and I appreciate that it may be counter intuitive for users.

Regarding the ToggleGroupControl component — as stated by @aaronrobertshaw, it uses a RadioGroup internally, which means that it's not possible to deselect an option by clicking on it again (I'm also reluctant to change the ToggleGroupControl implementation).

The correct solution for me would be to display the default option as preselected — although it looks like it may be problematic:

which we can't do without adding extra options to the control and also gaining access to merged theme.json and global styles within the block editor.

Another alternative (which I don't really like, since it'd be quite hacky) is to add another option to the ToggleGroupControl called "reset" or "default" which unselects the value — but again, far from ideal.

Otherwise, we could look into refining the ToolsPanel UX further to make it more clear that it can be used to reset values

[ciampo]

Another thing that came to mind — the font size picker can also display a dropdown instead of the ToggleGroupControl and an input field (in case of custom values), and therefore fixing ToggleGroupControl alone wouldn't probably be enough.

[ntsekouras]

Another thing that came to mind — the font size picker can also display a dropdown instead of the ToggleGroupControl and an input field (in case of custom values), and therefore fixing ToggleGroupControl alone wouldn't probably be enough.

There is another way to 'reset' the other controls - for other inputs we can clear the input value, and in select controls we provide a default option.

(I'm also reluctant to change the ToggleGroupControl implementation).
we could look into refining the ToolsPanel UX further to make it more clear that it can be used to reset values

Having said that, I agree with the above two points about what we should do.

[ramonjd]

The icon was changed to include the plus icon in #34107 with the aim to encourage users to explore that menu for additional options when all optional controls are hidden.

Thanks for the ping and the very neat summary @aaronrobertshaw.

I can confirm this was the original intention: to attempt to highlight that there are more controls available within the Tools Panel dropdown, other than those that are displayed by default.

If the plus sign is causing confusion, especially with the semantic opposition to the minus sign, then maybe that's a "sign" that we should revisit.

Perhaps it would be better for it to only be used in place of the vertical ellipsis when the panel would be completely empty.

Great idea. It's still possible that a block will not declare any default controls in "__experimentalDefaultControls" in its block.json so, barring any bespoke slot fills, the panel would start off empty.

Jan-27-2022.12-06-37.mp4

I will throw up a PR to do this so folks can test drive it.