Enable opacity control (transparency) in blocks that support background color #25421

cpapazoglou · 2020-09-17T15:05:31Z

Description

Enables passing disableAlpha={ false } to PanelColorGradientSettings component of any block which in turn allows for transparency (alpha) in that color.
Enables transparency in backround-color of:
cover, button, paragraph, heading, list

How has this been tested?

Add a cover block
Open Block Settings
Go to Overlay and select custom color
You should see a transparency (alpha) slider. Pick a color and set transparency < 1
The change should be visually depicted to the block in the block editor
Preview the post
The change should be visually depicted in the frontend

Screenshots

Before	After

In Action

Types of changes

New feature

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.

cpapazoglou · 2020-09-18T13:03:45Z

I am not sure whether the failing tests are related or how I can fix them? Any help will be appreciated!

youknowriad · 2020-09-21T08:47:38Z

I think this could be cool to support but since today we save colors in the hex format, I'm not sure if this has impact on backward compatibility or not. (validation...)

cpapazoglou · 2020-09-21T09:07:25Z

I think this could be cool to support but since today we save colors in the hex format, I'm not sure if this has impact on backward compatibility or not. (validation...)

Thanks @youknowriad for chiming in! That is a valid point! I just tried creating a block in the master branch and then edited it in the current branch without any problems. Since the color type (hex/rgb) is changed when onChangeComplete it doesn't seem that we are going to have an issue.

Even doing the opposite, creating a block with alpha and then moving to a branch that doesn't support alpha, didn't produce any errors. It fallbacked to hex.

jasmussen · 2020-09-21T09:32:35Z

I like this initiative a lot, just recently I was working on a mockup of an improved Cover block toolbar that doesn't change quite as much between color-only and media states. As part of that, it felt natural to add an opacity control to the color block, because there is when the color is used as an image overlay. Work in progress:

This also touches on Riad's comment:

I think this could be cool to support but since today we save colors in the hex format, I'm not sure if this has impact on backward compatibility or not. (validation...)

In that vein, instead of changing the RGB color to be RGBa, is it possible to refactor the cover block to use RGB plus an opacity instead? I know this is a bigger change, but it would bring some consistency between the color-only version and the media versions of the cover blocks.

aristath · 2020-09-21T09:45:11Z

There have been multiple attempts in the past to enable this, all of them got blocked by one thing or the other. I hope this time we make it happen.

This PR will expose the alpha picker to users and I'm not entirely sure it has been properly reviewed for a11y... I added the needs-a11y-feedback tag.

jasmussen · 2020-09-21T09:51:26Z

This PR will expose the alpha picker to users and I'm not entirely sure it has been properly reviewed for a11y... I added the needs-a11y-feedback tag.

There's already an opacity picker if you have an image background. And there's also an alpha picker for each gradient step, if you choose a gradient background. Fine to review either of those if they haven't already been, but it shouldn't be new, unless I'm missing something.

aristath · 2020-09-21T10:06:11Z

There's already an opacity picker if you have an image background. And there's also an alpha picker for each gradient step, if you choose a gradient background. Fine to review either of those if they haven't already been, but it shouldn't be new, unless I'm missing something.

Ah you're right, I hadn't noticed the ones in gradients, I only remembered the ones for background-images... and those opacity controls are not part of colorpickers (which is why I had the impression these here might need an OK from an a11y standpoint) 👍
In that case I think we can remove the a11y-feedback tag 👍

ItsJonQ

@cpapazoglou Awesome! Thanks for working on this one. 👍 from me from a code implementation perspective :).

Note: There's some input value rendering funkiness within the ColorPicker (for alpha). That is an existing issue and not related to this PR.

jasmussen · 2020-09-21T18:26:17Z

Worth just being sure about this one before we merge: #25421 (comment) — I think there's a way to refactor cover to not need the change to rgba as noted in #25421 (comment).

cpapazoglou · 2020-09-22T07:22:09Z

I think there's a way to refactor cover to not need the change to rgba as noted in #25421 (comment).

This would require:

removing the background-color from the block
adding a new child element that will have the rgb background-color and the opacity
a lot amount of work to make it work for the rest of the blocks too

If we need to consolidate things, I would remove the opacity setting from media and let only the rgba for media / background-color / gradient

cpapazoglou · 2020-10-02T17:06:01Z

@jasmussen I pushed 2afee4d that refactors cover block to allow background-color and gradient with opacity. I believe this is what we are after?

If yes, I will have to apply some changes for the frontend too!

I think there's a way to refactor cover to not need the change to rgba as noted in #25421 (comment).

This would require:

removing the background-color from the block

adding a new child element that will have the rgb background-color and the opacity

a lot amount of work to make it work for the rest of the blocks too

If we need to consolidate things, I would remove the opacity setting from media and let only the rgba for media / background-color / gradient

jasmussen · 2020-10-05T08:14:47Z

@jasmussen I pushed 2afee4d that refactors cover block to allow background-color and gradient with opacity. I believe this is what we are after?

This is what I see:

And yes, I think this is what I'm after! We entirely avoid having to use rgba, and the featureset seems to be the same. It also brings consistency to how gradient overlays are created, so it's the same UI. That's a real win. Nice work.

As you can see from the GIF, there's a weird thing that happens to the opacity when it hits 50% exactly. I'm not entirely sure what happens there. I would also love a sanity check by @jorgefilipecosta as I recall he worked on this.

Thank you!

jorgefilipecosta

Nice work here thank you for all the changes applied the alpha picker seems to be working well and it seems a safe change to me. I just left a minor suggestion related to onChangeComplete handling.

Regarding the changes for cover, in my tests things seem to be working as expected on the frontend. There were some discussions in the past related to moving cover image background to a dom element if we in fact are going to do that it may make sense to do the change we are doing here to cover and that change together to avoid multiple deprecations and more importantly multiple CSS support for old versions which on the cover block is already complex.

jorgefilipecosta · 2020-10-12T19:36:59Z

packages/components/src/color-palette/index.js

-			disableAlpha
+			onChangeComplete={ ( color ) =>
+				onChange(
+					disableAlpha ? color.hex : rgba( color.hex, color.rgb.a )


I think when alpha is not set we should store the colors in hexadecimal, even if picking alpha is enabled. The onChange condition should not be based on alpha being enabled or not but on alpha being set or not.

jorgefilipecosta · 2020-10-12T20:58:21Z

packages/block-library/src/cover/style.scss

@@ -10,6 +10,7 @@
 	justify-content: center;
 	align-items: center;
 	padding: 1em;
+	background-color: transparent;


These style changes are causing problems for existing cover blocks.
In all cases where we have an image or video background and an overlay color or gradient. With these changes, the overlay color and gradients stop appearing on the frontend of the websites.

To reproduce one can add some cover blocks select image, video backgrounds, and overlay color /gradients save the post and see it on the front end. The overlays will not be there.

jorgefilipecosta · 2020-10-12T21:37:57Z

packages/block-library/src/cover/edit.js

@@ -515,14 +516,24 @@ function CoverEdit( {
 						src={ url }
 					/>
 				) }
-				{ url && gradientValue && dimRatio !== 0 && (
+				{ overlayColor.color && ! gradientValue && dimRatio !== 0 && (
+					<span


We are adding this span element to the edit function but not to the save markup that the block produces and is shown on the frontend. Is the span also required on the frontend? If yes, I guess we may need to add it to the save function, but that is complex:

It will require CSS that works with the new block markup and with the old one.

It will require block deprecations.

Is there any way we can accomplish the same without requiring the additional span?

A possible way would to when there is an opacity value set, and there's a color change, we would add the alpha value to the color attribute even though in the color picker alpha does not appear. It is a little bit hacky and makes one attribute depend on the other, but that's only on editing on the frontend; no changes are required. For the gradients, I guess our gradients library would need to expose some function that allows changing every stop of the gradient to a specific alpha. This solution is also a little bit complex; the main advantage is that the dom we produce would be simpler as we would not require a dom element just for a color background.

In the future, we will probably move the image background to a dom element too. To take advantage of the server-side processing, WordPress does for images. If we follow that refactor, I wonder if it would make sense to join this work and that image change to avoid the need to add deprecations two times and the need to have our CSS code support more two different versions of the markup. In that case, I think it may make sense to not do the change to cover yet, and then do a wide refactor to the cover block with all these changes that are pending.

What do you think @jasmussen?

In the future, we will probably move the image background to a dom element too. To take advantage of the server-side processing, WordPress does for images. If we follow that refactor, I wonder if it would make sense to join this work and that image change to avoid the need to add deprecations two times and the need to have our CSS code support more two different versions of the markup. In that case, I think it may make sense to not do the change to cover yet, and then do a wide refactor to the cover block with all these changes that are pending.

This sounds very reasonable. As far as I'm aware, there are many pros to moving to a regular image, including around how srcsets work. The primary challenge, as I perceive it, is to refactor how the fixed position works, where currently it's a simple background-position change, whereas were it an image, it'd probably need to combine some position: fixed; with overflow: hidden; on a parent.

CC: @ajlende as I believe you've been involved in related work.

In the mean time, I would agree that it'd be best to find a way to avoid block deprecations. I have some thing to look into elsewhere today, but when I have a moment, I'm going to try and dive into the PR and see how I may be able to help.

@jorgefilipecosta The work for moving the cover block background image is in #25171. It's just kinda sitting there waiting for a +1.

That PR doesn't include changes for the fixed or "parallax" mode that Joen is referring to, so if we're trying to limit the number of deprecations, we'd also probably want to include that change. I can add it to #25171 or we can open another PR to review it separately and join the three together before merging them all.

@ajlende just to be sure I'm understanding you correctly, #25171 removes the "parallax" feature from the cover block, correct? I guess that makes sense insofar as now that I think about it, it's really tricky to replicate with an img, because position: fixed; puts it outside of the containers stacking order, so it can't be "cropped" by the cover container.

But that's still a big bummer. Is there some basic parallax JavaScript that we can use to replicate the parallax effect, without deprecating it?

#25171 didn't touch the parallax feature—choosing parallax sets the background-image property as before and is the only option that doesn't use srcset. That's what I was referring to when I was talking about opening a third PR—to see if it's worth trying to find a JS solution which will allow both srcset and the parallax effect.

Oh that's smart! That seems totally fine. Thank you for the clarification.

paaljoachim · 2020-10-21T10:45:26Z

I tested with the Cover block and this works nicely!
Which other blocks will have this feature included?

stokesman · 2020-10-29T02:24:57Z

Enables transparency in backround-color of: cover, button, paragraph, heading, list

Seems like a feature that would be best made available via Block Support/theme.json, no?

cpapazoglou · 2020-10-30T13:31:39Z

Enables transparency in backround-color of: cover, button, paragraph, heading, list

Seems like a feature that would be best made available via Block Support/theme.json, no?

Great suggestion @stokesman, we can create a disable-block-transparency support option and disable this feature only in case it is true. Right?

stokesman · 2020-10-30T17:37:33Z

Yeah, that's the idea. Though on second thought I wonder if it'd be important to have the support flag. I'm not sure that theme creators would feel the need to control this separately. There's already the custom color supports setting and disabling that would also disable the access to the alpha control.

aristath · 2021-03-05T10:44:07Z

If we intend to go through with this, the PR should be rebased 'cause it's been a long time and there are numerous merge conflicts now 👍

cpapazoglou · 2021-07-03T14:41:06Z

I started this PR months ago.
Since then many gutenberg related things have changed and I also don’t have the availability to move this forward.
For anyone interested, feel free to abandon or commandeer this PR.

ramonjd · 2022-02-07T04:51:39Z

I think we can close this one now that we have alpha controls in the colorpicker. See: #37731

If I'm mistaken, please reopen. Thank you!

cpapazoglou mentioned this pull request Sep 17, 2020

Add background colour transparency to blocks that support background colour #18095

Closed

cpapazoglou marked this pull request as ready for review September 18, 2020 12:39

cpapazoglou requested review from ajitbohra, chrisvanpatten, ellatrix, Soean, talldan and youknowriad as code owners September 18, 2020 12:39

cpapazoglou changed the title ~~Update/enable alpha controls~~ Enable alpha controls (transparency) Sep 18, 2020

youknowriad requested a review from jorgefilipecosta September 21, 2020 08:47

youknowriad added [Feature] Design Tools Tools that impact the appearance of blocks both to expand the number of tools and improve the experi [Type] Feature New feature to highlight in changelogs. labels Sep 21, 2020

youknowriad requested review from ItsJonQ and jasmussen September 21, 2020 09:11

aristath added the Needs Accessibility Feedback Need input from accessibility label Sep 21, 2020

aristath removed the Needs Accessibility Feedback Need input from accessibility label Sep 21, 2020

ItsJonQ approved these changes Sep 21, 2020

View reviewed changes

jorgefilipecosta reviewed Oct 12, 2020

View reviewed changes

cpapazoglou changed the title ~~Enable alpha controls (transparency)~~ Enable opacity control (transparency) Oct 16, 2020

cpapazoglou changed the title ~~Enable opacity control (transparency)~~ Enable opacity control (transparency) in blocks that support background color Oct 16, 2020

stokesman mentioned this pull request Jan 15, 2021

Add srcset for cover image #25171

Merged

10 tasks

ajlende mentioned this pull request Jan 19, 2021

Fix repeated backgrounds for cover srcset #28310

Merged

6 tasks

Base automatically changed from master to trunk March 1, 2021 15:44

cpap added 5 commits May 17, 2021 12:21

Enable setting alpha in colors, setting it by default to disabled.

fa8bd27

Ammends previous

ba3c92d

Returns the rgba serialized

bcf51e4

Enables transparency for button, paragraph, list, heading,

574f142

Enables changing the opacity of overlay

3290dbb

cpapazoglou force-pushed the update/enable-alpha-controls branch from 2afee4d to 3290dbb Compare May 17, 2021 09:39

Rebase fixes.

2c838bb

ramonjd closed this Feb 7, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Enable opacity control (transparency) in blocks that support background color #25421

Enable opacity control (transparency) in blocks that support background color #25421

cpapazoglou commented Sep 17, 2020 •

edited

Loading

cpapazoglou commented Sep 18, 2020

youknowriad commented Sep 21, 2020

cpapazoglou commented Sep 21, 2020

jasmussen commented Sep 21, 2020

aristath commented Sep 21, 2020

jasmussen commented Sep 21, 2020

aristath commented Sep 21, 2020

ItsJonQ left a comment

jasmussen commented Sep 21, 2020

cpapazoglou commented Sep 22, 2020

cpapazoglou commented Oct 2, 2020

jasmussen commented Oct 5, 2020

jorgefilipecosta left a comment

jorgefilipecosta Oct 12, 2020

jorgefilipecosta Oct 12, 2020

jorgefilipecosta Oct 12, 2020

jasmussen Oct 14, 2020

ajlende Oct 14, 2020

jasmussen Oct 15, 2020

ajlende Oct 15, 2020

jasmussen Oct 15, 2020

paaljoachim commented Oct 21, 2020 •

edited

Loading

stokesman commented Oct 29, 2020

cpapazoglou commented Oct 30, 2020

stokesman commented Oct 30, 2020

aristath commented Mar 5, 2021

cpapazoglou commented Jul 3, 2021

ramonjd commented Feb 7, 2022

Enable opacity control (transparency) in blocks that support background color #25421

Enable opacity control (transparency) in blocks that support background color #25421

Conversation

cpapazoglou commented Sep 17, 2020 • edited Loading

Description

How has this been tested?

Screenshots

Types of changes

Checklist:

cpapazoglou commented Sep 18, 2020

youknowriad commented Sep 21, 2020

cpapazoglou commented Sep 21, 2020

jasmussen commented Sep 21, 2020

aristath commented Sep 21, 2020

jasmussen commented Sep 21, 2020

aristath commented Sep 21, 2020

ItsJonQ left a comment

Choose a reason for hiding this comment

jasmussen commented Sep 21, 2020

cpapazoglou commented Sep 22, 2020

cpapazoglou commented Oct 2, 2020

jasmussen commented Oct 5, 2020

jorgefilipecosta left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

paaljoachim commented Oct 21, 2020 • edited Loading

stokesman commented Oct 29, 2020

cpapazoglou commented Oct 30, 2020

stokesman commented Oct 30, 2020

aristath commented Mar 5, 2021

cpapazoglou commented Jul 3, 2021

ramonjd commented Feb 7, 2022

cpapazoglou commented Sep 17, 2020 •

edited

Loading

paaljoachim commented Oct 21, 2020 •

edited

Loading