Add initial block support for width #26045

stacimc · 2020-10-12T23:47:24Z

Description

Issue #26368: This adds a dimensions block support providing a width selector with default options for 25%, 50%, 75%, and 100% width.

This is an alternative to implementing width as a selector directly on the Button block, implemented here: (#25999)

Changes

Adds a new dimensions block support
Provides default width options using CSS variables, allowing for preset options through theme customization
Updates the Button component to use the new block support

Notes

The width options are nested under dimensions settings and could be expanded to include additional block support options for height
This is a first iteration and could be iterated on to include custom percentage widths as a text entry, or px width support similar to what's implemented in the search block
The support for Button sets the width of the entire component -- no adjustments were made for margins in this iteration, so for example you will find that a 25% width button does not fit on the same line as a 75% width button.

How has this been tested?

Manual testing using the Button block.

Test instructions

Add a Buttons block to a post, with one or more Buttons.
Select a Button
You should see a Width Settings section under the Inspector Controls, with options for 25%, 50%, 75%, 100%.
Toggle a width option and verify that the selected button updates to the correct width. You should see an inline-style added to the block using var(--wp--preset--width--<the width you selected>).
Save the post and view on the frontend.
The same inline styling should be applied in the saved post.

Screenshots

Types of changes

New feature (non-breaking change which adds functionality)

Next Steps

Update tests

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.
I've updated all React Native files affected by any refactorings/renamings in this PR.

First pass attempt at creating a block support for adding a width selector with options for 25, 50, 75, 100 percent width. It is based off the work to add a block support for border radius. The intention is to extend this to include custom percentage widths and px support with a slider in the editor for custom sizing (see Search bar for an example).

When a custom width is selected apply the 'custom-width' className to the block. This is used to key off of for additional block-specific CSS; for example the Button block needs to set its inner component to 100% width for the styling to work correctly.

Nesting width into a dimension setting allows for the addition of related settings (height etc) in the future.

Adding a block support using CSS variables to the Button block causes the inline style to be added to the button's wrapper div as well as the inner anchor tag. This causes Block Invalidation errors for existing posts, as well as for any patterns that use the Button block. These errors are resolved with a deprecation that omits the block support. Once opened in the block editor they migrate cleanly.

Fix up an incorrectly applied rebase.

The use of `useBlockProps` in the Button block was causing all of the block's style attributes to be applied to the button's wrapper div, including color props that were previously applied only to the inner anchor tag. When a Button has both a custom background color and a border radius, this causes and issue where the background color (applied to the wrapper) exceeds the lines of the border (applied to the inner anchor tag). This commit removes style attributes related to the color props from the blockProps before they are applied to the wrapper. This also resolves the block invalidation errors that were previously addressed by a block deprecation, so the deprecation is no longer necessary and is also removed in this commit.

stacimc · 2020-10-20T23:21:29Z

One consequence of implementing the block support with CSS variables in this way is that the style attributes end up getting applied to the outermost element of the block. This causes issues when any block support of this type* is added to the Button block, because the background-color and color styles were previously only applied to the inner anchor tag.

This causes block invalidation errors for Button, and also a bug when a user selects a custom background-color and also applies a border radius to a button. The border-radius is applied to the inner component, and the background-color to the wrapper, causing the color to exceed the lines of the border. I handled this in the Button block by stripping color props from blockProps before applying it to the wrapper.

I tested adding the text-decoration block support (Block Support: Add text decoration block support using CSS variables #26059) and experienced the same issue

aaronrobertshaw · 2020-10-21T04:39:05Z

✨ Nice work @stacimc

This is working as advertised for me.

I have a few minor suggestions that I'll add as inline comments. I also have some thoughts on the stripping of color props before applying the block props to the wrapper but I'll write those up separately.

aaronrobertshaw

Appreciate all the hard work on this @stacimc it is coming along nicely! 🎉

After taking this for a test drive my suggestions fall under three banners:

Trivial comments or wording tweaks
Restructuring it a little to be consistent with the existing Typography tools
Addressing the issue regarding stripping the color props before applying to the wrapper

One consequence of implementing the block support with CSS variables in this way is that the style attributes end up getting applied to the outermost element of the block.

I wonder if we would be better served by moving the application of the button styles and classes to the actual button block itself. This obviously might lead to some failed tests and needing a deprecation. I'm happy for others to weigh in on this one.

At the moment, some of the block's props (border radius and colors) are retrieved and then applied to the inner link component.
We could just apply these to the button component itself and use a couple of CSS styles to inherit these values as needed (overriding the default button link styles)
Once the border radius block support PR is merged that could be opted into for the button block leading to its styles being applied to the button block itself for free.
The button block could be updated to leverage the useColors hook and block support. This would again apply the colors to the button block.
Using the border radius and colors block support would mean we could remove all that code applying those styles manually from the button edit and save scripts.

I've played around with the suggestion above and it worked pretty well for me. It could do with some further exploration though. I'd be happy to help if we all decide to go down that path.

lib/block-supports/dimensions.php

packages/block-editor/src/components/width-control/index.js

packages/block-editor/src/hooks/dimensions.js

packages/block-editor/src/hooks/style.js

packages/block-editor/src/hooks/dimensions.js

paaljoachim · 2020-10-21T13:27:01Z

I do believe we use Width Settings percentage for only images.

Here is an example with using width for columns:

I am thinking the columns approach in relation to width might be better to use with buttons.

Btw did you create a Gutenberg issue so that we can explore to figure out the best approach. It should also have feedback from design? Thanks.

Some docstrings still referred to the block support as just width support, and needed to be updated after refactoring into a larger dimensions feature.

apeatling · 2020-10-21T21:53:17Z

I do believe we use Width Settings percentage for only images.

We also use width percentages on the search block. Also on the Jetpack form block there is a similar setup. I think it's useful for when you want to use a flexbox based arrangement to align buttons into columns using percentages.

Properly register the block support and apply the CSS variable inline styles for dynamic blocks that are rendered in PHP.

Because block supports implemented with CSS variables add styling to the outermost element of a block, this commit updates the Button block to expect styling to be applied at this level, rather than directly setting it on the inner component. This is accomplished by: 1. Updates the CSS so that the inner button will always inherit color, background-color, and border-radius styling that was applied inline to its wrapper. This only happens when a user has selected an option from a block support, so we can reliably override any other styling applied by defaults or the theme. 2. Adds a deprecation for the Button block since styling is now applied differently. 3. Removes the block-specific implementation of Color settings and instead applies the color block support. 4. Temporarily manually applies the border-radius to the wrapper. There is a PR for a border radius block support, which can be used to replace this.

mcsf · 2020-10-23T15:23:49Z

Hi, thanks for your PR. However, implementing this feature as a wide-reaching block-supports feature is premature. Instead, I strongly suggest implementing width control directly in the Buttons block — which is a clear worthwhile use case — and seeing from there if more compelling use cases arise that would then have us generalise this feature.

apeatling · 2020-10-23T21:12:11Z

@mcsf We've been doing a lot of work on adding this kind of support to blocks, and have been directed towards making them "block support" features, see our other PRs:

#26060
#26050
#26059

I'm wondering why width would be different in this case? I can see a number of initial block uses for this, the search block, image and gallery blocks (with expanded options), buttons, and separator blocks off the top of my head.

mtias · 2020-10-26T09:32:21Z

@apeatling the typography tools in the examples above have a better defined shape (the typography object). Width and other dimension controls don't yet, and it's not clear how it might be apply to different blocks, which makes it a bit trickier. We should be using the same components for sure but we can wait a bit until theme.json gives us proper structure to absorb the support. It's fine to add this one just to buttons initially as we collect more use cases.

apeatling · 2020-10-26T16:19:53Z

Thanks for the context! @stacimc Let's push forward with #25999 that adds it only to the buttons block, and we can leave this one on the back burner and see if it helps down the line when things have matured more.

stacimc · 2020-10-26T17:12:43Z

Thanks, that's very helpful. I'm going to update Issue #26368 with that context and further discussion about dimension controls can happen there.

Closing this branch in favor of #25999.

stacimc force-pushed the try/width-block-support branch 10 times, most recently from c1411ca to 8368408 Compare October 19, 2020 20:20

stacimc force-pushed the try/width-block-support branch 2 times, most recently from aeedbf6 to 413d317 Compare October 20, 2020 19:09

Staci Cooper added 10 commits October 20, 2020 12:55

Apply inline styles when width is selected

3ec2348

Adjust CSS for right-aligned buttons in editor

42f2249

Flatten structure of width settings in the style attribute

873fb26

Add tests for block support

c89e0a1

Use CSS variables for block support implementation

8af7de3

Nest width into dimension settings

abed04a

Nesting width into a dimension setting allows for the addition of related settings (height etc) in the future.

Remove file not deleted in rebase

4cfd6f3

Fix up an incorrectly applied rebase.

stacimc force-pushed the try/width-block-support branch from 413d317 to 2b04a57 Compare October 20, 2020 19:58

stacimc force-pushed the try/width-block-support branch from 2b04a57 to bcade7c Compare October 20, 2020 22:28

stacimc marked this pull request as ready for review October 20, 2020 23:34

stacimc requested review from ajitbohra, ellatrix and Soean as code owners October 20, 2020 23:34

stacimc requested review from spacedmonkey, talldan, TimothyBJacobs and youknowriad as code owners October 20, 2020 23:34

aaronrobertshaw requested changes Oct 21, 2020

View reviewed changes

paaljoachim added Needs Accessibility Feedback Need input from accessibility Needs Design Feedback Needs general design feedback. and removed Needs Accessibility Feedback Need input from accessibility labels Oct 21, 2020

Update docstrings to reflect refactor into dimensions feature

6f37465

Some docstrings still referred to the block support as just width support, and needed to be updated after refactoring into a larger dimensions feature.

stacimc mentioned this pull request Oct 21, 2020

Add a block support for dimension settings #26368

Open

stacimc force-pushed the try/width-block-support branch from 4032e7a to 6f37465 Compare October 21, 2020 22:58

talldan added [Block] Buttons Affects the Buttons Block [Type] New API New API to be used by plugin developers or package users. labels Oct 22, 2020

Staci Cooper added 2 commits October 22, 2020 15:12

Apply inline styles for dynamic blocks

ef3379c

Properly register the block support and apply the CSS variable inline styles for dynamic blocks that are rendered in PHP.

stacimc mentioned this pull request Oct 23, 2020

Add width selector for button block #25999

Merged

6 tasks

stacimc closed this Oct 26, 2020

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add initial block support for width #26045

Add initial block support for width #26045

stacimc commented Oct 12, 2020 •

edited

Loading

stacimc commented Oct 20, 2020

aaronrobertshaw commented Oct 21, 2020 •

edited

Loading

aaronrobertshaw left a comment

paaljoachim commented Oct 21, 2020 •

edited

Loading

apeatling commented Oct 21, 2020 •

edited

Loading

mcsf commented Oct 23, 2020

apeatling commented Oct 23, 2020 •

edited

Loading

mtias commented Oct 26, 2020

apeatling commented Oct 26, 2020 •

edited

Loading

stacimc commented Oct 26, 2020

Add initial block support for width #26045

Add initial block support for width #26045

Conversation

stacimc commented Oct 12, 2020 • edited Loading

Description

Changes

Notes

How has this been tested?

Screenshots

Types of changes

Next Steps

Checklist:

stacimc commented Oct 20, 2020

aaronrobertshaw commented Oct 21, 2020 • edited Loading

aaronrobertshaw left a comment

Choose a reason for hiding this comment

paaljoachim commented Oct 21, 2020 • edited Loading

apeatling commented Oct 21, 2020 • edited Loading

mcsf commented Oct 23, 2020

apeatling commented Oct 23, 2020 • edited Loading

mtias commented Oct 26, 2020

apeatling commented Oct 26, 2020 • edited Loading

stacimc commented Oct 26, 2020

stacimc commented Oct 12, 2020 •

edited

Loading

aaronrobertshaw commented Oct 21, 2020 •

edited

Loading

paaljoachim commented Oct 21, 2020 •

edited

Loading

apeatling commented Oct 21, 2020 •

edited

Loading

apeatling commented Oct 23, 2020 •

edited

Loading

apeatling commented Oct 26, 2020 •

edited

Loading