fix(gradients): support for 'transparent' as a color stop

[evanoc3]

No other modules I found could be used plug'n'play here. It seems that the only value that parse-color doesn't handle correctly is transparent, so it can be handled especially

Some test cases that verify different color formats get handled correctly wouldn't hurt either.

resolves #64

[coveralls]

Coverage remained the same at 100.0% when pulling 93a923d on evanoc0:Fix-transparent-color into 80f24aa on hustcc:master.

[jtenner]

AFAIK "transparent" should also be a valid fillStyle and strokeStyle. Essentially, every call to parseColor() should check for "transparent".

I am proposing to replace calls to parseColor() with another function that calls parseColor() and otherwise outputs result.hex to the appropriate value of "transparent" so that it works everywhere and results in a smaller codebase.

[jtenner]

Example output:

> temp1
CanvasRenderingContext2D {canvas: canvas, globalAlpha: 1, globalCompositeOperation: "source-over", filter: "none", imageSmoothingEnabled: true, …}
> temp1.fillStyle = "transparent"
"transparent"
> temp1.fillStyle
"rgba(0, 0, 0, 0)"

[jtenner]

Another way to tackle this problem is to submit a pull request to the parse-color package, and fix support for "transparent" everywhere.

If perhaps they don't want to support this request, another option would be to fork parse-color and replace our usage of the module to a fork.

I will accept any of these solutions to get things working.

[evanoc3]

A module called validate-color can be used instead of parse-color, it validates colors by keyword, rgb[a] ,hex, and hsl[a] correctly.
There latest version of it on npm is currently missing it's lib, so I filed an issue and added the previous version, but when that is resolved it should be updated to latest.

[jtenner]

Wow this is great. Please give me a day to look over this and do a review.

[jtenner]

Please make sure that "validate-color" actually returns the HEX values for the fillStyle and strokeStyle property output.

[evanoc3]

Further than validating them, to alter the format of provided colors to hex would require functionality more than validate-color offers so I'll go back to the drawing board on that.
I'll look at the color-parse module to see if it is suitable. It seems more up to date than parse-color and is inspired by it so should work similarly.

[jtenner]

Is it possible we could submit a pull request to the module we currently use? I bet the maintainer would appreciate it.

[jtenner]

If not, https://www.npmjs.com/package/color-rgba looks like it might be the module we need to use.

[evanoc3]

The original module hasn't been touched in 6 years, which doesn't inspire hope in me that an issue would be answered

color-parse and color-rgba come from the same organization and seem to both be part of a family of similar modules, so either should work equally well

[jtenner]

Yes. This looks like an opportunity to fork parse-color, maintain some fixes, publish it to npm with a different name. Looks like substack hasn't touched their software in a really long time.

[jtenner]

In fact it looks like it's just a wrapper for a set of functions provided by: https://github.com/Qix-/color-convert

color-parse is MIT license, so we can copy the source of the color-parse/index.js function directly into the project and use an updated version of Qix-/color-convert to convert the color values between each other.

[jtenner]

Upon further investigation it uses the https://github.com/colorjs/color-name/ package to generate colors. It uses only rgb values. Perhaps it's time to implement a proper spec compliant css color parser?

[jtenner]

This is much better. Sorry for being verbose. I am proposing to switch to moo-color. Please see the above output on how to parse the colors and return the correct string values.

[evanoc3]

The defintely seems like the best option, I'll try it out

[evanoc3]

I've read over the HTML canvas spec and updated this to follow the color-serialization rules faithfully.

Internally, the _fillStack, _strokeStack, and _shadowStack now take MooColor objects instead of strings and produce events with the value being those objects too. I take it those are only for testing and so that's ok, since the getters/setters produce the correct values?

[jtenner]

A lot of the above comments reference changes to the test suite which should not be changed to validate that the functions and properties are spec compliant.

Thank you for your hard work, and it looks like this pull request is almost done.

Please make sure that your coding style matches single quotes for strings.

[jtenner]

Another round of changes. Sorry if I wasn't clear about my suggestions. I would prefer to store the resulting color value up front, otherwise we will need to call into MooColor more than once per proptery set and get.

I believe that some of this is my fault for not making my suggestions more clear.

In a future PR, I will add prettier support and a CONTRIBUTING.md document to help others in the future.

[evanoc3]

Just to ask, I'd like to include a test suite for the new function serializeColor to keep coverage at 100%. Is there a preferable way to make the function accessible to tests... Can I just export it, or use something like rewire?

[jtenner]

LGTM

@hustcc You can review this if you would like.

One of the things I noted about this pull request is that we should have a CONTRIBUTING.md file and use prettier for code formatting. I will submit a pull request later this week for these changes.

[jtenner]

I don't think this utility function is necessary, and we only need to snapshot and test the endpoint output. If perhaps you would like to test the function more, we can add more colors to the test suite, but it does look like everything is working as intended.

Another very good idea might just be to comment that function and state its purpose.

[jtenner]

One last commit suggestion:

• Add a contributors section at the bottom of README.md
  • add @jtenner, @hustcc and yourself to the list
• The changes involved here are backwards compatibile, but rewritten using a new module
  • add version 2.3.0 to the top of the list
  • add line item to changelog,md add "switched to moo-color for color parsing"
  • add line item to changelog.md add "added contributors to markdown document"