Description
Currently, the colorjs.io parsing logic has a dependance on color strings in functional notation (except color()) having 4 elements: 3 color coordinates and 1 alpha. This was introduced in #650 and discussed in #650 (comment).
This dependance would lead to errors if support for color strings in functional notation with a different number of elements is introduced.
One such case is color() which has 5 elements (https://www.w3.org/TR/css-color-4/#predefined). This also illustrates that it's plausible that this becomes a problem as the elements in between the parentheses aren't constrained to be just color coordinates and an alpha value. For color(), the first element is the color space parameter and effectively shifts the color and alpha elements "to the right".
To remove this dependance, each color space format could hold a definition of each element in the corresponding functional notation. The introduction of a new format and/or color space would then have to only take care of providing an accurate definition and not need to mess with the general parsing logic.