Remove parser dependance on all CSS colors in functional notation (except color()) having 4 elements (3 color coordinates; 1 alpha)

[kleinfreund]

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.

[svgeesus]

One such case is color() which has 5 elements (https://www.w3.org/TR/css-color-4/#predefined).

I'm not seeing any production in the CSS Color 4 definition of color() which would result in 5 elements. There are either 3 RGB or 3 XYZ elements, optionally with a fourth alpha element.

[kleinfreund]

I'm not seeing any production in the CSS Color 4 definition of color() which would result in 5 elements. There are either 3 RGB or 3 XYZ elements, optionally with a fourth alpha element.

I'm counting <predefined-rgb> and <xyz-space> as an element which becomes relevant in

color.js/src/parse.js

Line 257 in 3fe6c58

|| (name !== "color" && args.length === 3)

where those values will be pushed into the args array which is eventually used in

color.js/src/parse.js

Lines 39 to 44 in 3fe6c58

	let coords = env.parsed.args;
	let types = coords.map((c, i) => env.parsed.argMeta[i]?.type);
	if (name === "color") {
	// color() function
	let id = coords.shift();

for the parsing of color().

On reading my original message above back, I realize that the phrasing isn't quite clear. I only mean to say that color() serves as precedent for a syntax that has more that four things inside the parentheses. If there were another new functional color syntax with more than 4 things inside the parentheses then that code linked above will lead to errors.

[LeaVerou]

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.

Exactly. This is information that should live with the color format. IIRC this was introduced to handle alpha, we should probably have a property that controls how alpha is specified in the format. Before designing syntax for said property, let's enumerate what options we want to support. E.g.:

• No alpha supported | Mandatory | Optional
• Alpha as positional argument (e.g. a 4th argument is always alpha) | designated by / | both

Are there any other things that vary across the formats we currently support or may need to support in the short-term future?

[kleinfreund]

Are there any other things that vary across the formats we currently support or may need to support in the short-term future?

I considered this question a bit some weeks ago as I was working on #653. Specifically in the "Notes" section of that draft PR's description where I'm exercising my thoughts loudly about a possible syntax for defining color space formats more completely/accurately. To summarize, this tries to turn the spec's syntax definition (e.g. https://www.w3.org/TR/css-color-4/#funcdef-hsl)

hsl() = [ <legacy-hsl-syntax> | <modern-hsl-syntax> ]
hsla() = [ <legacy-hsla-syntax> | <modern-hsla-syntax> ]
<modern-hsl-syntax> = hsl(
    [<hue> | none]
    [<percentage> | <number> | none]
    [<percentage> | <number> | none]
    [ / [<alpha-value> | none] ]? )
<modern-hsla-syntax> = hsla(
    [<hue> | none]
    [<percentage> | <number> | none]
    [<percentage> | <number> | none]
    [ / [<alpha-value> | none] ]? )
<legacy-hsl-syntax> = hsl( <hue>, <percentage>, <percentage>, <alpha-value>? )
<legacy-hsla-syntax> = hsla( <hue>, <percentage>, <percentage>, <alpha-value>? )

into a JavaScript structure:

const hsl = {
  grammars: [
    {
      name: "hsl",
      label: "<modern-hsl-syntax>",
      parameters: [
        {
          types: ["<hue>", "none"],
        },
        {
          types: ["<percentage>", "<number>", "none"],
        },
        {
          types: ["<percentage>", "<number>", "none"],
        },
        {
          types: ["<percentage>", "<number>", "none"],
          optional: true,
        },
      ],
    },
    {
      name: "hsla",
      label: "<modern-hsla-syntax>",
      parameters: [
        {
          types: ["<hue>", "none"],
        },
        {
          types: ["<percentage>", "<number>", "none"],
        },
        {
          types: ["<percentage>", "<number>", "none"],
        },
        {
          types: ["<percentage>", "<number>", "none"],
          optional: true,
        },
      ],
    },
    {
      name: "hsl",
      label: "<legacy-hsl-syntax>",
      legacy: true,
      parameters: [
        {
          types: ["<hue>"],
        },
        {
          types: ["<percentage>"],
        },
        {
          types: ["<percentage>"],
        },
        {
          types: ["<percentage>", "<number>"],
          optional: true,
        },
      ],
    },
    {
      name: "hsla",
      label: "<legacy-hsla-syntax>",
      legacy: true,
      parameters: [
        {
          types: ["<hue>"],
        },
        {
          types: ["<percentage>"],
        },
        {
          types: ["<percentage>"],
        },
        {
          types: ["<percentage>", "<number>"],
          optional: true,
        },
      ],
    },
  ],
}

(see that PR's description for some more thoughts on this)

To get back to your question as for what information we need:

• whether a grammar is a legacy grammar (implies the current commas setting)
• how many parameters a format has (including whether a parameter is optional, covers alpha)
• what types a parameter can have

It's also important that we need an array of grammars per format so we can distinguish special cases like legacy RGB accepting <percentage> or <number> but not a mix of them.

(I should also note that I'm mainly considering this from the lense of parsing even though currently, colorjs.io also uses the format definitions for serialization, something I'd prefer to see be handled independently in the future).