[css-color-5] unclamped alpha through RCS

[romainmenke]

see : #9759 (comment)

@svgeesus said :

the whole reason we added the serialization of RCS rgb(), hsl() and hwb() to color(srgb) specifically to enable round-tripping of out of gamut values. But the text from CSS Color 4 that I quoted above prevents that, which means that CSS Color 5 needs to specifically say that RCS versions of those color functions do not clamp out of range values. And then, do we really want unclamped alpha values like that?

---

I kept coming back to this.
I initially concluded that this behavior isn't useful.

But I wanted to have a better understanding of the implication of either mode.

---

I think there are 2 cases where an unclamped alpha could be observable:

1. calc expressions in RCS
2. interpolation

I might be wrong here

https://codepen.io/romainmenke/pen/dyrvGoz

calc expressions in RCS

rgb(
  /* produce an alpha higher than 1 */
  from rgb(from red r g b / r)
  /* make it smaller */
  r g b / calc(alpha / 2))

If the value is clamped then the result must be 0.5, if it is unclamped it must be 1.

interpolation

color-mix(
  in srgb,
  /* produce an alpha higher than 1 */
  rgb(from red r g b / r),
  /* mix it with something semi-transparent */
  rgb(50% 50% 50% / 0.5) 90%
)

If the value is clamped then the result must be rgba(151, 104, 104, 0.55), if it is unclamped then it must be rgb(253, 2, 2).

Other channels are also affected because premultiplying by alpha will have very different results.

---

Compared to other channels which aren't clamped:

https://codepen.io/romainmenke/pen/OJqpMgr

Best viewed in Chrome as that implementation is more up to date

---

I do think that it is observable that alpha is clamped or not in RCS but I still don't think it enables authors to do something useful.

While clamping will almost always produce the results you would intuitively expect.

There also seems to be interop for clamping alpha in RCS.

@svgeesus thoughts?

[svgeesus]

@LeaVerou I am still of the opinion that unclamped alpha in RCS is an unexpected and unwanted side effect of unclamped color components. And unlike those, where unclamped color components serves a useful purpose (prevents cumulative premature gamut clamping and thus hue drift etc) unclamped alpha is surprising and only noticeable in contrived test cases like setting alpha to 127 and then RCS uses alpha as the green channel to get a nice testable "green pass". What do you think?

[LeaVerou]

So it seems that lots of good things come from clamping alpha. What are the arguments against clamping?

[svgeesus]

None, it happened by accident ¯\_(ツ)_/¯

[romainmenke]

Did it actually happen?

I thought this was mainly something that wasn't fully explored and was maybe lacking some WPT tests.

As far as I can tell both Safari and Chrome clamp alpha.
I also think the spec is quite clear and doesn't imply that alpha isn't clamped.

So could be as simple as adding an extra test and closing this? :)

[svgeesus]

Did it actually happen?

Color 4 says that for rgb(), for r, g, b, and alpha:

Values outside these ranges are not invalid, but are clamped to the ranges defined here at parsed-value time.

and for Lab, LH and friends it says

In Lab, the first argument specifies the CIE Lightness, L. This is a number between 0% or 0 and 100% or 100 Values less than 0% or 0 must be clamped to 0% at parsed-value time; values greater than 100% or 100 are clamped to 100% at parsed-value time.

and does not specify any clamping for a, b, C, H or alpha.

So RCS, which is currently silent about clamping, needs to say that there is no clamping of color components. And that there is clamping of alpha.

And yes, WPT tests would be great once there is a testable assertion in the spec that they can point to.

[svgeesus]

How does that look?

Edit: Now live in the spec

[romainmenke]

Thank you for the speedy edits @svgeesus,

Text is clear to me.
The examples had two typo's but were otherwise good representations of the behavior.