Skip to content
This repository has been archived by the owner on Nov 6, 2022. It is now read-only.

Add Color Picker control. #201

Closed
wants to merge 6 commits into from
Closed

Add Color Picker control. #201

wants to merge 6 commits into from

Conversation

kopepasah
Copy link
Contributor

Adds a color picker control.

@kopepasah kopepasah added this to the 1.1.1 milestone Dec 11, 2018
@RobStino
Copy link
Collaborator

@kopepasah
Testing. Noticed a few bugs.

  1. There is too much padding on the rgba input fields. Means you can't see the input values.
    image
  2. The input fields & the arrow button at the end are different heights.
    image
  3. The position of the arrow button that cycles through the color types shifts around depending on the width of the other input fields. Expecting the button to remain fixed to the right.
  4. The little white arrow at the top of the modal is about 1px out of line with the top of the modal. Expecting it to be flush, where it kinda overlaps.
    image
  5. Toggling through the different color types doesn't change the output. The output, in the editor and frontend is always HEX. This is particularly noticeable with rgba as the alpha value doesn't do anything.

1 & 5 are the only real bugs. 2-4 are minor design flaws.

In general, this is a great start! Really cool to see you pull together this particular implementation. I'm interested in whether you still think it's a good idea doing this as you mentioned concern with that it departs from the native controls.

@kopepasah
Copy link
Contributor Author

@RobStino addressed numbers 1 and 5 in the two new commits.

@RobStino
Copy link
Collaborator

@kopepasah
Looking good now. I think I've found one more bug, and have one more thought.
Bug(?)
If you set the color with HSL, it switches back to RGBA. The color is correct, but I feel like if you choose HSL, that should persist through the experience. Including what is displayed next time you open the control as well as what is outputted in the preview and and the frontend. Noting however that this same issue occurs with the native color control, so may not be something we solve ourselves.
Thought
When adding the field to the block, should you be able to set a default?

@lukecarbis
Copy link
Member

@RobStino This is a known issue in Gutenberg. WordPress/gutenberg#11791

Copy link
Member

@lukecarbis lukecarbis left a comment

Choose a reason for hiding this comment

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

Great feature! Some minor suggestions included here.

@@ -38,5 +38,7 @@
"uglifyjs-webpack-plugin": "^1.2.7",
"webpack": "^3.11.0"
},
"dependencies": {}
"dependencies": {
"color": "^3.1.0"
Copy link
Member

Choose a reason for hiding this comment

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

Is this required? Isn't a colour picker included in WordPress by default? https://github.com/WordPress/gutenberg/tree/master/packages/components/src/color-picker

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@lukecarbis this package is not the color picker, but rather used to adjust the darkness of the border in the select color display, this way the border can be a similar color variation.

Copy link
Member

@lukecarbis lukecarbis Dec 12, 2018

Choose a reason for hiding this comment

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

It would be really nice if we could find a workaround for this without introducing a third-party dependency (our only one!).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

We could use tinycolor, which is used in WordPress, but I did not see it exposed as usable. So it would have to be imported too.

Do you see an issue with introducing dependencies?

js/blocks/controls/index.js Show resolved Hide resolved
'sanitize' => 'sanitize_textarea_field',
)
);
}
Copy link
Member

Choose a reason for hiding this comment

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

There should also be a default setting.

help={ field.help }
className="block-lab-color-picker"
>
<span className="components-color-picker__alpha block-lab-color-picker__current-color" style={ {
Copy link
Member

Choose a reason for hiding this comment

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

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It could, but would require some adjusting non-the-less. Do you see any advantages of using the component over the current implementation?

Copy link
Member

Choose a reason for hiding this comment

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

Relying on core components means less maintainability.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

While I do agree, in this case we are only referencing a span and, even if we did use the component, we still need the wrapper component and style adjustments (which the core component does not allow to alter on the component level).

@lukecarbis lukecarbis mentioned this pull request Jan 4, 2019
@lukecarbis lukecarbis deleted the feature/color-picker branch January 15, 2019 00:54
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants