Add experimental ResponsiveBlockControl component

[getdave]

PLEASE READ THIS BEFORE REVIEWING 😀

This PR isn't in any way wired up to Block state. Therefore changing the values in the UI doesn't do anything or persist any settings whatsoever.

This is purely a PR for the UI only to allow multiple controls for different viewports only. It is a sub PR of a wider effort to allow the Group Block to define spacing controls (eg: margin / padding). See below for more details.

Description

Sub PR of Adds basic dimension controls to Group Block.

Adds a standardised <ResponsiveBlockControl> component which provides a UI for Block controls that need to have responsive settings.

Features:

• Standardised, accessible markup using fieldset and legend
• Complete control over the rendered controls via render props
• Render prop to render a default control (non-responsive mode)
• Toggle to turn responsive controls on/off
• Render prop to render a Responsive control(s) (responsive mode)

How has this been tested?

I've temporarily hacked and implementation into the core/group Block which utilises <select> inputs and temporary state for demo purposes.

Note that this will be removed before merging.

Screenshots

Default

Responsive (toggled)

Types of changes

New feature (non-breaking change which adds functionality)

Checklist:

• My code is tested.
• My code follows the WordPress code style.
• My code follows the accessibility standards.
• My code has proper inline documentation.
• I've included developer documentation if appropriate.

[karmatosed]

Adding a design review here there are a few points come to mind:

• It struck me why no large option. I found that super interesting to experience. I think that's covered in another PR though Add DimensionControl component #16791 maybe?
• I have to admit it was hard to guess what small/medium would be.
• I can see people wanting to set the spacing themselves. This is where I think we might be getting into a slippery slope of mammoth configurations but I am noting it.
• I wonder if using term mobile is future proof? You use your iPad not just mobile.

[shaunandrews]

Took some time to work up a design.

One thing you'll notice is I've reverse the default state of the Switch to be on by default. Switching it off would show the multiple rows.

An alternative ideas is to list out all available options with a Switch for each row. This tends to work great if we plan to have more than 2 options, but otherwise feels a little busy and overwhelming.

--

I mentioned some related changes to the placeholder value over in #16791

[shaunandrews]

Another consideration here is that its likely we'll have many responsive settings across blocks and even within settings for a single block. For example, consider the need to adjust not only basic spacing (like we have above) but also font-size, or color, or general layout. At some point we may end up with a "mobile" switch for each of these settings. This is going to be problematic.

What we might want to do instead, is have some sort of Switch for the entire editor. Something along the lines of a "mobile mode" or a "tablet mode" that would allow changes to be made to that specific view, without affecting the "desktop mode" display. I realize this is a much larger change than you initial proposed, but I think its the better way of handling the UI.

[getdave]

Took some time to work up a design.

Thanks for much for taking the time here @shaunandrews. It is much appreciated.

I've reverse the default state of the Switch to be on by default. Switching it off would show the multiple rows.

I see why you've done this. Playing devil's advocate here for a second. Does it feel a little odd to be turning something "off" to enable a feature?

...list out all available options with a Switch for each row. This tends to work great if we plan to have more than 2 options, but otherwise feels a little busy and overwhelming.

Nice exploration. I agree this doesn't scale well though.

At some point we may end up with a "mobile" switch for each of these settings. This is going to be problematic.

Yes that could get a little...noisy UI-wise!

What we might want to do instead, is have some sort of Switch for the entire editor. Something along the lines of a "mobile mode" or a "tablet mode" that would allow changes to be made to that specific view, without affecting the "desktop mode" display.

A good idea. I wonder if @youknowriad is aware of any efforts in this area?

I realize this is a much larger change than you initial proposed, but I think its the better way of handling the UI.

I agree although as you've identified it's a lot more complex. @youknowriad @mtias are you able to advise as to whether you feel the direction we're proposing here is suitable or will it be wasted effort in the long run if you have a "mobile mode" in the works?

[mapk]

provides a UI for Block controls that need to have responsive settings.

This seems very related to the responsive block controls that went through several iterations here: #13363

I think we came super close with this particular design from @kjellr : #13363 (comment)

I understand the UI in #13363 is primarily for columns, but can help inform the design behind spacing too hopefully.

[getdave]

@mapk Thanks very much for your feedback.

I think we came super close with this particular design from @kjellr : #13363 (comment)

@mapk This is what I was building on having touched base with @kjellr earlier. However there have been a few iterations since and @shaunandrews has provided some more input.

Are you able to advise how you feel about the designs @shaunandrews has proposed (cc @kjellr )? I'd like to avoid costly refactors in code because it takes a long time. Ideally, I've love ot get consensus from the design before I write any more code here.

Much appreciated.

[mapk]

Are you able to advise how you feel about the designs @shaunandrews has proposed

For sure! Sorry to have let this stall. Regarding @shaunandrews' mockups, I definitely prefer the first concept, so I'll comment on that one specifically.

1. Looking at this, I first thought the dropdown "Small" was a reference to device size due to the label. To curtail this confusion, we repeated a lot of words in the other mockups for Columns.
2. I think there will be an a11y problem with switching out the label of the dropdown when toggling on. This will probably not work well with screen-readers.
3. That second point leads me to think if we move the toggle to the top, and keep the dropdowns below it, that might work better. I'm sure some language would have to be changed to support this, but when toggling the top control, it feels okay to have the bottom controls reflect the change.

[getdave]

@mapk Thanks for this and sorry for the mega delay in responding. I've been away a lot recently.

I first thought the dropdown "Small" was a reference to device size due to the label. To curtail this confusion, we repeated a lot of words in the other mockups for Columns.

I'm not completely clear on what you're recommending we do here to avoid this confusion. I've previously been asked to remove any additional "explainer" text to simplify the UI. I'd love to see/hear more detail here to help ensure I"m on the same page.

I think there will be an a11y problem with switching out the label of the dropdown when toggling on.

I think you're right. The solution should be

• don't add/remove from the DOM - use show/hide
• to set the disabled attribute on the element that has been hidden (or even the hidden attribute) to better semantically communicate the change to screenreaders
• consider which aria roles can communicate a change of focus area

...if we move the toggle to the top, and keep the dropdowns below it, that might work bette

I can do that. I don't think this precludes making the other a11y changes though.

[getdave]

@afercia Regarding this comment, I tried adding fieldset around the fields on a per device basis. However, this leads to a lot of visual and markup duplication of the same term.

See below

Notice how the legend and the label are repeating the same word.

Questions

1. Would you say it's overkill to have a fieldset when there is only a single field (ie: for example, we may not want both margin and padding so it's entirely possible that we'll just have this control for padding).

2. If no to 1, then how would you recommend resolving the duplication of text/term between label and legend?

3. When the toggle is activated how would you recommend changing the focus to the new fieldsets and marking the All as no longer "active"? I was previously adding/removing the fields from the DOM on toggle, but I felt that perhaps that wasn't a very accessible approach. I now retain both fieldsets in the DOM and so I thought perhaps toggling a hidden attribute on the parent fieldset might be the best way of indicating the change of state? You may need to try this out to understand what I'm talking about.

Also, are there any other ways I could look to improve this?

[afercia]

Quoting from #16791 (comment) my understanding, this control is meant to add padding / margin settings to the group block, with the ability to specify this setting for different types of devices. If this is the case, I'd suggest to use <fieldset> and <legend> elements to group the settings based on devices. Pseudo code:

fieldset
    visible legend: All devices
    DimensionControl: Margin
    DimensionControl: Padding
/fieldset
fieldset
    visible legend: Small screen devices
    DimensionControl: Margin
    DimensionControl: Padding
/fieldset
etc.

[afercia]

@getdave I see only now the screenshot and questions before my previous comment 🤦‍♂

Yes, in your example the nested fieldset + legend aren't ideal. That would require to change the HTML structure and the text used for legend / labels.

As general rules:

• the fieldset legend gives a name to the group of controls
• each control should have a meaningful label
• see also https://accessibility.blog.gov.uk/2016/07/22/using-the-fieldset-and-legend-elements/

In the example above I'm not sure the labels for the select are ideal.

• Label = "Desktop/Tablet/Mobile" doesn't tell what the values within the select are about
• semantically, that actually means: "Select a small/medium Desktop" which is confusing
• the selects are meant to set the padding values: they contain padding values therefore they should be labelled "Padding"
• To clarify what this "padding" relates to, the fieldset legend would give context by clarifying it's about "Desktop"
• This makes even more sense when there are multiple selects within the same group (e.g. padding, margin)

Would you say it's overkill to have a fieldset when there is only a single field

It really depends on the text used for the labels.
In that case, the visible label should also clarify what the "padding" is about, e.g.:
<label for...>Padding for desktop devices</label>

It is OK to remove all the fieldsets if each label provides all the necessary information.

When the toggle is activated how would you recommend changing the focus to the new fieldsets

Couple of considerations:

• I'm not sure a switch toggle is the most appropriate control: switch toggles should be used to set a setting that gets immediately saved without the need of submitting. In this case, it justs switches the visibility of a UI section. I'd consider to use a different control in the first place. /Cc @mapk
• I'd move the toggle control (whatever it is) before all the selects. This way, focus can stay on the toggle and the UI after that changes. Users can explore the content after the toggle as they would do normally. Instead, if the UI that changes is placed before the toggle, they won't have a clue something has changed.

[getdave]

@afercia Thanks for your feedback.

Here's a screenshot

Yes, in your example the nested fieldset + legend aren't ideal. That would require to change the HTML structure and the text used for legend / labels.

I agree. So I've removed the fieldsets but kept it open for developers to utilise these when it is most appropriate. The rendering of the control itself if fully in the control of the developer so they can choose to use fieldsets where that makes sense.

It really depends on the text used for the labels.
In that case, the visible label should also clarify what the "padding" is about, e.g.:

I believe the label per device approach is better in this case. As a result I've amended the label text to include a full description as you advise. However, previously design feedback is that including the full text is too visually "verbose". Therefore I suggest a compromise of providing the full text to screen readers whilst providing a shortened version for sighted users. I think with the context of the "Padding" fieldset legend surrounding all the controls it is clear enough that the device names refer to the setting for "padding" for that device.

I'm not sure a switch toggle is the most appropriate control

I'll leave that to you and the design team. @mapk could you confirm a direction for us here please? Much appreciated.

I'd move the toggle control (whatever it is) before all the selects.

Done 👍

[jorgefilipecosta]

I left some comments (some are optional and are just my thoughts), but In general, I think the PR is ready 👍

[jorgefilipecosta]

onIsResponsiveModeChange - this is a callback purely to "notify" the consuming component that the responsive mode has changed to the value provided as an argument (ie: on/off). It doesn't do any setting.

If it does not do any setting, why we have a need to notify it? I think when there is a responsive mode change, the parent must update its state.
If we had a different padding setting per device (one value for small and one for medium), then the user clicks "Use the same padding on all screen sizes." the parent needs to update the values to remove the different settings for small and medium paddings. Otherwise, we start a disconnection between what the UI says, "Use the same padding on all screen sizes." and what is effectively stored.

So It seems like when there is a toggle on the responsive mode, the parent needs to update something probably block attributes. Depending on these attributes, the parent knows if the flag is true or not. If, during the first render, the parent needs to know if responsiveControlsActive is true or false, why can't on future updates the flag the parent passes also be used? That's the reason I think we don't need a local state the parent knows if the toggle is set or not depending on the attributes.

But right now I also not sure on the direction because we don't have storage for these settings yet. Also, I'm not totally inside the problem, so don't treat this suggestion as a blocker we can continue the current approach. When the component is used in practice it will be easier to understand the current path and if needed we can change as the component is experimental.

[rodrigodagostino]

@getdave thanks a lot for your efforts and also for considering my opinion :) I think small screens, medium screens, and large screens is even better than the middle-ground I suggested.
Just wanted to share with you one more little thing: the UI of the spacing panel I've implemented a while ago in my custom blocks.

I know it doesn't really fit the current Gutenberg workflow, but it might be a little helpful in the future.

[aduth]

Same note here about BEM convention as at: #17846 (comment)

Also:

• These classes are only referenced in tests. It's not strictly problematic to do so, but ideally the runtime implementation needn't be conformed specifically to tailor to tests.
• I think in representing this as some sort of on/off state (it either is or isn't "responsive"), we'd not need to refer to this explicitly as "default" but rather as the absence of "responsive". In other words, I'd suggest using modifier class is-responsive for the other condition, and for this one, simply omitting it.

The second point would actually enable us to simplify this implementation, where currently there is code duplication for block-editor-responsive-block-control__group largely because of how this class is assigned. With the above changes, it could become a unified wrapper of:

<div className={ classnames( 'block-editor-responsive-block-control__group', { 'is-responsive': isResponsive } ) } hidden={ ! isResponsive }>

[aduth]

The assignment of hidden here is effectively dead code, because this div is only rendered inside the condition of isResponsive && <div />.

[aduth]

Regarding #16790 (comment) and #16790 (comment) , I have proposed relevant changes at #19738.

[tellthemachines]

Any idea how this snapshot ended up minified? Makes it impossible to review changes to the component 😞

[aduth]

@tellthemachines It's quite likely that because the test is using a string of HTML for the snapshot, it doesn't know how to make sense of the string as markup of elements to break across lines, vs. say a React element tree. I'd agree though that it sort of defeats the purpose of a snapshot if a future maintainer is unable to assess whether changes in the snapshot are sensible.

I'm not sure exactly what our current configuration will support for those snapshots, but I'd wonder if it could be using the DOM element or if we could adapt somehow for the React element to be used. Otherwise, we may ought to avoid using the snapshot altogether and instead assert directly against specific values we're expecting in the markup.