[css-color-4] `rgba()` is legacy so does not support `none`. Right?

[svgeesus]

From CSS Color 4:

The rgb() function defines an sRGB color by specifying the red, green, and blue channels directly

For legacy reasons, rgb() also supports a legacy color syntax that separates all of its arguments with commas:

Also, an rgba() legacy color syntax also exists, with an identical grammar and behavior to rgb().

Now I guess there are two ways of reading this:

a) rgba() is a legacy only syntax, so rgba(18% none 56% / 30%) is invalid
b) rgba() has a modern syntax, which is not described explicitly but is "identical" except for using rgba, and a legacy syntax given below.

@tabatkins Which is it?

I had assumed a). But WPT tests like parsing/color-computed-rgb.html seem to assume b). WPT results as do Chrome and Safari.

Either way the spec needs to clarify.

[tabatkins]

I think I intended (a), but I have no opinion on which we go with. If browsers and WPTs currently do (b), that's fine with me, so we should clarify in that direction.

[svgeesus]

@csnardi you wrote the WPT in question, should the spec be updated to add a non-legacy rgba() syntax (no commas, slash for alpha, accepts none)?

Comments from browser engineers working on this aspect very welcome.

[cdoublev]

I am not a browser engineer but I would like to add that the legacy rgb() syntax (production) accepts <alpha-value> whereas legacy color syntax defines that non-opaque forms use a separate notation (for example hsla() rather than hsl()).

EDIT: to be clear, I would remove non-opaque forms use a separate notation (for example hsla() rather than hsl()) from the definition of legacy color syntax, because rgba() and hsla() are aliases, ie. they can be an alias of legacy rgb() or hsl() but they "only" are aliases.

For legacy reasons, rgb() also supports a legacy color syntax that separates all of its arguments with commas:

rgb() = rgb( <percentage>#{3} , <alpha-value>? ) | rgb( <number>#{3} , <alpha-value>? )

For Web compatibility, the syntactic forms of rgb(), rgba(), hsl(), and hsla(), (those defined in earlier specifications) also support a legacy color syntax which has the following differences:

• color components are separated by commas (optionally preceded and/or followed by whitespace)
• non-opaque forms use a separate notation (for example hsla() rather than hsl())
• ...

I am not able to say why none and color channel keywords are not accepted in legacy color functions, but as a user I would prefer them to be accepted in all color function syntaxes (eg. as defined in 3. Relative Color Syntax for color channel keywords, even if there are also not accepted in <device-cmyk()>) or if it is not possible, only in non-legacy color functions, ie. not in rgba() and hsla().

EDIT:

Also as functionality is added over time, having to support [none] in all the various legacy syntaxes as well (with all their varying web-compat issues) would be burdensome for implementers while offering no particular benefit for content authors.

#7137 (comment)

This does not seem burdensome to me and the benefit I see for content authors would be that they would not have to remember in which syntax none in valid or not.

[GPHemsley]

My interpretation of the spec has been that legacy rgb() has one syntax and modern rgb() has another syntax, and that rgba() is just an alias for the corresponding syntax.

Put another way: legacy rgba() does not support none, but modern rgba() does.

(And the same goes for hsl() and hsla().)

[svgeesus]

Okay, sounds like a consensus is forming and so I should make the spec edits.

[svgeesus]

rgba() is legacy so does not support none. Right?

Wrong :)

[cdoublev]

I assume that the consensus is to accept none as an argument of rgba() and hsla() when they are aliases of the modern rgb() and hsl(), respectively, and that legacy rgba() or legacy hsla() are a short and confusing concept/naming for rgba() or hsla() as aliases of legacy rgb() or hsl(), that should be removed from the spec (like the link in the definition of <color> directing from <rgba()> to the definition of rgba() legacy color syntax).

  color:  rgb(0, 0, 0, none); /* invalid */
  color: rgba(0, 0, 0, none); /* invalid */
  color:  rgb(0 0 0 / none);  /* valid, serializes to rgba(0, 0, 0, 0) */
  color: rgba(0 0 0 / none);  /* valid, serializes to rgba(0, 0, 0, 0) */

---

Please allow me this additional observation, which is also valid for <hsla()>.

<color> includes both ... | <rgb()> | <rgba()> | ..., therefore a CSS parser should not recognize rgba as a function name alias of rgb when matching against <rgb()>: an input specified with rgba(...) should match <rgba()> instead.

<rgba()> is not defined with a basic syntax therefore w3c/reffy only extracts some prose and a grammar-driven parser implementation must define it on its side. It cannot define it with <rgba()> = <rgb()> because this would require to recognize rgba as a function name alias of rgb.

It might tempting to say that rgba() should be defined in prose as a legacy alias for rgb() and that <rgba()> should be removed from <color>, but similarly, <repeating-*-gradient()> is not defined with a basic syntax, is clearly not legacy, and is semantically different than the corresponding <*-gradient()>.

In my opinion, an ideal solution would be to define the arguments of <rgb()> and <rgba()> with a non-terminal:

<rgb-fn-args> = [
    [<percentage> | none]{3} [/ [<alpha-value> | none]]?
  | [<number> | none]{3} [/ [<alpha-value> | none]]?
<rgb()> = rgb(<rgb-fn-args>)
<rgba()> = rgba(<rgb-fn-args>)

<rgb-fn-args> could even include <legacy-rgb-fn-args>, which would allow w3c/webref to remove legacyValue for <rgb()>.

[GPHemsley]

@cdoublev I'm not sure I'm following your explanation/argument. Allow me to be deliberately verbose in order to ensure we're all on the same page.

---

css-color-3 defines rgb() with one syntax (3 comma-separated arguments) and rgba() with another syntax (4 comma-separated arguments):

	rgb()	rgba()
3 arguments	✔️	❌
4 arguments	❌	✔️

css-color-4 expands those definitions into a superset "legacy color syntax", using either 3 or 4 comma-separated arguments, invoked using either rgb() or rgba():

	rgb()	rgba()
3 arguments	✔️	✔️
4 arguments	✔️	✔️

That rgba() is what I refer to as "legacy rgba()" and is apparently already settled.

---

css-color-4 also defines a new syntax for rgb(), using only spaces and a slash to separate the alpha value, and allowing none. Under discussion here is whether that syntax is also available to rgba() - what I refer to as "modern rgba()".

The two options mentioned in the original comment are as follows:

a) rgba() is legacy syntax only

	rgb()	rgba()
legacy syntax	✔️	✔️
modern syntax	✔️	❌

b) rgba() is a complete alias of rgb()

	rgb()	rgba()
legacy syntax	✔️	✔️
modern syntax	✔️	✔️

Consensus appears to be (b).

---

After having ruminated and reread your comment, I think you are merely arguing over how to define this grammatically? (When you say rgba() and hsla() "should be removed from the spec" you mean just as a distinct grammatical rule, rather than the entire concept?)

If that's the target, this is one way to do it:

<legacy-rgb-syntax> = <percentage>#{3} , <alpha-value>? | <number>#{3} , <alpha-value>?
<modern-rgb-syntax> = [<percentage> | none]{3} [ / [<alpha-value> | none] ]? | [<number> | none]{3} [ / [<alpha-value> | none] ]?
<rgb-function-name> = rgb | rgba
<rgb()> = <rgb-function-name>( [ <legacy-rgb-syntax> | <modern-rgb-syntax> ] )

But if not, this could also work:

<rgb()> = rgb( [ <legacy-rgb-syntax> | <modern-rgb-syntax> ] )
<rgba()> = rgba( [ <legacy-rgb-syntax> | <modern-rgb-syntax> ] )

(And similarly for hsl() and hsla().)

The first option is essentially how I've implemented it.

The second option seems unnecessarily redundant if consensus is not interpretation (a), as it ostensibly requires rgb() and rgba() to be parsed independently.

---

EDIT: Oh, that's exactly what you were saying, isn't it.

[cdoublev]

Oh, that's exactly what you were saying, isn't it.

Yes. I would like to avoid spec readers thinking that rgba() (or hsla()) is entirely legacy...

rgba() is legacy so does not support none. Right?

Wrong :)

... and I would like <rgba()>, <hsla()>, <repeat-*-gradient()>, to be defined with a basic syntax or alternatively, to be removed from any parent production, and defined as non-legacy aliases.

[svgeesus]

@GPHemsley thanks for listing all the differences, for CSS Color 4. Let me add to that: CSS Color 5 adds Relative Color Syntax which for Relative sRGB Colors gives a grammar which extends the modern (comma-less, slash alpha) rgb() function (only).

In Relative HSL Colors there is a clarification:

Relative color syntax is only applicable to the non-legacy HSL syntactic forms.

That isn't needed for HWB, Lab, LCH, Oklab and Oklch which don't have legacy forms but clarification is needed for rgba(). Currently it says

Relative color syntax is only applicable to the non-legacy RGB syntactic forms.

If all rgba() is legacy then it needs to be explicitly excluded from RCS; if the comma-form is legacy and the comma-less, slash alpha form is not legacy then that form needs to be added to the grammar.

Given the way the discussion is going I would argue for the latter option.

[svgeesus]

So in CSS Color 5 we would have

<legacy-rgb-syntax> = <percentage>#{3} , <alpha-value>? | <number>#{3} , <alpha-value>?
<modern-rgb-syntax> = [<percentage> | <number> | none]{3} [ / [<alpha-value> | none] ]? 
<relative-rgb-syntax> = from <color>  <modern-rgb-syntax>
<rgb-function-name> = rgb | rgba
<rgb()> = <rgb-function-name>( [ <legacy-rgb-syntax> | <modern-rgb-syntax> | <relative-rgb-syntax> ] )

Two changes there, one to add RCS and one to make modern syntax accept a mixture of <number> and <percentage>.