Design tools: Better handling of unset / inherited values

[jameskoster]

There was a lot of discussion on this in https://github.com/WordPress/gutenberg/pull/42173, with no optimal outcome. Consensus was to explore a holistic solution.

The problem

It is possible for styles to be applied to blocks in ways that we cannot programatically detect. Confusion arises when what is printed on the canvas does not seem to match the configuration in the Inspector. As an extreme example take a look at this Group block and its settings:

Clearly text color, padding, background, border, and radius are all being applied. And yet the corresponding tools give no clear indication of this. Indeed many of them suggest they are unset (see: https://github.com/WordPress/gutenberg/issues/37752).

It would be good explore an intuitive design convention we can apply consistently across these controls so that users have a better understanding of what is happening.

Existing patterns

The font-size control attempts to clarify things by communicating it is set to 'default'. But this is confusing because the label is ambiguous – does 'default' mean the default value from global styles, or the default value inherited from whatever stylesheet? In any case a text label may not be a feasible solution since not all controls display their value as text, e.g. color values are illustrated as swatches.

The padding preset control from the PR above attempts a kind of 'indeterminate' state, which is okay. But again I'm not sure how to apply that globally. What does an indeterminate color swatch look like?

I'm not aware of any other controls that attempt to tackle this problem.

---

I think its worth noting that this is a problem that will hopefully self-heal over time, as more theme developers migrate to theme.json and away from custom styles. But until then it would be good to at least explore potential solutions to this problem.

[jameskoster]

I've thought about this a fair bit, and it seems to me that coming up with designs that will entertain the scenario outlined in the OP for every single control is probably not the best way to allocate resources. It would be a large undertaking (for both design and development), and given that this issue is one that should disappear over time, a holistic solution feels like a better way to tackle this.

By far the simplest approach imo, would be to hide local controls when there is no determinate source value. So if you're editing a Group block in a post, and there are no styles for Group in theme.json or global styles, you'd see something like this:

If you add a control – for example font-size – then it appears in the panel with a value set like so:

The value would come from global styles if possible, but if not then a default custom value would be used:

Most importantly, the control never appears as "unset". Instead, "unset" is communicated by the control not being present at all. This idea is inspired by CSS, where classes are able to inherit styles without declaring them.

The main drawback to this approach is that controls you might expect to find on certain blocks by default will often be hidden. For example a paragraph block wouldn't have a font-size control visible by default. A group block wouldn't have a padding control. In both cases you'd need to add the control manually before setting a value. I don't find this to be a big problem personally, but am keen to hear thoughts and feedback on this idea.

[jasmussen]

Thanks for the excellent thoughts outlined here 🙏

The main drawback to this approach is that controls you might expect to find on certain blocks by default will often be hidden.

This feels like a big enough drawback to me. Especially because the indeterminate value as we've been able to test for padding in trunk for the past few weeks, hasn't felt substantially confusing. As more and more values are brought into theme.json, the problem should also shrink, so I'm not sure the value of hiding by default outweighs the downside at this point 🤔

[eidolonnight]

I also encountered this issue with block spacing within a row while using Twenty Twenty-Two. In that case, with the sliders, it's very much not clear that values are unset. The sliders are at their minimum value by default, and the only way to achieve the true minimum spacing is by engaging the slider, moving it to a higher value, and then putting it back to the minimum.

While I too hope that this problem will self-heal over time, I also think that this should fail gracefully in the meantime. Almost any sort of indicator could help communicate to the user "please play with this slider because what you're seeing doesn't match".

[annezazu]

This came up as a point of distraction with the FSE Outreach Program's Site Editor exploration:

Under Styles > Typography > Elements > (choose one) > Line Height, clicking on the “+” will set the value to 0.1 even if a default value exists (eg. 1.5).

It also ties in nicely with various feedback the outreach program has gotten over the many calls for testing. Folks want to know what the default values are, especially when it comes to continued customization. For example, trying to use the font size presets only to find that "medium" is actually smaller than the text they have currently.

[BE-Webdesign]

Most importantly, the control never appears as "unset". Instead, "unset" is communicated by the control not being present at all. This idea is inspired by CSS, where classes are able to inherit styles without declaring them.

Although more and more people using theme.json to set default values would be great. There will still probably be custom styles set in a CSS file for some themes and the ability to unset these values I think is important, as the user may want to experiment with a control, and then undo the changes they made. From what I have seen with the Typography Size selection, it is tricky to unset, where you should just be able to click on the active size to untoggle its value.

[cbirdsong]

I'd like to reiterate how awkward this is in the slider used in spacing presets, where it appears to show "0" as the default when that is not the case, and then if you click on the control it then sets it to actually be 0, with no obvious way to revert. This is extremely unintuitive:

https://user-images.githubusercontent.com/1672206/210586669-79b8099f-3fdf-411b-bb83-c3f4e39eee37.mp4

---

I think its worth noting that this is a problem that will hopefully self-heal over time, as more theme developers migrate to theme.json and away from custom styles.

As more and more values are brought into theme.json, the problem should also shrink, so I'm not sure the value of hiding by default outweighs the downside at this point

I don't think this is feasible to expect. In a complex design, there are too many edge cases to account for unless you want to dumb everything down to fit the system as designed. Just a few that come to mind from CSS I've written:

• For larger font sizes, decrease the font weight (and vice versa)
• In a cover block using a photo or video background, subtly increase the font weight of a variable font by ~50 to make it easier to read
• In an alternate blockquote style (.is-style-whatever registered to the quote or pull quote block), increase the font size and weight of regular text, and further increase the font size and weight of bolded text
• In a gallery, decrease the spacing between images when it contains a lot of images across a lot of columns

These kind of subtle tweaks to design elements are not something that content editors should be routinely expected to make when authoring content (and them doing so would be lead to a ton of inconsistency in the design). They are also not easily expressed using ever more nested JSON objects.

[annezazu]

This came up in the nineteenth call for testing for the FSE Outreach Program:

When adding a background color to my post title, the padding automatically expanded A LOT. I had to scroll down, find Dimensions → Padding and click for it to go back to the normal/original dimensions. I was suprised to see when I went to padding that the dimensions I was seeing didn’t seem to reflect the size of the padding on my title – it was set to minimum; yet when I clicked on minimum, while the slider didn’t move, the size of my background shrank.

In particular, we also need to think about how to display these variables when adding a background color as that inherently adds padding as this issue reflects https://github.com/WordPress/gutenberg/issues/30725

[mrfoxtalbot]

We have multiple examples of this being a recurring pain point in the case of Twenty Twenty-Three, where users have a really hard time figuring out how to remove the margin above the header:

• https://wordpress.org/support/topic/how-to-reudce-whitespace-above-logo/
• https://wordpress.org/support/topic/blank-space-between-header-and-body-issue/
• https://wordpress.org/support/topic/blank-space-above-title/
• https://wordpress.org/support/topic/theme-twenty-twenty-three
• https://wordpress.org/support/topic/white-space-at-the-top-of-the-page-2/
• https://wordpress.org/support/topic/remove-top-padding-from-wp-site-blocks

I have recorded the steps to do this and as you can see, it is not as intuitive as it should:

https://user-images.githubusercontent.com/4452464/234899417-c1f010c3-7461-4db6-9cbc-9629256888cf.mp4

I will add that even if that was fixed and and the controls were visible by default and did not default to empty != 0 , it would still be challenging to figure out where a given gap is coming from.Is it padding, margin or block spacing? Is it coming from the block at the top or the one at the bottom? Is it coming from the parent block or from a child one?

This probably merits a separate issue but I would like to have some "visual aid" to help users identify where the spacing is coming from.

[jameskoster]

Returning to this one in the context of https://github.com/WordPress/gutenberg/issues/49278, and I still believe the best course of action is to hide controls unless the value can be detected programatically.

So when there are no style providers (theme.json, global styles, patterns, etc) the Inspector panels would appear empty:

It's worth considering the potential treatment of default/inherited styles while ideating on this approach:

More context around this can be found in https://github.com/WordPress/gutenberg/issues/49278#issuecomment-1655883528.

[jasmussen]

While I appreciate the simplicity of empty panels when no overrides are set, our fundamental challenge is not just to showcase the set/unset states, but also to provide an intuitive writing flow. While entirely empty panels may be useful for a purely design/layout tool, for someone knocking out a quick blogpost, they might want to select three paragraphs and click once to bump the font-size.

[jameskoster]

That's why the panels would only appear in the empty state when no values can be programatically detected.

Otherwise, assuming the font size is set by some style provider (e.g. global styles) it would appear in the Inspector and the user would be able to change it directly:

https://github.com/WordPress/gutenberg/assets/846565/0809db8b-2bec-4246-8512-65bb77564614

[jasmussen]

Interesting. Might work.

[SaxonF]

What's the difference between this issue and https://github.com/WordPress/gutenberg/issues/49278? If they are a duplicate it sounds like we can break this down in to a few shippable releases:

1. Always show default values in the inspector if we know them
2. Highlight where those styles are coming from
3. If local styles override global then indicate that change with a dot (as seen here) which offers a shortcut to resetting and pushing changes to global.
4. Implement make default/push to global functionality

Is there any other points of clarification we need before moving to dev? Who can help out with this piece to move it forward?

[jameskoster]

This issue was mostly about how to handle unset style properties in the UI. In short: it's confusing how a control like background color communicates an unset/empty value when a background color is clearly being applied somewhere.

A solution for that is captured in the designs shared in 49278. If we proceed with those, this issue can be closed.

[creativecoder]

Another way we could consider handling unset/inherited values is by showing a "computed" style for properties: https://github.com/WordPress/gutenberg/issues/57296

[Sirjazzfeetz]

I think its worth noting that this is a problem that will hopefully self-heal over time, as more theme developers migrate to theme.json and away from custom styles.

Experienced this earlier today with the Astra theme - which is, still hybrid? Inconsistency between state shown in settings and the actual state of page.

[colorful-tones]

Hi folks, We are only one week away from the Beta 1 cut-off date for WordPress 6.6. This issue hasn’t seen any movement in a while, so we (the editor triage leads of the 6.6 release) have decided to remove it from the WordPress 6.6 Editor Tasks project board.

[annezazu]

@colorful-tones as a heads up, what work is ready for this specific overaching issue is here: https://github.com/WordPress/gutenberg/issues/37752 I'm going to add this to the 6.6 board as a "to do" as it's ready for dev and I've been attempting to track down dev help :) (Mamaduka is going to tackle it!).