Color picker <input> for DOM library

[stellartux]

Nature of issue?

• Existing feature enhancement
• New feature request

Most appropriate sub-area of p5.js?

• Color
• Other (specify if possible) - p5.dom.js

New feature details:

I was thinking it'd be useful if there was a quick and easy way to add the color picker DOM element with p5.js by doing something like createColor() . It's possible to createInput('#ffffff', 'color') but calling value() on this input returns a hex color string, it'd be nice to be able to read and write the value as a p5.Color. For this I was thinking it'd be useful to parameterize the Color.toString() function so it could format the string in different ways, in this case as a 6 digit hex color code.

I'm going to attempt to implement this.

[limzykenneth]

As you mentioned createInput('#ffffff', 'color') is already available to create a color picker element and so having an additional function createColor() may be confusing and unnecessary.

As for returning a p5.Color object instead of a hex string, I'm also a bit skeptical of it. The main reason being having some sort of parity with the native HTML/JS API. The reason it returns a hex string is because with native API it returns a hex sting (ie. docElement.value returns a hex string). Not doing too much magic behind the scene helps with transitioning or working with other library/frameworks. It also aids the case when you need to send the color data off to a server instead of having to serialize it yourself. Getting the hex string and initializing a p5.Color object like so color(myInput.value) can easily create a p5.Color object as well.

Perhaps you have some use cases where color(myInput.value) is not a viable solution?

[stellartux]

I'm surprised you think its unnecessary having an easy way to input a color in a graphics library. If createColor() is unnecessary, by the same logic so are createSlider(), createButton(), createCheckbox(), createSelect() and createRadio().

It's not that the current method isn't viable to use, it's just inconsistent with the rest of the dom library. Currently, if you want to create a color input and choose the color it starts with, you have to convert it to a hex color code manually, and you can't create one without choosing a default color. Using color(myInput.value) feels like an awkward workaround when none of the other dom element values need converted. I can see why you would want it to be an easy transition to work with other frameworks or native HTML/JS, but if that's the idea it'd be better not to use the dom library at all. Isn't the point of the dom library letting people use dom elements without having to think about what's going on behind the scenes?

Having the ability to parse p5.Color objects to hex strings would still be useful even if createColor() doesn't get used. To show what I mean, I've rewritten p5.Color.toString() to return different formats of color code, preserving the original behavior if nothing is passed in. p5.Color.toString('#rrggbb') would return the string in the format compatible with the HTML API.

With that change, at least you could create a new color input with colorPicker = createInput(myColor.toString('#rrggbb')), 'color') but I still think colorPicker = createColor() and colorPicker = createColor(myColor) would be cleaner, easier to understand and more consistent.

[Spongman]

All other issues aside, I think 'createColorPicker' would be a better name.

[limzykenneth]

@amoetodi As @Spongman mentioned, createColorPicker would be a better name (ie. createColor is too confusing as one may expect it to create a p5.Color object not a DOM element). I guess my bigger concern is about what should the created element returned when querried and not whether it should exist or not. How about this: myInput.value() returns the hex string (which is the HTML value of the element, consistent with the rest of the DOM library API), while myInput.color() returns a p5.Color object?

To have p5.Color being able to return different kind of color strings is great and I don't object to that at all. I would suggest filing a PR for that.

[stellartux]

You're right, those are better ideas. I'll finish my changes to toString first and file a PR for that before I work on createColorPicker.

[TanviKumar]

I'd like to work on this new method. I'm hoping to discuss the possible parameters for this method.
var myInput = createColorPicker(colorValue); seems like the most common way one would create a color picker. The colorValue here could be a hex string which can be directly set or it could be a p5.Color object. Would it be wiser to allow only hex strings or have the method handle both cases?

[lmccart]

fixed with #3089