parse.js fixes to allow "custom" ColorSpace formats #595
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Two very simple fixes that come out of this discussion: #593
parse()
function, but only exiting the inner of two loops. I added a new variable:found
, that the inner loop sets to true so that the outer loop knows to exit. This was not only causing unnecessary iterations of the loop, it was causing issues with custom user ColorSpaces that have formats with{type:"custom"}
.?
in this line:let color = format.parse?(env.str);
so that "custom" ColorSpace formats don't require aparse
property. The discussion linked above creates a custom ColorSpace with a default format that has a customserialize()
property/function, but doesn't need aparse
property. The current code requires it to have a dummyparse()
property/function that returns falsy. This change removes that requirement and prevents the throwing of unnecessary errors.It is worth noting that this outside loop on
ColorSpace.all
is inefficient relative to its contents, even after fix 1. There is only one built-in space with custom formats: sRGB, and it's the near the end ofColorSpace.all
. I'm no expert, but based on what I've seen I can't imagine any other built-in spaces doing custom parsing. As for user color spaces, I don't know if any other users have created any, and mine doesn't parse. Are there pending proposals for new CSS color strings that parse in other spaces? Is there a need for a user color space that parses a custom, non-CSS color string?If you want to ensure that user spaces and new built-in spaces can do custom parsing, you can create a new
ColorSpace.custom
array containing sRGB all other registered spaces that have custom formats. You could add spaces to that array inregister()
. Otherwise it's just sRGB, no need to iterate over any other color spaces.