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 #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.

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

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.

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?

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.

@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.

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.

@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.

@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?

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.

@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.

@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 👍

Seems I'm a bit late to the discussion, but I still would like to ask: wouldn't it be better to have the control be content-oriented instead of device-oriented?
Designing based on device sizes is a bad practice that should be avoided. I think small, medium and large would be a better approach than mobile, tablet and desktop.