Re: [csswg-drafts] [css-color-4] Concerns about color() function fallback (#5931)

Yesterday I took Safari Preview 121 through the CSS Color 4 testsuite. The [results](https://test.csswg.org/harness/results/css-color-4_dev/grouped/) now show two implementations, BFO Publisher and Safari, passing almost all tests (Spec test coverage is not complete though). BFO skips the tests that require scripting. Relevant to this issue, Safari fails on two tests which exercise `color()` fallback.

predefined-015.htm has a valid first color and a red fallback, the pass is "green no red"

```css
    .test { background-color: red; width: 12em; height: 6em; margin-top:0}
    .ref { background-color: #009900; width: 12em; height: 6em; margin-bottom: 0}
    .test {background-color: color(display-p3 0.26374 0.59085 0.16434, red)}
```
predefined-014.htm has an invalid first color and a green fallback, again the pass is "green no red"

```css
    .test { background-color: red; width: 12em; height: 6em; margin-top:0}
    .ref { background-color: #009900; width: 12em; height: 6em; margin-bottom: 0}
    .test {background-color: color(banana 0.1 0.2 0.3, #009900)}
```

I deduce therefore that Safari does not currently implement the falback _at all_, (which is a reasonable decision at this point) so -15 fails just because the parser hits a comma instead of a closing paren.

BFO Publisher passes both those tests.

So again I think removing the fallback syntax from `color()` and using the existing CSS facilities of stylesheet order, conditionally set custom properties, `@media` queries, and `@supports` gives better fallback without cluttering the syntax and implementation complexity.






-- 
GitHub Notification of comment by svgeesus
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5931#issuecomment-797648014 using your GitHub account


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

Received on Friday, 12 March 2021 17:41:30 UTC