ColorPicker: Number Sign on Hex Input Values

[hzhu]

I noticed that there's no option to include a number sign in front of HEX input values, e.g. #FF00FF. It seemed to have been left off on purpose. I have a few questions regarding this decision:

1. Why was the number sign (#) left off of HEX input values? What drove this decision?

2. Is there a way for consumers to configure the ColorPicker so that the input renders HEX colors with the number sign (#)?

[ecraig12345]

The ColorPicker was designed a long time ago and hasn't been updated much, so at this point it's hard to say exactly what the rationale was, sorry. My guess is because including the # (and requiring that the user preserve it while editing) would add a bit of extra complexity, and it's not really necessary when the field is typically labeled "hex".

There's not currently a way to make the field include the # (though you can customize the label if that helps). What was your reasoning for wanting to show it?

[hzhu]

Thanks @ecraig12345 for the response, really appreciate it 🙏 .

What was your reasoning for wanting to show it?

The ability for the HEX input to handle a number (#) would help improve usability by allowing users to copy HEX values from popular tools (web browsers, design tools) and paste it directly into the HEX input of the color picker.

Copying a HEX value with # from web browser:

Copying a HEX value with # from design tools:

[JustSlone]

Interesting, so then this could be simply solved by ColorPicker allowing a # value to be input into the control, even if the control immediately strips it off.

Like this:

[hzhu]

@JustSlone thanks for the response!

Oh yeah, that would solve it 👍 . However, I should have mentioned that the ability to copy + paste the other direction would also help improve usability. For example, copying a HEX value from the color picker, then pasting it into a web browser (or design tool):

I imagine (as @ecraig12345 had mentioned) the ability for the HEX input to handle number sign (#) and non-number sign values could introduce some complexity to the code. Is the improved usability enough to warrant further engineering and design exploration?