.toRgbString() returns unexpectedly unspaced result

[jhack89]

Dear Developers,

color.toRgbString() is supposed to be compatible with the jQuery.css(), however it does not return an easily comparable value.
In fact, jQuery.css("color") returns colors as "rgb(xxx, xxx, xxx)" while .toRgbString() return the same as "rgb(xxx,xxx,xxx)" without spaces! This makes impossible to easily compare colors as strings without workarounds such as $("<div>").css("color", color.toRgbString()).css("color"). This is especially important when comparing miscellaneous CSS proprieties.

Example code where I needed to use the workaround to make things work seamlessly:

$("#element").click(function() {
$(this).animate(
{
   "backgroundColor": "red",
   "width", "+=100"
}, {
    duration: 1000,
    step(val, fx) {
    // some code here
    if( $("<div>").css(fx.prop, fx.end.toString()).css(fx.prop) == check[fx.prop]) { ... }
    /* instead of the expected: 
     * if(fx.end.toString() == check[fx.prop]) { ... }
     */
    // more code here
    }
})
});

It would be great if this little bug could be fixed.
Thank you for your great work,
Warmest Regards.

[dmethvin]

There is no conversion of units or format with the value that jQuery's .css() returns, so you are at the mercy of whatever the browser provides for color units. I don't know if that's a problem of the past that just affects browsers like IE8, or whether there are differences in newer ones as well. Still, it does make sense to match the browser format including spaces. Do you want to make a pull request?

[gnarf]

Hrm.

So the interesting part about this, is there is nothing in the spec that specifies the spacing, or format of this value coming back from the style object. Browser A might return rgba values as percents while browser b uses integer format.

I could see making the .toString() use a style property to calculate it's return value, where the .toRgbString etc methods would continue to return what they do.

[dmethvin]

I agree it's not specified by any standard, and we definitely saw differences in the past. What seems to have happened over the years is that everyone gravitated towards the rgb(...) format for the colors returned by getComputedStyle strings. That's why I cautioned @jhack89 about depending on it always being that way. Still, it seems like a really trivial change to make it match. I can see that being a breaking change to code that expects/parses the current format though.

[gnarf]

Interestingly, .toString is currently undocumented, and has a weird transparent case:

jquery-color/jquery.color.js

Lines 426 to 428 in 889d029

	toString: function() {
	return this._rgba[ 3 ] === 0 ? "transparent" : this.toRgbaString();
	}

Though I could ALSO see this being a breaking change, perhaps color 3.0 is on the horizon? Updated for jQuery 1.8 animation, removing IE6, etc?

[gnarf]

Though I'd also like to point out that the OP could use fx.end.is( check[ fx.prop ] ) instead of casting strings.

[dmethvin]

Seems like the "right" solution TBH.

[mgol]

The spec seems to have evolved since the initial report and now it's pretty strict in the expected output of computed style's color formatting, i.e. it requires the rgb form (or rgba if alpha is non-1) and it requires the values to be joined by , , i.e. with a space after the comma. See:
https://drafts.csswg.org/cssom/#serializing-css-values

[mgol]

That also means transparent is translated to rgba(0, 0, 0, 0). Should we align with the standard for 3.0.0?

[dmethvin]

That seems like a good idea.