[css-color-5] Interpolation of system color keywords #5780
Labels
Closed as Question Answered
Used when the issue is more of a question than a problem, and it's been answered.
css-color-5
Color modification
Comments
Hm? That's definitely not what Firefox does. What Firefox does for currentcolor is effectively That is observable via inheritance. I guess inheritance is less of an issue for system color keywords though? cc @upsuper |
Whoops, you're right. I should have tested this myself before commenting on it. Thanks for pointing it out. |
moz-v2v-gh
pushed a commit
to mozilla/gecko-dev
that referenced
this issue
Oct 30, 2021
…re. r=dholbert For that, add `.dark` version of the browser.display* prefs that control the light version of these colors. The default for background/foreground colors are taken from the GenericDarkColors used in LookAndFeel. The defaults for links are based on this discussion: whatwg/html#5426 (comment) (So they effectively match Chrome). Whether the dark colors should be exposed in about:preferences (like the light colors are) is TBD. With this patch, we pass all the tests in: /html/semantics/document-metadata/the-meta-element/color-scheme/ Use the colors to paint the default canvas background and the default colors. There are three "regressions", though they are really progressions: we now render the reference as the test expects (before we rendered a light canvas background even for the reference). Apart of these iframe tests (which we should look into, I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1738380), there are three remaining test failures. Two of them are due to `color: initial` not changing based on the color-scheme. Safari also fails these tests, and the thing they're really testing is whether system colors are preserved at computed-value time: w3c/csswg-drafts#3847 Regarding that change, I'm not so sure the trade-offs there are worth it, as that not only complicates interpolation (we wouldn't be able to use system colors in color-mix among others, see w3c/csswg-drafts#5780) plus it changes inheritance behavior in sorta unexpected ways, see: w3c/csswg-drafts#6773 Which I just filed because apparently no browser implements this correctly. So for now will punt on those (keep matching Safari). There's an svg-as-image test: https://searchfox.org/mozilla-central/rev/f8576fec48d866c5f988baaf1fa8d2f8cce2a82f/testing/web-platform/tests/css/css-color-adjust/rendering/dark-color-scheme/svg-as-image.html Which isn't using the feature at all and I'm not sure why is it supposed to pass (why prefers-color-scheme: dark is supposed to match that SVG image). This test fails in all browsers apparently: https://wpt.fyi/results/css/css-color-adjust/rendering/dark-color-scheme/svg-as-image.html?label=master&label=experimental&aligned I sent web-platform-tests/wpt#31407 to remove it and hopefully get it reviewed by some Chromium folks. Differential Revision: https://phabricator.services.mozilla.com/D129746
jamienicol
pushed a commit
to jamienicol/gecko
that referenced
this issue
Nov 1, 2021
…re. r=dholbert For that, add `.dark` version of the browser.display* prefs that control the light version of these colors. The default for background/foreground colors are taken from the GenericDarkColors used in LookAndFeel. The defaults for links are based on this discussion: whatwg/html#5426 (comment) (So they effectively match Chrome). Whether the dark colors should be exposed in about:preferences (like the light colors are) is TBD. With this patch, we pass all the tests in: /html/semantics/document-metadata/the-meta-element/color-scheme/ Use the colors to paint the default canvas background and the default colors. There are three "regressions", though they are really progressions: we now render the reference as the test expects (before we rendered a light canvas background even for the reference). Apart of these iframe tests (which we should look into, I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1738380), there are three remaining test failures. Two of them are due to `color: initial` not changing based on the color-scheme. Safari also fails these tests, and the thing they're really testing is whether system colors are preserved at computed-value time: w3c/csswg-drafts#3847 Regarding that change, I'm not so sure the trade-offs there are worth it, as that not only complicates interpolation (we wouldn't be able to use system colors in color-mix among others, see w3c/csswg-drafts#5780) plus it changes inheritance behavior in sorta unexpected ways, see: w3c/csswg-drafts#6773 Which I just filed because apparently no browser implements this correctly. So for now will punt on those (keep matching Safari). There's an svg-as-image test: https://searchfox.org/mozilla-central/rev/f8576fec48d866c5f988baaf1fa8d2f8cce2a82f/testing/web-platform/tests/css/css-color-adjust/rendering/dark-color-scheme/svg-as-image.html Which isn't using the feature at all and I'm not sure why is it supposed to pass (why prefers-color-scheme: dark is supposed to match that SVG image). This test fails in all browsers apparently: https://wpt.fyi/results/css/css-color-adjust/rendering/dark-color-scheme/svg-as-image.html?label=master&label=experimental&aligned I sent web-platform-tests/wpt#31407 to remove it and hopefully get it reviewed by some Chromium folks. Differential Revision: https://phabricator.services.mozilla.com/D129746
|
@kbabbitt @emilio so [in CSS Color 4] we still have:
followed by a link to #445 where I said:
It sounds like, instead of the used values, the proposal is that the result of `color-mix() would need to be:
This seems very complex and heavyweight. Do I understand the proposal correctly? |
|
That's correct, tho most of those would be zero in anything but specially-constructed hostile examples. |
So TypedOM would return a 19-element array, most of which is zeroes? |
|
Right, and this also affects the long-running #445 We seem to have been kicking these related issues around for a while and I want to see them resolved one way or the other |
No? It would, I assume, have a list of color/% pairs, as many as needed to represent the value. The abstract computed value doesn't have a 1:1 correspondence to what we serialize or reify. (and it might simplify further, as Emilio said) |
|
This is now a non-issue due to the resolution of |
svgeesus
added
the
Closed as Question Answered
Loirooriol
pushed a commit
to Loirooriol/servo
that referenced
this issue
May 30, 2023
For that, add `.dark` version of the browser.display* prefs that control the light version of these colors. The default for background/foreground colors are taken from the GenericDarkColors used in LookAndFeel. The defaults for links are based on this discussion: whatwg/html#5426 (comment) (So they effectively match Chrome). Whether the dark colors should be exposed in about:preferences (like the light colors are) is TBD. With this patch, we pass all the tests in: /html/semantics/document-metadata/the-meta-element/color-scheme/ Use the colors to paint the default canvas background and the default colors. There are three "regressions", though they are really progressions: we now render the reference as the test expects (before we rendered a light canvas background even for the reference). Apart of these iframe tests (which we should look into, I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1738380), there are three remaining test failures. Two of them are due to `color: initial` not changing based on the color-scheme. Safari also fails these tests, and the thing they're really testing is whether system colors are preserved at computed-value time: w3c/csswg-drafts#3847 Regarding that change, I'm not so sure the trade-offs there are worth it, as that not only complicates interpolation (we wouldn't be able to use system colors in color-mix among others, see w3c/csswg-drafts#5780) plus it changes inheritance behavior in sorta unexpected ways, see: w3c/csswg-drafts#6773 Which I just filed because apparently no browser implements this correctly. So for now will punt on those (keep matching Safari). There's an svg-as-image test: https://searchfox.org/mozilla-central/rev/f8576fec48d866c5f988baaf1fa8d2f8cce2a82f/testing/web-platform/tests/css/css-color-adjust/rendering/dark-color-scheme/svg-as-image.html Which isn't using the feature at all and I'm not sure why is it supposed to pass (why prefers-color-scheme: dark is supposed to match that SVG image). This test fails in all browsers apparently: https://wpt.fyi/results/css/css-color-adjust/rendering/dark-color-scheme/svg-as-image.html?label=master&label=experimental&aligned I sent web-platform-tests/wpt#31407 to remove it and hopefully get it reviewed by some Chromium folks. Differential Revision: https://phabricator.services.mozilla.com/D129746
Loirooriol
pushed a commit
to Loirooriol/servo
that referenced
this issue
May 30, 2023
For that, add `.dark` version of the browser.display* prefs that control the light version of these colors. The default for background/foreground colors are taken from the GenericDarkColors used in LookAndFeel. The defaults for links are based on this discussion: whatwg/html#5426 (comment) (So they effectively match Chrome). Whether the dark colors should be exposed in about:preferences (like the light colors are) is TBD. With this patch, we pass all the tests in: /html/semantics/document-metadata/the-meta-element/color-scheme/ Use the colors to paint the default canvas background and the default colors. There are three "regressions", though they are really progressions: we now render the reference as the test expects (before we rendered a light canvas background even for the reference). Apart of these iframe tests (which we should look into, I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1738380), there are three remaining test failures. Two of them are due to `color: initial` not changing based on the color-scheme. Safari also fails these tests, and the thing they're really testing is whether system colors are preserved at computed-value time: w3c/csswg-drafts#3847 Regarding that change, I'm not so sure the trade-offs there are worth it, as that not only complicates interpolation (we wouldn't be able to use system colors in color-mix among others, see w3c/csswg-drafts#5780) plus it changes inheritance behavior in sorta unexpected ways, see: w3c/csswg-drafts#6773 Which I just filed because apparently no browser implements this correctly. So for now will punt on those (keep matching Safari). There's an svg-as-image test: https://searchfox.org/mozilla-central/rev/f8576fec48d866c5f988baaf1fa8d2f8cce2a82f/testing/web-platform/tests/css/css-color-adjust/rendering/dark-color-scheme/svg-as-image.html Which isn't using the feature at all and I'm not sure why is it supposed to pass (why prefers-color-scheme: dark is supposed to match that SVG image). This test fails in all browsers apparently: https://wpt.fyi/results/css/css-color-adjust/rendering/dark-color-scheme/svg-as-image.html?label=master&label=experimental&aligned I sent web-platform-tests/wpt#31407 to remove it and hopefully get it reviewed by some Chromium folks. Differential Revision: https://phabricator.services.mozilla.com/D129746
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
#3847 resolved that system color keywords should compute to themselves. There was a question left open regarding interpolation. There have been fragments of further discussion around this, but I haven't seen a formalized resolution, so I wanted to raise it as its own issue.
#3847 (comment) suggested that system colors should be treated the same as currentcolor: convert to a used value and interpolate based on that, per https://drafts.csswg.org/css-color-5/#interpolation:
#5392 (comment) suggested using color-mix() to interpolate between system color keywords. For example, if we're running an interpolation between the system color keywords
canvasandmenu, and the timing function just returned a value of 0.4, the interpolated value would becolor-mix(canvas 40%, menu).Though the color-mix() suggestion was mine, I'm not particularly attached to it. The "resolve to used value" behavior seems less likely to introduce compat issues, and after implementing #3847 in Blink behind a flag, I discovered that it already had the "resolve to used value" behavior.
Either way, I'm hoping we can get the desired behavior covered in the spec. What does the working group think?
The text was updated successfully, but these errors were encountered: