GradientPicker: improvements wishlist

ciampo commented 2 years ago

This is a wish list of improvements for the GradientPicker component (& related components) that I came up with while fixing popover regressions:

Slow rendering performance

This can be observed especially when dragging a control point in the editor:

https://user-images.githubusercontent.com/1083581/182951729-34eba57c-0c46-4a11-bffd-5354fb4bb718.mp4

~Improve the initial state when there's no gradient set~

~The semi-transparency given to the whole gradient bar is weird, especially when clicking on an insertion point: in that case, the popover is also semi transparent, and is rendered below the rest of the controls (this is a side-effect caused by the opacity rule, which creates a new stacking context for the gradient bar)~
~I also find it weird that the "no gradient set" state is represented by the value of the gradient being set to the default one — in my mind, that value should be undefined (or null), but definitely not a gradient. The visual state of the component should be also adjusted to clearly show that there's no gradient being set~

https://user-images.githubusercontent.com/1083581/182949019-584c1ad3-717b-41bd-a383-5b354c1e6642.mp4

Done as part of https://github.com/WordPress/gutenberg/pull/49146

~Get rid of `__experimentalHasMultipleOrigins` prop~

~We should agree on the best way to implement this feature, and remove the experimental prop. I'm personally not a fan of props like __experimentalHasMultipleOrigins that change the meaning of other props (in this case, gradients). Maybe we don't need __experimentalHasMultipleOrigins at all, and we can just infer the information from the shape of the gradients prop~

Done in https://github.com/WordPress/gutenberg/pull/46315

Get rid of the `__experimentalIsRenderedInSidebar` prop

We should avoid props that introduce a tight coupling with the editor. First we should understand exactly what changes when this prop is specified, and then find alternatives to get to the same results

Component structure is messy

We should tidy up components and folder structures for the GradientPicker-related components (GradientPicker, CustomGradientPicker, ColorPalette, ColorListPicker, CircularOptionPicker, ColorIndicator....). These components feel very intertwined / tightly coupled and partially overlapping. (related to https://github.com/WordPress/gutenberg/issues/35093 )

~Sometimes clicking on the GradientPicker in the editor doesn't result in a new control point being added~

~I can't reproduce this unexpected behavior consistently, but it's definetly something that we should investigate (it could be related to the low rendering performance listed above)~

Done as part of https://github.com/WordPress/gutenberg/pull/49146

ciampo commented 2 years ago

cc @jorgefilipecosta who mostly worked on these components — would you have any capacity to take a look at some of these issues?

talldan commented 2 years ago

isRenderedInSidebar was mentioned in this discussion - https://make.wordpress.org/core/2022/08/10/proposal-stop-merging-experimental-apis-from-gutenberg-to-wordpress-core/#comment-43590.

It's in use by a plugin, so some care should be taken when refactoring it.

uzegonemad commented 2 years ago

Hopefully this is the appropriate place to leave this feedback. (If not, please redirect me to the appropriate place.)

It would be ideal to display the percentage a gradient stop (control point) is located at.

Right now, to ensure a gradient stop is at the correct place, I have to open my browser's dev tools, select the element with the gradient, and move one of the points until dev tools show it at the correct percentage. (The use case is a sharp gradient at 50%, or 1/3. I use those to display full-width backgrounds while maintaining a content grid)

Adding a tooltip to the control point would be a huge help.

It would also be useful to have an input to make manual tweaks to the position.

The use case is to provide better precision but also the ability to use other units, e.g. vw/vh or px. It looks like others have previously mocked up what this could look like in several of the comments from https://github.com/WordPress/gutenberg/issues/16662, as well as https://github.com/WordPress/gutenberg/issues/23816#issuecomment-674271963.

ciampo commented 2 years ago

Hey @uzegonemad , thank you for your feedback!

We're not actively working on this component at the moment, but we'll take your feedback into account when we do!

jorgefilipecosta commented 2 years ago

Hi @ciampo,

Slow rendering performance

Is this issue specific to the gradient picker, or is the site editor that is taking some time to update and reflect the new prop? With CPU throttling updating a color by dragging on the color picker and updating a gradient is not very different.

cc @jorgefilipecosta who mostly worked on these components — would you have any capacity to take a look at some of these issues?

Yes, I will try to find some availability to do some enhancements here.

ciampo commented 2 years ago

Is this issue specific to the gradient picker, or is the site editor that is taking some time to update and reflect the new prop? With CPU throttling updating a color by dragging on the color picker and updating a gradient is not very different.

I believe it's more about the site taking a long time to update to reflect the changes in the new prop.

seothemes commented 2 years ago

Could we also add support for conic gradients to the wishlist?

There is good browser support now and no reason not to provide the option.

ciampo commented 1 year ago

Could we also add support for conic gradients to the wishlist?

There is good browser support now and no reason not to provide the option.

This list was mainly aimed at improving / polishing the component in its existing state, but in general I'm not opposed to it

seothemes commented 1 year ago

I have created a separate issue here https://github.com/WordPress/gutenberg/issues/44633

WordPress / gutenberg