[css-color-5] Clarification on scaling ranges of color keyword parameters for relative color #9094
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
|
WPT tests are outdated. All values are numbers (or hue angles as numbers) and there is no scaling or mapping of ranges. see : #8499 |
Yeah there is no basis for this, and the spec warns specifically about assuming this:
So those WPT are wrong. |
chromium-wpt-export-bot
pushed a commit
to web-platform-tests/wpt
that referenced
this issue
Jul 22, 2023
https://csswg.sesse.net/css-color-5/#relative-colors go/rcs-chromium This CL launches RCS behind a flag. Tests are added to the virtual/stable test suite to ensure that it is not accidentally launched on stable. With RCS, color channels can now be math expressions with possible "channel keyword" substitutions. To accomplish this, an optional hash map of {CSSValueID, double} has been added to necessary CSSMathExpressionNode functions. When the parser encounters one of the valid CSSValueIDs it simply returns the associated double instead of failing. This color_channel_keyword_values HashMap could be given a more generic name if it could be useful for other features in the future. With this CL, chrome now passes 94% of 1922 tests for valid/computed relative colors. The remaining failures are mostly problems with the tests themselves, such as the following: w3c/csswg-drafts#9094 This is also the case for the new failures in color-invalid-relative-color.html There are two major TODOs: - calc expressions that mix types are not currently handled. i.e. lab(from magenta calc(l - 20%) a b). - currentcolor as an origin color does not work. The first is hopefully easy to resolve in a follow up CL. The second is not currently handled in any browser and requires some thought, as with currentcolor the values of the channel keywords will not be known at parse time. A possible solution is to simply pass in any random double value for the channel keywords and verify that the expression does indeed parse, but then save that expression and actually parse it at computed value time. Bug: 1447327 Change-Id: I8eb3bc780deb700aa4741ad071b05287c0c0deb3
chromium-wpt-export-bot
pushed a commit
to web-platform-tests/wpt
that referenced
this issue
Jul 22, 2023
https://csswg.sesse.net/css-color-5/#relative-colors go/rcs-chromium This CL launches RCS behind a flag. Tests are added to the virtual/stable test suite to ensure that it is not accidentally launched on stable. With RCS, color channels can now be math expressions with possible "channel keyword" substitutions. To accomplish this, an optional hash map of {CSSValueID, double} has been added to necessary CSSMathExpressionNode functions. When the parser encounters one of the valid CSSValueIDs it simply returns the associated double instead of failing. This color_channel_keyword_values HashMap could be given a more generic name if it could be useful for other features in the future. With this CL, chrome now passes 94% of 1922 tests for valid/computed relative colors. The remaining failures are mostly problems with the tests themselves, such as the following: w3c/csswg-drafts#9094 This is also the case for the new failures in color-invalid-relative-color.html Some basic incorrect tests were changed here. For example, lightness is always clamped to [0, 100]. A fuzzy test for color channels was added to the "valid" test harness, exactly like what already exists in the "computed" version. There are two major TODOs: - calc expressions that mix types are not currently handled. i.e. lab(from magenta calc(l - 20%) a b). - currentcolor as an origin color does not work. The first is hopefully easy to resolve in a follow up CL. The second is not currently handled in any browser and requires some thought, as with currentcolor the values of the channel keywords will not be known at parse time. A possible solution is to simply pass in any random double value for the channel keywords and verify that the expression does indeed parse, but then save that expression and actually parse it at computed value time. Bug: 1447327 Change-Id: I8eb3bc780deb700aa4741ad071b05287c0c0deb3
chromium-wpt-export-bot
pushed a commit
to web-platform-tests/wpt
that referenced
this issue
Jul 22, 2023
https://csswg.sesse.net/css-color-5/#relative-colors go/rcs-chromium This CL launches RCS behind a flag. Tests are added to the virtual/stable test suite to ensure that it is not accidentally launched on stable. With RCS, color channels can now be math expressions with possible "channel keyword" substitutions. To accomplish this, an optional hash map of {CSSValueID, double} has been added to necessary CSSMathExpressionNode functions. When the parser encounters one of the valid CSSValueIDs it simply returns the associated double instead of failing. This color_channel_keyword_values HashMap could be given a more generic name if it could be useful for other features in the future. With this CL, chrome now passes 94% of 1922 tests for valid/computed relative colors. The remaining failures are mostly problems with the tests themselves, such as the following: w3c/csswg-drafts#9094 This is also the case for the new failures in color-invalid-relative-color.html Some basic incorrect tests were changed here. For example, lightness is always clamped to [0, 100]. A fuzzy test for color channels was added to the "valid" test harness, exactly like what already exists in the "computed" version. There are two major TODOs: - calc expressions that mix types are not currently handled. i.e. lab(from magenta calc(l - 20%) a b). - currentcolor as an origin color does not work. The first is hopefully easy to resolve in a follow up CL. The second is not currently handled in any browser and requires some thought, as with currentcolor the values of the channel keywords will not be known at parse time. A possible solution is to simply pass in any random double value for the channel keywords and verify that the expression does indeed parse, but then save that expression and actually parse it at computed value time. Bug: 1447327 Change-Id: I8eb3bc780deb700aa4741ad071b05287c0c0deb3
chromium-wpt-export-bot
pushed a commit
to web-platform-tests/wpt
that referenced
this issue
Jul 25, 2023
https://csswg.sesse.net/css-color-5/#relative-colors go/rcs-chromium This CL launches RCS behind a flag. Tests are added to the virtual/stable test suite to ensure that it is not accidentally launched on stable. With RCS, color channels can now be math expressions with possible "channel keyword" substitutions. To accomplish this, an optional hash map of {CSSValueID, double} has been added to necessary CSSMathExpressionNode functions. When the parser encounters one of the valid CSSValueIDs it simply returns the associated double instead of failing. This color_channel_keyword_values HashMap could be given a more generic name if it could be useful for other features in the future. With this CL, chrome now passes 94% of 1922 tests for valid/computed relative colors. The remaining failures are mostly problems with the tests themselves, such as the following: w3c/csswg-drafts#9094 This is also the case for the new failures in color-invalid-relative-color.html Some basic incorrect tests were changed here. For example, lightness is always clamped to [0, 100]. A fuzzy test for color channels was added to the "valid" test harness, exactly like what already exists in the "computed" version. There are two major TODOs: - calc expressions that mix types are not currently handled. i.e. lab(from magenta calc(l - 20%) a b). - currentcolor as an origin color does not work. The first is hopefully easy to resolve in a follow up CL. The second is not currently handled in any browser and requires some thought, as with currentcolor the values of the channel keywords will not be known at parse time. A possible solution is to simply pass in any random double value for the channel keywords and verify that the expression does indeed parse, but then save that expression and actually parse it at computed value time. Bug: 1447327 Change-Id: I8eb3bc780deb700aa4741ad071b05287c0c0deb3
chromium-wpt-export-bot
pushed a commit
to web-platform-tests/wpt
that referenced
this issue
Jul 29, 2023
https://csswg.sesse.net/css-color-5/#relative-colors go/rcs-chromium This CL launches RCS behind a flag. Tests are added to the virtual/stable test suite to ensure that it is not accidentally launched on stable. With RCS, color channels can now be math expressions with possible "channel keyword" substitutions. To accomplish this, an optional hash map of {CSSValueID, double} has been added to necessary CSSMathExpressionNode functions. When the parser encounters one of the valid CSSValueIDs it simply returns the associated double instead of failing. This color_channel_keyword_values HashMap could be given a more generic name if it could be useful for other features in the future. With this CL, chrome now passes 94% of 1922 tests for valid/computed relative colors. The remaining failures are mostly problems with the tests themselves, such as the following: w3c/csswg-drafts#9094 This is also the case for the new failures in color-invalid-relative-color.html Some basic incorrect tests were changed here. For example, lightness is always clamped to [0, 100]. A fuzzy test for color channels was added to the "valid" test harness, exactly like what already exists in the "computed" version. There are two major TODOs: - calc expressions that mix types are not currently handled. i.e. lab(from magenta calc(l - 20%) a b). - currentcolor as an origin color does not work. The first is hopefully easy to resolve in a follow up CL. The second is not currently handled in any browser and requires some thought, as with currentcolor the values of the channel keywords will not be known at parse time. A possible solution is to simply pass in any random double value for the channel keywords and verify that the expression does indeed parse, but then save that expression and actually parse it at computed value time. Bug: 1447327 Change-Id: I8eb3bc780deb700aa4741ad071b05287c0c0deb3
chromium-wpt-export-bot
pushed a commit
to web-platform-tests/wpt
that referenced
this issue
Jul 31, 2023
https://csswg.sesse.net/css-color-5/#relative-colors go/rcs-chromium This CL launches RCS behind a flag. Tests are added to the virtual/stable test suite to ensure that it is not accidentally launched on stable. With RCS, color channels can now be math expressions with possible "channel keyword" substitutions. To accomplish this, an optional hash map of {CSSValueID, double} has been added to necessary CSSMathExpressionNode functions. When the parser encounters one of the valid CSSValueIDs it simply returns the associated double instead of failing. This color_channel_keyword_values HashMap could be given a more generic name if it could be useful for other features in the future. With this CL, chrome now passes 94% of 1922 tests for valid/computed relative colors. The remaining failures are mostly problems with the tests themselves, such as the following: w3c/csswg-drafts#9094 This is also the case for the new failures in color-invalid-relative-color.html Some basic incorrect tests were changed here. For example, lightness is always clamped to [0, 100]. A fuzzy test for color channels was added to the "valid" test harness, exactly like what already exists in the "computed" version. There are two major TODOs: - calc expressions that mix types are not currently handled. i.e. lab(from magenta calc(l - 20%) a b). - currentcolor as an origin color does not work. The first is hopefully easy to resolve in a follow up CL. The second is not currently handled in any browser and requires some thought, as with currentcolor the values of the channel keywords will not be known at parse time. A possible solution is to simply pass in any random double value for the channel keywords and verify that the expression does indeed parse, but then save that expression and actually parse it at computed value time. Bug: 1447327 Change-Id: I8eb3bc780deb700aa4741ad071b05287c0c0deb3
chromium-wpt-export-bot
pushed a commit
to web-platform-tests/wpt
that referenced
this issue
Aug 7, 2023
https://csswg.sesse.net/css-color-5/#relative-colors go/rcs-chromium This CL launches RCS behind a flag. Tests are added to the virtual/stable test suite to ensure that it is not accidentally launched on stable. With RCS, color channels can now be math expressions with possible "channel keyword" substitutions. To accomplish this, an optional hash map of {CSSValueID, double} has been added to necessary CSSMathExpressionNode functions. When the parser encounters one of the valid CSSValueIDs it simply returns the associated double instead of failing. This color_channel_keyword_values HashMap could be given a more generic name if it could be useful for other features in the future. With this CL, chrome now passes 94% of 1922 tests for valid/computed relative colors. The remaining failures are mostly problems with the tests themselves, such as the following: w3c/csswg-drafts#9094 This is also the case for the new failures in color-invalid-relative-color.html Some basic incorrect tests were changed here. For example, lightness is always clamped to [0, 100]. A fuzzy test for color channels was added to the "valid" test harness, exactly like what already exists in the "computed" version. There are two major TODOs: - calc expressions that mix types are not currently handled. i.e. lab(from magenta calc(l - 20%) a b). - currentcolor as an origin color does not work. The first is hopefully easy to resolve in a follow up CL. The second is not currently handled in any browser and requires some thought, as with currentcolor the values of the channel keywords will not be known at parse time. A possible solution is to simply pass in any random double value for the channel keywords and verify that the expression does indeed parse, but then save that expression and actually parse it at computed value time. Bug: 1447327 Change-Id: I8eb3bc780deb700aa4741ad071b05287c0c0deb3
chromium-wpt-export-bot
pushed a commit
to web-platform-tests/wpt
that referenced
this issue
Aug 15, 2023
https://csswg.sesse.net/css-color-5/#relative-colors go/rcs-chromium This CL launches RCS behind a flag. Tests are added to the virtual/stable test suite to ensure that it is not accidentally launched on stable. With RCS, color channels can now be math expressions with possible "channel keyword" substitutions. To accomplish this, an optional hash map of {CSSValueID, double} has been added to necessary CSSMathExpressionNode functions. When the parser encounters one of the valid CSSValueIDs it simply returns the associated double instead of failing. This color_channel_keyword_values HashMap could be given a more generic name if it could be useful for other features in the future. With this CL, chrome now passes 94% of 1922 tests for valid/computed relative colors. The remaining failures are mostly problems with the tests themselves, such as the following: w3c/csswg-drafts#9094 This is also the case for the new failures in color-invalid-relative-color.html Some basic incorrect tests were changed here. For example, lightness is always clamped to [0, 100]. A fuzzy test for color channels was added to the "valid" test harness, exactly like what already exists in the "computed" version. There are two major TODOs: - calc expressions that mix types are not currently handled. i.e. lab(from magenta calc(l - 20%) a b). - currentcolor as an origin color does not work. The first is hopefully easy to resolve in a follow up CL. The second is not currently handled in any browser and requires some thought, as with currentcolor the values of the channel keywords will not be known at parse time. A possible solution is to simply pass in any random double value for the channel keywords and verify that the expression does indeed parse, but then save that expression and actually parse it at computed value time. Bug: 1447327 Change-Id: I8eb3bc780deb700aa4741ad071b05287c0c0deb3
chromium-wpt-export-bot
pushed a commit
to web-platform-tests/wpt
that referenced
this issue
Aug 16, 2023
https://csswg.sesse.net/css-color-5/#relative-colors go/rcs-chromium This CL launches RCS behind a flag. Tests are added to the virtual/stable test suite to ensure that it is not accidentally launched on stable. With RCS, color channels can now be math expressions with possible "channel keyword" substitutions. To accomplish this, an optional hash map of {CSSValueID, double} has been added to necessary CSSMathExpressionNode functions. When the parser encounters one of the valid CSSValueIDs it simply returns the associated double instead of failing. This color_channel_keyword_values HashMap could be given a more generic name if it could be useful for other features in the future. With this CL, chrome now passes 93% of 1922 tests for valid/computed relative colors. The remaining failures are mostly problems with the tests themselves, such as the following: w3c/csswg-drafts#9094 This is also the case for the new failures in color-invalid-relative-color.html The rebaseline in color-valid-color-mix is an existent failure that should be handled elsewhere (it is only the change in the testharness that is causing the test to fail differently). A fuzzy test for color channels was added to the "valid" test harness, exactly like what already exists in the "computed" version. There are two major TODOs: - calc expressions that mix types are not currently handled. i.e. lab(from magenta calc(l - 20%) a b). - currentcolor as an origin color does not work. The first is hopefully easy to resolve in a follow up CL. The second is not currently handled in any browser and requires some thought, as with currentcolor the values of the channel keywords will not be known at parse time. A possible solution is to simply pass in any random double value for the channel keywords and verify that the expression does indeed parse, but then save that expression and actually parse it at computed value time. Bug: 1447327 Change-Id: I7cf8947253f5b51a9c730f186743a560befd6a5c
chromium-wpt-export-bot
pushed a commit
to web-platform-tests/wpt
that referenced
this issue
Aug 16, 2023
https://csswg.sesse.net/css-color-5/#relative-colors go/rcs-chromium This CL launches RCS behind a flag. Tests are added to the virtual/stable test suite to ensure that it is not accidentally launched on stable. With RCS, color channels can now be math expressions with possible "channel keyword" substitutions. To accomplish this, an optional hash map of {CSSValueID, double} has been added to necessary CSSMathExpressionNode functions. When the parser encounters one of the valid CSSValueIDs it simply returns the associated double instead of failing. This color_channel_keyword_values HashMap could be given a more generic name if it could be useful for other features in the future. With this CL, chrome now passes 93% of 1922 tests for valid/computed relative colors. The remaining failures are mostly problems with the tests themselves, such as the following: w3c/csswg-drafts#9094 This is also the case for the new failures in color-invalid-relative-color.html The rebaseline in color-valid-color-mix is an existent failure that should be handled elsewhere (it is only the change in the testharness that is causing the test to fail differently). A fuzzy test for color channels was added to the "valid" test harness, exactly like what already exists in the "computed" version. There are two major TODOs: - calc expressions that mix types are not currently handled. i.e. lab(from magenta calc(l - 20%) a b). - currentcolor as an origin color does not work. The first is hopefully easy to resolve in a follow up CL. The second is not currently handled in any browser and requires some thought, as with currentcolor the values of the channel keywords will not be known at parse time. A possible solution is to simply pass in any random double value for the channel keywords and verify that the expression does indeed parse, but then save that expression and actually parse it at computed value time. Bug: 1447327 Change-Id: I7cf8947253f5b51a9c730f186743a560befd6a5c
chromium-wpt-export-bot
pushed a commit
to web-platform-tests/wpt
that referenced
this issue
Aug 16, 2023
https://csswg.sesse.net/css-color-5/#relative-colors go/rcs-chromium This CL launches RCS behind a flag. Tests are added to the virtual/stable test suite to ensure that it is not accidentally launched on stable. With RCS, color channels can now be math expressions with possible "channel keyword" substitutions. To accomplish this, an optional hash map of {CSSValueID, double} has been added to necessary CSSMathExpressionNode functions. When the parser encounters one of the valid CSSValueIDs it simply returns the associated double instead of failing. This color_channel_keyword_values HashMap could be given a more generic name if it could be useful for other features in the future. With this CL, chrome now passes 93% of 1922 tests for valid/computed relative colors. The remaining failures are mostly problems with the tests themselves, such as the following: w3c/csswg-drafts#9094 This is also the case for the new failures in color-invalid-relative-color.html The rebaseline in color-valid-color-mix is an existent failure that should be handled elsewhere (it is only the change in the testharness that is causing the test to fail differently). A fuzzy test for color channels was added to the "valid" test harness, exactly like what already exists in the "computed" version. There are two major TODOs: - calc expressions that mix types are not currently handled. i.e. lab(from magenta calc(l - 20%) a b). - currentcolor as an origin color does not work. The first is hopefully easy to resolve in a follow up CL. The second is not currently handled in any browser and requires some thought, as with currentcolor the values of the channel keywords will not be known at parse time. A possible solution is to simply pass in any random double value for the channel keywords and verify that the expression does indeed parse, but then save that expression and actually parse it at computed value time. Bug: 1447327 Change-Id: I7cf8947253f5b51a9c730f186743a560befd6a5c
chromium-wpt-export-bot
pushed a commit
to web-platform-tests/wpt
that referenced
this issue
Aug 17, 2023
https://csswg.sesse.net/css-color-5/#relative-colors go/rcs-chromium This CL launches RCS behind a flag. Tests are added to the virtual/stable test suite to ensure that it is not accidentally launched on stable. With RCS, color channels can now be math expressions with possible "channel keyword" substitutions. To accomplish this, an optional hash map of {CSSValueID, double} has been added to necessary CSSMathExpressionNode functions. When the parser encounters one of the valid CSSValueIDs it simply returns the associated double instead of failing. This color_channel_keyword_values HashMap could be given a more generic name if it could be useful for other features in the future. With this CL, chrome now passes 93% of 1922 tests for valid/computed relative colors. The remaining failures are mostly problems with the tests themselves, such as the following: w3c/csswg-drafts#9094 This is also the case for the new failures in color-invalid-relative-color.html The rebaseline in color-valid-color-mix is an existent failure that should be handled elsewhere (it is only the change in the testharness that is causing the test to fail differently). A fuzzy test for color channels was added to the "valid" test harness, exactly like what already exists in the "computed" version. There are two major TODOs: - calc expressions that mix types are not currently handled. i.e. lab(from magenta calc(l - 20%) a b). - currentcolor as an origin color does not work. The first is hopefully easy to resolve in a follow up CL. The second is not currently handled in any browser and requires some thought, as with currentcolor the values of the channel keywords will not be known at parse time. A possible solution is to simply pass in any random double value for the channel keywords and verify that the expression does indeed parse, but then save that expression and actually parse it at computed value time. Bug: 1447327 Change-Id: I7cf8947253f5b51a9c730f186743a560befd6a5c
chromium-wpt-export-bot
pushed a commit
to web-platform-tests/wpt
that referenced
this issue
Aug 17, 2023
https://csswg.sesse.net/css-color-5/#relative-colors go/rcs-chromium This CL launches RCS behind a flag. Tests are added to the virtual/stable test suite to ensure that it is not accidentally launched on stable. With RCS, color channels can now be math expressions with possible "channel keyword" substitutions. To accomplish this, an optional hash map of {CSSValueID, double} has been added to necessary CSSMathExpressionNode functions. When the parser encounters one of the valid CSSValueIDs it simply returns the associated double instead of failing. This color_channel_keyword_values HashMap could be given a more generic name if it could be useful for other features in the future. With this CL, chrome now passes 93% of 1922 tests for valid/computed relative colors. The remaining failures are mostly problems with the tests themselves, such as the following: w3c/csswg-drafts#9094 This is also the case for the new failures in color-invalid-relative-color.html The rebaseline in color-valid-color-mix is an existent failure that should be handled elsewhere (it is only the change in the testharness that is causing the test to fail differently). A fuzzy test for color channels was added to the "valid" test harness, exactly like what already exists in the "computed" version. There are two major TODOs: - calc expressions that mix types are not currently handled. i.e. lab(from magenta calc(l - 20%) a b). - currentcolor as an origin color does not work. The first is hopefully easy to resolve in a follow up CL. The second is not currently handled in any browser and requires some thought, as with currentcolor the values of the channel keywords will not be known at parse time. A possible solution is to simply pass in any random double value for the channel keywords and verify that the expression does indeed parse, but then save that expression and actually parse it at computed value time. Bug: 1447327 Change-Id: I7cf8947253f5b51a9c730f186743a560befd6a5c
chromium-wpt-export-bot
pushed a commit
to web-platform-tests/wpt
that referenced
this issue
Aug 18, 2023
https://csswg.sesse.net/css-color-5/#relative-colors go/rcs-chromium This CL launches RCS behind a flag. Tests are added to the virtual/stable test suite to ensure that it is not accidentally launched on stable. With RCS, color channels can now be math expressions with possible "channel keyword" substitutions. To accomplish this, an optional hash map of {CSSValueID, double} has been added to necessary CSSMathExpressionNode functions. When the parser encounters one of the valid CSSValueIDs it simply returns the associated double instead of failing. This color_channel_keyword_values HashMap could be given a more generic name if it could be useful for other features in the future. With this CL, chrome now passes 94% of 1922 tests for valid/computed relative colors. The remaining failures are mostly problems with the tests themselves, such as the following: w3c/csswg-drafts#9094 This is also the case for the new failures in color-invalid-relative-color.html Some basic incorrect tests were changed here. For example, lightness is always clamped to [0, 100]. A fuzzy test for color channels was added to the "valid" test harness, exactly like what already exists in the "computed" version. There are two major TODOs: - calc expressions that mix types are not currently handled. i.e. lab(from magenta calc(l - 20%) a b). - currentcolor as an origin color does not work. The first is hopefully easy to resolve in a follow up CL. The second is not currently handled in any browser and requires some thought, as with currentcolor the values of the channel keywords will not be known at parse time. A possible solution is to simply pass in any random double value for the channel keywords and verify that the expression does indeed parse, but then save that expression and actually parse it at computed value time. Bug: 1447327 Change-Id: I8eb3bc780deb700aa4741ad071b05287c0c0deb3
chromium-wpt-export-bot
pushed a commit
to web-platform-tests/wpt
that referenced
this issue
Aug 18, 2023
https://csswg.sesse.net/css-color-5/#relative-colors go/rcs-chromium This CL launches RCS behind a flag. Tests are added to the virtual/stable test suite to ensure that it is not accidentally launched on stable. With RCS, color channels can now be math expressions with possible "channel keyword" substitutions. To accomplish this, an optional hash map of {CSSValueID, double} has been added to necessary CSSMathExpressionNode functions. When the parser encounters one of the valid CSSValueIDs it simply returns the associated double instead of failing. This color_channel_keyword_values HashMap could be given a more generic name if it could be useful for other features in the future. With this CL, chrome now passes 94% of 1922 tests for valid/computed relative colors. The remaining failures are mostly problems with the tests themselves, such as the following: w3c/csswg-drafts#9094 This is also the case for the new failures in color-invalid-relative-color.html Some basic incorrect tests were changed here. For example, lightness is always clamped to [0, 100]. A fuzzy test for color channels was added to the "valid" test harness, exactly like what already exists in the "computed" version. There are two major TODOs: - calc expressions that mix types are not currently handled. i.e. lab(from magenta calc(l - 20%) a b). - currentcolor as an origin color does not work. The first is hopefully easy to resolve in a follow up CL. The second is not currently handled in any browser and requires some thought, as with currentcolor the values of the channel keywords will not be known at parse time. A possible solution is to simply pass in any random double value for the channel keywords and verify that the expression does indeed parse, but then save that expression and actually parse it at computed value time. Bug: 1447327 Change-Id: I8eb3bc780deb700aa4741ad071b05287c0c0deb3
chromium-wpt-export-bot
pushed a commit
to web-platform-tests/wpt
that referenced
this issue
Aug 18, 2023
https://csswg.sesse.net/css-color-5/#relative-colors go/rcs-chromium This CL launches RCS behind a flag. Tests are added to the virtual/stable test suite to ensure that it is not accidentally launched on stable. With RCS, color channels can now be math expressions with possible "channel keyword" substitutions. To accomplish this, an optional hash map of {CSSValueID, double} has been added to necessary CSSMathExpressionNode functions. When the parser encounters one of the valid CSSValueIDs it simply returns the associated double instead of failing. This color_channel_keyword_values HashMap could be given a more generic name if it could be useful for other features in the future. With this CL, chrome now passes 94% of 1922 tests for valid/computed relative colors. The remaining failures are mostly problems with the tests themselves, such as the following: w3c/csswg-drafts#9094 This is also the case for the new failures in color-invalid-relative-color.html Some basic incorrect tests were changed here. For example, lightness is always clamped to [0, 100]. A fuzzy test for color channels was added to the "valid" test harness, exactly like what already exists in the "computed" version. There are two major TODOs: - calc expressions that mix types are not currently handled. i.e. lab(from magenta calc(l - 20%) a b). - currentcolor as an origin color does not work. The first is hopefully easy to resolve in a follow up CL. The second is not currently handled in any browser and requires some thought, as with currentcolor the values of the channel keywords will not be known at parse time. A possible solution is to simply pass in any random double value for the channel keywords and verify that the expression does indeed parse, but then save that expression and actually parse it at computed value time. Bug: 1447327 Change-Id: I8eb3bc780deb700aa4741ad071b05287c0c0deb3
chromium-wpt-export-bot
pushed a commit
to web-platform-tests/wpt
that referenced
this issue
Aug 18, 2023
https://csswg.sesse.net/css-color-5/#relative-colors go/rcs-chromium With this CL, chrome now passes 94% of 1922 tests for valid/computed relative colors. The remaining failures are mostly problems with the tests themselves, such as the following: w3c/csswg-drafts#9094 This is also the case for the new failures in color-invalid-relative-color.html Some basic incorrect tests were changed here. For example, lightness is always clamped to [0, 100]. A fuzzy test for color channels was added to the "valid" test harness, exactly like what already exists in the "computed" version. There are two major TODOs: - calc expressions that mix types are not currently handled. i.e. lab(from magenta calc(l - 20%) a b). - currentcolor as an origin color does not work. The first is hopefully easy to resolve in a follow up CL. The second is not currently handled in any browser and requires some thought, as with currentcolor the values of the channel keywords will not be known at parse time. A possible solution is to simply pass in any random double value for the channel keywords and verify that the expression does indeed parse, but then save that expression and actually parse it at computed value time. Next steps: - Guard the launch with virtual/stable - Go over tests to make sure they are valid and get 100% passing - Return color(srgb ... ) formatted colors for legacy colors - Accomodate currentcolor Bug: 1447327 Change-Id: I8eb3bc780deb700aa4741ad071b05287c0c0deb3
chromium-wpt-export-bot
pushed a commit
to web-platform-tests/wpt
that referenced
this issue
Aug 18, 2023
https://csswg.sesse.net/css-color-5/#relative-colors go/rcs-chromium With this CL, chrome now passes 94% of 1922 tests for valid/computed relative colors. The remaining failures are mostly problems with the tests themselves, such as the following: w3c/csswg-drafts#9094 This is also the case for the new failures in color-invalid-relative-color.html Some basic incorrect tests were changed here. For example, lightness is always clamped to [0, 100]. A fuzzy test for color channels was added to the "valid" test harness, exactly like what already exists in the "computed" version. There are two major TODOs: - calc expressions that mix types are not currently handled. i.e. lab(from magenta calc(l - 20%) a b). - currentcolor as an origin color does not work. The first is hopefully easy to resolve in a follow up CL. The second is not currently handled in any browser and requires some thought, as with currentcolor the values of the channel keywords will not be known at parse time. A possible solution is to simply pass in any random double value for the channel keywords and verify that the expression does indeed parse, but then save that expression and actually parse it at computed value time. Next steps: - Guard the launch with virtual/stable - Go over tests to make sure they are valid and get 100% passing - Return color(srgb ... ) formatted colors for legacy colors - Accomodate currentcolor Bug: 1447327 Change-Id: I8eb3bc780deb700aa4741ad071b05287c0c0deb3
chromium-wpt-export-bot
pushed a commit
to web-platform-tests/wpt
that referenced
this issue
Aug 19, 2023
https://csswg.sesse.net/css-color-5/#relative-colors go/rcs-chromium With this CL, chrome now passes 94% of 1922 tests for valid/computed relative colors. The remaining failures are mostly problems with the tests themselves, such as the following: w3c/csswg-drafts#9094 This is also the case for the new failures in color-invalid-relative-color.html Some basic incorrect tests were changed here. For example, lightness is always clamped to [0, 100]. A fuzzy test for color channels was added to the "valid" test harness, exactly like what already exists in the "computed" version. There are two major TODOs: - calc expressions that mix types are not currently handled. i.e. lab(from magenta calc(l - 20%) a b). - currentcolor as an origin color does not work. The first is hopefully easy to resolve in a follow up CL. The second is not currently handled in any browser and requires some thought, as with currentcolor the values of the channel keywords will not be known at parse time. A possible solution is to simply pass in any random double value for the channel keywords and verify that the expression does indeed parse, but then save that expression and actually parse it at computed value time. Next steps: - Guard the launch with virtual/stable - Go over tests to make sure they are valid and get 100% passing - Return color(srgb ... ) formatted colors for legacy colors - Accomodate currentcolor Bug: 1447327 Change-Id: I8eb3bc780deb700aa4741ad071b05287c0c0deb3
chromium-wpt-export-bot
pushed a commit
to web-platform-tests/wpt
that referenced
this issue
Aug 20, 2023
w3c/csswg-drafts#9094 Change-Id: I9ca3224647a272c214d0e4782ca44912213625ca
aarongable
pushed a commit
to chromium/chromium
that referenced
this issue
Aug 22, 2023
https://drafts.csswg.org/css-color-5/#relative-colors go/rcs-chromium With this CL, chrome now passes 94% of 1922 tests for valid/computed relative colors. The remaining failures are mostly problems with the tests themselves, such as the following: w3c/csswg-drafts#9094 This is also the case for the new failures in color-invalid-relative-color.html Some incorrect tests are changed in other CLs, along with fuzzy color matching for valid tests: https://chromium-review.googlesource.com/c/chromium/src/+/4799569 https://chromium-review.googlesource.com/c/chromium/src/+/4797830 There are two major TODOs: - calc expressions that mix types are not currently handled. i.e. lab(from magenta calc(l - 20%) a b). - currentcolor as an origin color does not work. The first is hopefully easy to resolve in a follow up CL. The second is not currently handled in any browser and requires some thought, as with currentcolor the values of the channel keywords will not be known at parse time. A possible solution is to simply pass in any random double value for the channel keywords and verify that the expression does indeed parse, but then save that expression and actually parse it at computed value time. Next steps: - Guard the launch with virtual/stable - Go over tests to make sure they are valid and get 100% passing - Return color(srgb ... ) formatted colors for legacy colors - Accomodate currentcolor Bug: 1447327 Change-Id: I8eb3bc780deb700aa4741ad071b05287c0c0deb3 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4690403 Reviewed-by: Xiaocheng Hu <xiaochengh@chromium.org> Commit-Queue: Aaron Krajeski <aaronhk@chromium.org> Reviewed-by: Rune Lillesveen <futhark@chromium.org> Cr-Commit-Position: refs/heads/main@{#1186740}
chromium-wpt-export-bot
pushed a commit
to web-platform-tests/wpt
that referenced
this issue
Aug 22, 2023
w3c/csswg-drafts#9094 Change-Id: I9ca3224647a272c214d0e4782ca44912213625ca
aarongable
pushed a commit
to chromium/chromium
that referenced
this issue
Aug 23, 2023
w3c/csswg-drafts#9094 Change-Id: I9ca3224647a272c214d0e4782ca44912213625ca Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4794880 Commit-Queue: Aaron Krajeski <aaronhk@chromium.org> Reviewed-by: Rune Lillesveen <futhark@chromium.org> Cr-Commit-Position: refs/heads/main@{#1187223}
chromium-wpt-export-bot
pushed a commit
to web-platform-tests/wpt
that referenced
this issue
Aug 23, 2023
w3c/csswg-drafts#9094 Change-Id: I9ca3224647a272c214d0e4782ca44912213625ca Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4794880 Commit-Queue: Aaron Krajeski <aaronhk@chromium.org> Reviewed-by: Rune Lillesveen <futhark@chromium.org> Cr-Commit-Position: refs/heads/main@{#1187223}
chromium-wpt-export-bot
pushed a commit
to web-platform-tests/wpt
that referenced
this issue
Aug 23, 2023
w3c/csswg-drafts#9094 Change-Id: I9ca3224647a272c214d0e4782ca44912213625ca Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4794880 Commit-Queue: Aaron Krajeski <aaronhk@chromium.org> Reviewed-by: Rune Lillesveen <futhark@chromium.org> Cr-Commit-Position: refs/heads/main@{#1187223}
chromium-wpt-export-bot
pushed a commit
to web-platform-tests/wpt
that referenced
this issue
Aug 28, 2023
See: w3c/csswg-drafts#9094 """ All values are numbers (or hue angles as numbers) and there is no scaling or mapping of ranges. """ From: https://drafts.csswg.org/css-color-5/#ex-no-percentage-magic """ Beware when using components outside their normal position; when percentages are resolved, there is no "magic scaling" to account for the changed position. """ Since all values are numbers, any parameter can be matched with any other. These changes make color-invalid-relative-color-expected.txt in virtual/stable redundant, as it was all PASS. Bug: 1447327 Change-Id: I674da3f953e0ce336757b593beb6c205528e7800
chromium-wpt-export-bot
pushed a commit
to web-platform-tests/wpt
that referenced
this issue
Aug 30, 2023
See: w3c/csswg-drafts#9094 """ All values are numbers (or hue angles as numbers) and there is no scaling or mapping of ranges. """ From: https://drafts.csswg.org/css-color-5/#ex-no-percentage-magic """ Beware when using components outside their normal position; when percentages are resolved, there is no "magic scaling" to account for the changed position. """ Since all values are numbers, any parameter can be matched with any other. These changes make color-invalid-relative-color-expected.txt in virtual/stable redundant, as it was all PASS. Bug: 1447327 Change-Id: I674da3f953e0ce336757b593beb6c205528e7800
chromium-wpt-export-bot
pushed a commit
to web-platform-tests/wpt
that referenced
this issue
Aug 30, 2023
See: w3c/csswg-drafts#9094 """ All values are numbers (or hue angles as numbers) and there is no scaling or mapping of ranges. """ From: https://drafts.csswg.org/css-color-5/#ex-no-percentage-magic """ Beware when using components outside their normal position; when percentages are resolved, there is no "magic scaling" to account for the changed position. """ Since all values are numbers, any parameter can be matched with any other. These changes make color-invalid-relative-color-expected.txt in virtual/stable redundant, as it was all PASS. Bug: 1447327 Change-Id: I674da3f953e0ce336757b593beb6c205528e7800 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4817175 Reviewed-by: Rune Lillesveen <futhark@chromium.org> Commit-Queue: Aaron Krajeski <aaronhk@chromium.org> Cr-Commit-Position: refs/heads/main@{#1190137}
chromium-wpt-export-bot
pushed a commit
to web-platform-tests/wpt
that referenced
this issue
Aug 30, 2023
See: w3c/csswg-drafts#9094 """ All values are numbers (or hue angles as numbers) and there is no scaling or mapping of ranges. """ From: https://drafts.csswg.org/css-color-5/#ex-no-percentage-magic """ Beware when using components outside their normal position; when percentages are resolved, there is no "magic scaling" to account for the changed position. """ Since all values are numbers, any parameter can be matched with any other. These changes make color-invalid-relative-color-expected.txt in virtual/stable redundant, as it was all PASS. Bug: 1447327 Change-Id: I674da3f953e0ce336757b593beb6c205528e7800 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4817175 Reviewed-by: Rune Lillesveen <futhark@chromium.org> Commit-Queue: Aaron Krajeski <aaronhk@chromium.org> Cr-Commit-Position: refs/heads/main@{#1190137}
moz-v2v-gh
pushed a commit
to mozilla/gecko-dev
that referenced
this issue
Sep 13, 2023
…range scaling, a=testonly Automatic update from web-platform-tests Remove relative color tests that assume range scaling w3c/csswg-drafts#9094 Change-Id: I9ca3224647a272c214d0e4782ca44912213625ca Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4794880 Commit-Queue: Aaron Krajeski <aaronhk@chromium.org> Reviewed-by: Rune Lillesveen <futhark@chromium.org> Cr-Commit-Position: refs/heads/main@{#1187223} -- wpt-commits: faf22d0d4125f7f9342bfac01289c26483be289a wpt-pr: 41548
moz-v2v-gh
pushed a commit
to mozilla/gecko-dev
that referenced
this issue
Sep 13, 2023
…ive color syntax, a=testonly Automatic update from web-platform-tests Permuting types is not invalid for relative color syntax See: w3c/csswg-drafts#9094 """ All values are numbers (or hue angles as numbers) and there is no scaling or mapping of ranges. """ From: https://drafts.csswg.org/css-color-5/#ex-no-percentage-magic """ Beware when using components outside their normal position; when percentages are resolved, there is no "magic scaling" to account for the changed position. """ Since all values are numbers, any parameter can be matched with any other. These changes make color-invalid-relative-color-expected.txt in virtual/stable redundant, as it was all PASS. Bug: 1447327 Change-Id: I674da3f953e0ce336757b593beb6c205528e7800 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4817175 Reviewed-by: Rune Lillesveen <futhark@chromium.org> Commit-Queue: Aaron Krajeski <aaronhk@chromium.org> Cr-Commit-Position: refs/heads/main@{#1190137} -- wpt-commits: f78f1aa35bb02f39c7667112903a9efc868399c4 wpt-pr: 41674
vinnydiehl
pushed a commit
to vinnydiehl/mozilla-unified
that referenced
this issue
Sep 14, 2023
…range scaling, a=testonly Automatic update from web-platform-tests Remove relative color tests that assume range scaling w3c/csswg-drafts#9094 Change-Id: I9ca3224647a272c214d0e4782ca44912213625ca Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4794880 Commit-Queue: Aaron Krajeski <aaronhk@chromium.org> Reviewed-by: Rune Lillesveen <futhark@chromium.org> Cr-Commit-Position: refs/heads/main@{#1187223} -- wpt-commits: faf22d0d4125f7f9342bfac01289c26483be289a wpt-pr: 41548
vinnydiehl
pushed a commit
to vinnydiehl/mozilla-unified
that referenced
this issue
Sep 14, 2023
…ive color syntax, a=testonly Automatic update from web-platform-tests Permuting types is not invalid for relative color syntax See: w3c/csswg-drafts#9094 """ All values are numbers (or hue angles as numbers) and there is no scaling or mapping of ranges. """ From: https://drafts.csswg.org/css-color-5/#ex-no-percentage-magic """ Beware when using components outside their normal position; when percentages are resolved, there is no "magic scaling" to account for the changed position. """ Since all values are numbers, any parameter can be matched with any other. These changes make color-invalid-relative-color-expected.txt in virtual/stable redundant, as it was all PASS. Bug: 1447327 Change-Id: I674da3f953e0ce336757b593beb6c205528e7800 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4817175 Reviewed-by: Rune Lillesveen <futhark@chromium.org> Commit-Queue: Aaron Krajeski <aaronhk@chromium.org> Cr-Commit-Position: refs/heads/main@{#1190137} -- wpt-commits: f78f1aa35bb02f39c7667112903a9efc868399c4 wpt-pr: 41674
|
Looks like the tests have all been cleaned up (thanks for that!), so this can be closed. |
svgeesus
added
the
Closed as Question Answered
Lightning00Blade
pushed a commit
to Lightning00Blade/wpt
that referenced
this issue
Dec 11, 2023
w3c/csswg-drafts#9094 Change-Id: I9ca3224647a272c214d0e4782ca44912213625ca Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4794880 Commit-Queue: Aaron Krajeski <aaronhk@chromium.org> Reviewed-by: Rune Lillesveen <futhark@chromium.org> Cr-Commit-Position: refs/heads/main@{#1187223}
Lightning00Blade
pushed a commit
to Lightning00Blade/wpt
that referenced
this issue
Dec 11, 2023
See: w3c/csswg-drafts#9094 """ All values are numbers (or hue angles as numbers) and there is no scaling or mapping of ranges. """ From: https://drafts.csswg.org/css-color-5/#ex-no-percentage-magic """ Beware when using components outside their normal position; when percentages are resolved, there is no "magic scaling" to account for the changed position. """ Since all values are numbers, any parameter can be matched with any other. These changes make color-invalid-relative-color-expected.txt in virtual/stable redundant, as it was all PASS. Bug: 1447327 Change-Id: I674da3f953e0ce336757b593beb6c205528e7800 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4817175 Reviewed-by: Rune Lillesveen <futhark@chromium.org> Commit-Queue: Aaron Krajeski <aaronhk@chromium.org> Cr-Commit-Position: refs/heads/main@{#1190137}
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Some web platform tests assume that an alpha of 1, when passed to the lightness channel of
lab/lch, should result in a lightness value of 100:https://github.com/web-platform-tests/wpt/blob/master/css/css-color/parsing/color-valid-relative-color.html#L420
It appears that the logic for this is that the [0, 1] range for alpha should be mapped onto the [0, 100] range for lightness. I see nothing in the spec stating this should be the case:
https://csswg.sesse.net/css-color-5/#relative-colors
https://csswg.sesse.net/css-color-5/#relative-Lab
In fact, this text seems to imply that numbers are not remapped/normalized:
If color keywords inputs were to be mapped to their ranges, many tests are missing from wpt, for example:
lightnessto other components.hueangle.ainlabmaps to a raw value of 125, shouldavalues then be normalized as if they are in the range [0, 125]?oklab, but with the range [0, 0.4]Given that the spec is not explicit about this behavior and it is non-trivial, am I correct in assuming the aforementioned tests are incorrect?
web-platform-tests/wpt#41113
The text was updated successfully, but these errors were encountered: