[csswg-drafts] [css-color] Clamping alpha at computed-value time vs parsing time (#7677)

mysteryDate has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-color] Clamping alpha at computed-value time vs parsing time ==
From https://www.w3.org/TR/css-color-4/#rgb-functions:

> The final argument, the <alpha-value>, specifies the alpha of the color. If given as a <number>, the useful range of the value is 0 (representing a fully transparent color) to 1 (representing a fully opaque color). If given as a <percentage>, 0% represents a fully transparent color, while 100% represents a fully opaque color. If omitted, it defaults to 100%.
> Values outside these ranges are not invalid, but are clamped to the ranges defined here at computed-value time.

All user agents I've tested in fact do the clamping at parsing time:
```
  <!doctype html>
  <style>
    #target {
          color: rgba(400, 400, 300, -300);
    }
  </style>
  <div id="target"></div>
  <pre id="res"></pre>
  <script>
    res.innerText = "specified: " + document.styleSheets[0].cssRules[0].style.color + "\ncomputed: " + getComputedStyle(target).color;
  </script>
  ```
Firefox, Safari and Chrome all give "specified: rgba(255, 255, 255, 0)"

Is there a disadvantage to just doing the clamping at parsing time? It is easier to implement and is already the behavior that we're living with.


Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7677 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Friday, 2 September 2022 15:36:30 UTC