Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update the buttons block to use the new color support flag. #21266

Merged
merged 7 commits into from
Apr 9, 2020

Conversation

youknowriad
Copy link
Contributor

@youknowriad youknowriad commented Mar 30, 2020

This PR does a lot of things:

  • Refactors the buttons block to use this new hook.
  • Remove the div wrapper for the button block (impacts themes).
  • Uses the lighterBlockWrapper flag for the button block.

Notes

  • This needs dev notes, deprecations...

@youknowriad youknowriad self-assigned this Mar 30, 2020
@youknowriad youknowriad added [Block] Buttons Affects the Buttons Block [Type] Code Quality Issues or PRs that relate to code quality Needs Design Feedback Needs general design feedback. labels Mar 30, 2020
@github-actions
Copy link

github-actions bot commented Mar 30, 2020

Size Change: -315 B (0%)

Total Size: 889 kB

Filename Size Change
build/block-library/editor-rtl.css 7.21 kB -14 B (0%)
build/block-library/editor.css 7.21 kB -14 B (0%)
build/block-library/index.js 110 kB -285 B (0%)
build/block-library/style-rtl.css 7.42 kB -1 B
build/block-library/style.css 7.43 kB -1 B
ℹ️ View Unchanged
Filename Size Change
build/a11y/index.js 1.02 kB 0 B
build/annotations/index.js 3.4 kB 0 B
build/api-fetch/index.js 3.79 kB 0 B
build/autop/index.js 2.58 kB 0 B
build/blob/index.js 620 B 0 B
build/block-directory/index.js 6.03 kB 0 B
build/block-directory/style-rtl.css 760 B 0 B
build/block-directory/style.css 760 B 0 B
build/block-editor/index.js 103 kB 0 B
build/block-editor/style-rtl.css 10.2 kB 0 B
build/block-editor/style.css 10.2 kB 0 B
build/block-library/theme-rtl.css 669 B 0 B
build/block-library/theme.css 671 B 0 B
build/block-serialization-default-parser/index.js 1.65 kB 0 B
build/block-serialization-spec-parser/index.js 3.1 kB 0 B
build/blocks/index.js 57.5 kB 0 B
build/components/index.js 195 kB 0 B
build/components/style-rtl.css 16.6 kB 0 B
build/components/style.css 16.5 kB 0 B
build/compose/index.js 6.21 kB 0 B
build/core-data/index.js 10.7 kB 0 B
build/data-controls/index.js 1.04 kB 0 B
build/data/index.js 8.23 kB 0 B
build/date/index.js 5.36 kB 0 B
build/deprecated/index.js 772 B 0 B
build/dom-ready/index.js 569 B 0 B
build/dom/index.js 3.05 kB 0 B
build/edit-navigation/index.js 2.75 kB 0 B
build/edit-navigation/style-rtl.css 279 B 0 B
build/edit-navigation/style.css 280 B 0 B
build/edit-post/index.js 92.9 kB 0 B
build/edit-post/style-rtl.css 12.3 kB 0 B
build/edit-post/style.css 12.3 kB 0 B
build/edit-site/index.js 10.1 kB 0 B
build/edit-site/style-rtl.css 5.02 kB 0 B
build/edit-site/style.css 5.02 kB 0 B
build/edit-widgets/index.js 7.17 kB 0 B
build/edit-widgets/style-rtl.css 3.74 kB 0 B
build/edit-widgets/style.css 3.73 kB 0 B
build/editor/editor-styles-rtl.css 428 B 0 B
build/editor/editor-styles.css 431 B 0 B
build/editor/index.js 42.8 kB 0 B
build/editor/style-rtl.css 3.49 kB 0 B
build/editor/style.css 3.49 kB 0 B
build/element/index.js 4.44 kB 0 B
build/escape-html/index.js 733 B 0 B
build/format-library/index.js 6.95 kB 0 B
build/format-library/style-rtl.css 502 B 0 B
build/format-library/style.css 502 B 0 B
build/hooks/index.js 1.93 kB 0 B
build/html-entities/index.js 622 B 0 B
build/i18n/index.js 3.57 kB 0 B
build/is-shallow-equal/index.js 710 B 0 B
build/keyboard-shortcuts/index.js 2.3 kB 0 B
build/keycodes/index.js 1.7 kB 0 B
build/list-reusable-blocks/index.js 2.99 kB 0 B
build/list-reusable-blocks/style-rtl.css 226 B 0 B
build/list-reusable-blocks/style.css 226 B 0 B
build/media-utils/index.js 4.84 kB 0 B
build/notices/index.js 1.57 kB 0 B
build/nux/index.js 3.01 kB 0 B
build/nux/style-rtl.css 616 B 0 B
build/nux/style.css 613 B 0 B
build/plugins/index.js 2.54 kB 0 B
build/primitives/index.js 1.5 kB 0 B
build/priority-queue/index.js 789 B 0 B
build/redux-routine/index.js 2.84 kB 0 B
build/rich-text/index.js 14.5 kB 0 B
build/server-side-render/index.js 2.54 kB 0 B
build/shortcode/index.js 1.69 kB 0 B
build/token-list/index.js 1.28 kB 0 B
build/url/index.js 4.01 kB 0 B
build/viewport/index.js 1.6 kB 0 B
build/warning/index.js 1.14 kB 0 B
build/wordcount/index.js 1.17 kB 0 B

compressed-size-action

__experimentalLinkControl as LinkControl,
} from '@wordpress/block-editor';
import { rawShortcut, displayShortcut } from '@wordpress/keycodes';
import { link } from '@wordpress/icons';

const { getComputedStyle } = window;

const applyFallbackStyles = withFallbackStyles( ( node, ownProps ) => {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jorgefilipecosta What this fallback styles for?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It was used to compute the colors the button contained when no colors were explicitly assigned than the colors were used for contrast checking.

@youknowriad youknowriad force-pushed the try/support-gradient-color-flg branch from fefd666 to 96dd0ab Compare March 31, 2020 10:44
@youknowriad youknowriad marked this pull request as ready for review March 31, 2020 10:54
@youknowriad
Copy link
Contributor Author

@jasmussen do you know why we had a "div" wrapper around button blocks?

@jasmussen
Copy link
Contributor

do you know why we had a "div" wrapper around button blocks?

Are you referring to this one?
https://github.com/WordPress/gutenberg/pull/21266/files#diff-5ddfa233aa5293aedee4cdbb53926ef9L196

I don't actually know, but I can't see why it would be necessary.

@youknowriad
Copy link
Contributor Author

@jasmussen yes, there's the same on frontend too.

Copy link
Member

@jorgefilipecosta jorgefilipecosta left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi Riad, awesome work here things worked well in my tests.
I left some comments the more important ones are related to inheritance. That part will be challenging.

packages/block-editor/src/hooks/color.js Outdated Show resolved Hide resolved
...localAttributes.current?.style,
color: {
...localAttributes.current?.style?.color,
gradient: value,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is the reason for making gradient attribute child of color and not making it a "sibling" of color?

Copy link
Contributor Author

@youknowriad youknowriad Apr 6, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

because it's kind of related to the backgroundColor in terms of UI..., but I don't mind changing it. Not sure what's best.

};
};

const onChangeGradient = ( value ) => {
Copy link
Member

@jorgefilipecosta jorgefilipecosta Apr 6, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if it would make sense to include this logic inside PanelColorGradient and avoid the need for effect. E.g: include a onStyleChange that when passed makes the component update the keys in a style attribute?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd love a single onChange for both onColorChange and onGradientChange instead of two sequential calls (I don't know if that's what you're talking about?)

__experimentalLinkControl as LinkControl,
} from '@wordpress/block-editor';
import { rawShortcut, displayShortcut } from '@wordpress/keycodes';
import { link } from '@wordpress/icons';

const { getComputedStyle } = window;

const applyFallbackStyles = withFallbackStyles( ( node, ownProps ) => {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It was used to compute the colors the button contained when no colors were explicitly assigned than the colors were used for contrast checking.

packages/block-library/src/button/deprecated.js Outdated Show resolved Hide resolved
packages/block-library/src/button/save.js Show resolved Hide resolved
packages/block-library/src/button/style.scss Outdated Show resolved Hide resolved
@youknowriad youknowriad force-pushed the try/support-gradient-color-flg branch from 5c7f989 to cb39108 Compare April 8, 2020 10:58
@youknowriad
Copy link
Contributor Author

@nosolosw @jorgefilipecosta I updated the PR to use the inline style styles (like before) solving the inheritance issue.

I also restored wp-block-button__link className on the button wrapper to attempt to diminish the BC issues themes might have due to the removal of the button div wrapper.

That said, you can see that in 2020, the palette colors don't seem to work properly on the editor due to a specificity problem (work well on the frontend).

On 2019, we have the palette issue mentioned here #21428 (comment)

On themes without editor styles, everything works as expected.

@youknowriad youknowriad added the Needs Dev Note Requires a developer note for a major WordPress release cycle label Apr 8, 2020
Copy link
Member

@jorgefilipecosta jorgefilipecosta left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi, @youknowriad thank you for the changes, the inheritance problems seem fixed.
I just noticed a small regression on the contract checking:
Tested in: Twenty Seventeen
I added a buttons block.
I selected a gradient as background e.g: from black to black (default color text is white).
I saw a contrast warning.

I guess contrast checking should not be enabled when a background gradient is selected?

@youknowriad
Copy link
Contributor Author

Thanks for the review and good catch. I disabled the contrast checking when a gradient is selected. I also extracted the API in #21481 to land it first

Copy link
Member

@jorgefilipecosta jorgefilipecosta left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The issue was fixed in my tests 👍

@youknowriad youknowriad changed the title Implement gradients support in the colors hook and apply it to the Buttons block Update the buttons block to use the new color support flag. Apr 8, 2020
@jasmussen
Copy link
Contributor

So happy to see the lighter DOM and global styles happen. This is a PR that needs to land.

I just tested a recent 2019 patch which fixes many of the issues that have happened with it, so I'm on the "latest version", so to speak, and I'm seeing some issues with that theme. In master:

Screenshot 2020-04-09 at 07 51 03

In this branch:

Screenshot 2020-04-09 at 07 50 35

And this is the frontend, and therefore presumably what the button should look like:

Screenshot 2020-04-09 at 07 52 06

This appears to be because of some rules in the editor style that target the button directly. These obviously need to be updated:

.wp-block-button:not(.is-style-squared) .wp-block-button__link {
    border-radius: 5px;
}
.editor-styles-wrapper .wp-block-button .wp-block-button__link {
    line-height: 1.8;
    font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", "Roboto", "Oxygen", "Ubuntu", "Cantarell", "Fira Sans", "Droid Sans", "Helvetica Neue", sans-serif;
    font-size: 0.88889em;
    font-weight: bold;
}

Absent that rule, the default styles are inherited and shown:

.wp-block-button {
    border: none;
    border-radius: 28px;
    box-shadow: none;
    cursor: pointer;
    display: inline-block;
    font-size: 18px;
    margin: 0;
    padding: 12px 24px;
    text-align: center;
    text-decoration: none;
    overflow-wrap: break-word;
}

So yeah, there's breakage. But IMO it's worth it, because it means the editor itself can inherit identical styles to the frontend.


Almost certainly unrelated to this particular PR, as we continue to add customization options to blocks, the default styles definitely need revisiting. It's a little weird that the default button block starts rounded and with a border-radius set to zero:

radius

As seen in that GIF there are a number of issues:

  • The border radius should actually read <unset>, OR the button should not be rounded.
  • The dropdown to select default style, what does that do? It doesn't appear to do anything.
  • The outline style, I wonder should it actually show a background when you select a background color? I would have imagined the stroke itself receiving the background color.

Let me know which of these to ticket separately.

@youknowriad
Copy link
Contributor Author

The dropdown to select default style, what does that do? It doesn't appear to do anything.

That's unrelated, it just saves the "default" style variation for the block, next time you insert the block, it will have that variation by default. I believe there are some UX explorations to improve this on separate issues.

The outline style, I wonder should it actually show a background when you select a background color? I would have imagined the stroke itself receiving the background color.

That's because applying the background color, applies the backgroundColor CSS property, I thought it was the same before but maybe the removal of the wrapper had an impact on its behavior, I'll have to check.

@youknowriad
Copy link
Contributor Author

I took a look at the outline style variation and it seems to work in a similar way on master, which is IMO consistent, you're applying a background color not a "theme color" or something like that.

@youknowriad
Copy link
Contributor Author

The border radius issue is also a bug already present on master, I reopened this issue to track it #17596

@jasmussen
Copy link
Contributor

I do think it dilutes the outline version. But because it's clearly unrelated to this PR, totally good to disregard entirely :)

Thanks for opening the radius ticket!

@youknowriad
Copy link
Contributor Author

I do think it dilutes the outline version

I wonder if it's better to have a border color instead of a style variation personally, it's clearer for the user.

@jasmussen
Copy link
Contributor

Possibly yes. Though I do think an "outlined button" is something that's good to have a thing for — and a class attached to.

@youknowriad youknowriad merged commit cee6439 into master Apr 9, 2020
@youknowriad youknowriad deleted the try/support-gradient-color-flg branch April 9, 2020 16:08
@github-actions github-actions bot added this to the Gutenberg 7.9 milestone Apr 9, 2020
@youknowriad
Copy link
Contributor Author

I merged this, I'll try to add a note about the markup change for the next Gutenberg release.

@kjellr
Copy link
Contributor

kjellr commented Apr 9, 2020

This appears to be because of some rules in the editor style that target the button directly. These obviously need to be updated

Started a ticket for this here: https://core.trac.wordpress.org/ticket/49863

@skorasaurus
Copy link
Member

skorasaurus commented Apr 13, 2020

I was pleasantly surprised to see that one of the containers 'button' block has been removed in this commit.

this should increase improve accessibility issues by using proper, semantic html of just using an 'a' and improves compatibility with existing themes also to most themes who have button-like class directly applied to the div, as discussed in #14121
(this PR does not solve #14121)

On second thought, I would keep in mind that developers may initially try to go to the button block for actions of the traditional button (submitting a form, toggling user-defined settings on a page, etc).

@ramonjd
Copy link
Member

ramonjd commented Apr 22, 2020

Remove the div wrapper for the button block (impacts themes).

Just a quick question.

This change impacts a lot of our themes. See: #21747

Were there any plans to make it backwards compatible for folks already running these themes?

This needs dev notes, deprecations...

It would be great to have these available as soon as possible, or before these PRs are merged into master. Whatever your workflow dictates.

Thanks a lot!

@mtias mtias mentioned this pull request May 29, 2020
82 tasks
@ellatrix ellatrix mentioned this pull request Jul 3, 2020
12 tasks
@youknowriad youknowriad removed the Needs Dev Note Requires a developer note for a major WordPress release cycle label Jul 16, 2020
This pull request was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Block] Buttons Affects the Buttons Block Needs Design Feedback Needs general design feedback. [Type] Code Quality Issues or PRs that relate to code quality
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants