Good question, and the answer is a bit more complicated than a simple yes or no.

We now define a legacy color syntax, which originally was simply a comma vs space-and-slash difference.

On the positive side, the legacy syntaxes are implemented widely and reach back to earlier browser versions so content developers who are required to support incredibly old browser versions for whatever reason are advised to use them. That broad support is also why we serialize in legacy syntax, using either rgb() or rgba() depending on whether the alpha is exactly one. That maximizes compatibility with older scripts that assume rgb() never has alpha, for example. For similar backwards-compatibility reasons, we ensure that component values which can be exactly serialized as integer are serialized that way.

On the negative side, there is an increasing list of things that modern color syntax can do, which legacy syntax cannot:

• can't use none for missing values (0 is used instead)
• can't mix percent and number, must use one or the other
• don't reliably preserve more than 8 bits per component

That list gets bigger in CSS Color 5, relative colors

• relative colors can only use the modern syntax (although the origin color can use any syntax, including legacy)

And thus, for new color syntaxes that don't have a web-compat legacy, we only define the modern syntax because we expect all of these additional things to always work.

Moving on to your specific questions:

Are rgba() and hsla() already deprecated?

Remember, deprecated means "don't use in new content" not "will stop working".

So they can certainly continue to be used, even if we did deprecate them, which we have not. Provided that none of the new features are needed.

Should we ask developers not to use them in new code?

If it doesn't make a difference then yes, encourage new developers, and developers of new code, to use the modern syntax. That way, if they want to set an hsl() hue to missing, or want to make a new hsl() color using calc, they don't need to discover that it doesn't work (and that the fix, mysteriously, is to get rid of commas).

The MDN team is fairly clear that the comma-list syntax is discouraged. Our question is whether there's any reason to prefer between rgb(1 1 1 / 0.5) and rgba(1 1 1 / 0.5), in which case there's really no syntax limitations difference.

There is a slight preference for rgb() when authoring (but you will get rgba() back when serializing).

When serializing I'm getting the legacy comma-list syntax anyway, right? Is there any reason for this preference that's relevant to developers, or is it just for consistency with other color functions?

When serializing I'm getting the legacy comma-list syntax anyway, right?

Yes

Is there any reason for this preference that's relevant to developers, or is it just for consistency with other color functions?

The relevance is that changing the hue to missing in hsl(60 5% 50% /0.9) is hsl(none 5% 50% /0.9) while changing it in hsl(60, 5%, 50%, 0.9) is ... also hsl(none 5% 50% /0.9) which may be surprising.

And also that hsl(from green, h, calc(s *.0.8), l) will not work but hsl(from green, h calc(s *.0.8) l) will.

I think I'm still not making myself clear.

There are four ways to write colors:

1. rgb(1 1 1 / 0.5)
2. rgba(1 1 1 / 0.5)
3. rgb(1, 1, 1, 0.5)
4. rgba(1, 1, 1, 0.5)

Right now, we are on board with dissuading people from using 3 and 4, due to the limitations you mentioned about none, relative colors, mixed percentages, etc. I'm asking whether there's any tangible reason to discourage the use of 2, or whether preference of 1 over 2, or the other way, is purely stylistic.

I see. No, both will work and mean exactly the same.

While they work and mean exactly the same, I'd still say authors should be encouraged to use rgb() and hsl() over rgba() and hsla(), because that's more consistent with newer color functions which don't have ...a() aliases.

Maybe rgba(), hsla(), and the legacy syntaxes should officially be labeled as "deprecated" in the spec. to discourage their usage (while they will have to be supported forever for web compat, of course).

Sebastian