Missing output formats

[marcandre]

While the input format is permissive, the output format isn't as flexible. For legacy reasons, we'd rather store colors as hex codes without the '#'. That's not a problem for input, but there's no corresponding output.

My first thought was to make a PR where preferredFormat can be a function, but because of the "feature" with formatting and alpha #182, it's not clear if that would be an acceptable feature.

Otherwise having a "hex6short" or similar would work.

[bgrins]

Are you using a form post to get the value? If not, you could get the value as color.toHex() instead of color.toHexString() in the change event, for instance.

[marcandre]

Yes, I'm using an <input> inside a form that gets posted.

[bgrins]

Hmm, I'm not sure about overloading the color toString call even more than it already is (https://github.com/bgrins/TinyColor/blob/master/tinycolor.js#L123-L160). The input is basically being set by color.toString(preferredFormat), and toString is always returning the version with the #. Then if we wanted to support it without the #, we would need to add all of the variations to be consistent:hexshort hex3short hex6short hex8short. Would it work for you to just listen to the form submit event and do something like:

$(".spectrum").each(function() {
  $(this).val(tinycolor($(this).val()).toHex());
});

Or maybe even trim it on the server?

I suppose it could be possible to provide a custom value rendering function that takes in a color and preferredFormat and returns a string. Would have to think about that a bit more though.

[marcandre]

Right, I can find an alternate solution to bypass spectrum's behavior, but I wanted you to be aware of this. spectrum is nice enough to update the val of the input, but by taking the responsibility, it ideally should give us the control we need to do so.

In any case I'll probably have to do something, as spectrum chooses to update the value of the input only when validating a dialog, even though the visual representation of the input (the color swatch) does change when moving around the color spectrum.

[bgrins]

I'm thinking about the idea of allowing a custom valueFormatter function... Would you want this to only set the value of the original input, or also to set the value of the visible input (with showInput)?

[marcandre]

Right now, because we use spectrum as a RGB selector only and use a separate Alpha control, I have no choice but to override spectrum anyways. I take whatever color spectrum tells me, convert to RGBa, override the alpha with the value of my control and reset the color to that (see #182).
Another problem I have is that spectrum doesn't change the input when moving around the spectrum. It works better for us to make the change in that case too. So the logic to see if the value has changed doesn't work for us. Thank god there's the 'hide' event.
So really, I'd say that a value formatter for the input might be useful to others, but I can't really use a value formatter unless spectrum changes the way it works for showAlpha = false (see #182) and has an option to update the input on move. Otherwise I have to override it anyways.
For the showInput, I could use it (to force hex6), but again it's more a matter of philosophy about how to deal with alpha.

It looks like we're using spectrum in a different way than was really intended: we like to split the RGB and the alpha values, both in terms of UI and in terms of <input>, we prefer hex6 without the '#', and we feel it makes sense that change is triggered on the input when moving around the spectrum.

I can understand if you prefer not changing spectrum to handle these requirements since it is possible (albeit not natural) to hack around it and make it work. Feel free to close this issue and #182, or else I'm more than willing to discuss solutions 😸

[bgrins]

OK, so regarding firing change on move, there used to be an option for this, but it caused many issues. IIRC most had to deal with reverting and clicking out of the colorpicker. I also saw issue #173 was opened requesting the ability to fire change on move. We could revisit this, or at least come up with and document an 'official' workaround for how to accomplish this behavior. What is your current workaround for this, btw?

Regarding the hex without the #, it still sounds like the formatter would be helpful here (really, issue #182 is a separate concern from this).

Are you using a flat colorpicker? If not, have you seen clickoutFiresChange? http://bgrins.github.io/spectrum/#options-clickoutFiresChange. That will at least help you not have to wait for a hide event to get a change to fire.

[bgrins]

Also, Issue #184

[bgrins]

Moving the discussion about firing change on move to #173. We can focus simply on the output formatting here.

[marcandre]

Sorry, not 100% sure which 'workaround' you are talking about. Here's what we do:

move callback: a bunch of workarounds:

1. (workaround Continuous Update Mode? #184) combine the colour with our alpha control and reset the colour with spectrum('set', combinedColorAndAlpha). This has the undesirable side effect of populating the palette with a whole bunch of colours when dragging around the spectrum, but unavoidable AFAIK
2. we update the input manually (because we want to have it updated in case of form submit and because we want other code to be able to rely on the updated value and since output format isn't "hex short")
3. trigger the change event manually, to keep the code decoupled between the picker and the code that needs to update the rest of the page to show the user how the new colour choice looks like.

change callbacks: can't be relied upon, since might not be triggered if the user ended up selecting the color to the original colour manually. spectrum thinks the input hasn't really changed (it has, since we updated it manually), so does not trigger the event (even though it does reset the value, with the wrong formatting).

hide callback: our saviour because it's always called. Same code as move callback.

HTH