Relative Color Syntax (RCS)#41479
Closed
chromium-wpt-export-bot wants to merge 1 commit intomasterfrom
Closed
Conversation
wpt-pr-bot
approved these changes
Aug 15, 2023
Collaborator
wpt-pr-bot
left a comment
There was a problem hiding this comment.
The review process for this patch is being conducted in the Chromium project.
f357ae7 to
af1b7e5
Compare
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
af1b7e5 to
581d0e7
Compare
Collaborator
Author
|
Close this PR because the Chromium CL has been abandoned. |
servo-wpt-sync
pushed a commit
to servo/wpt
that referenced
this pull request
Jan 28, 2026
Per CSS-CONTENT-3, one of the possible values of the `content` CSS property is `<content-replacement>`, which evaluates to a single `<image>`. This value is also allowed on regular elements, not just on pseudo-elements, and it will make the element into a replaced element representing the given image, discarding its contents. This patch implements this in `traverse_element`: if the `display` value is not `none` or `contents`, we first check whether the `contents` property should make the element replaced, and if it shouldn't, then we check whether the element itself is replaced or a widget. Per the spec, an invalid image must be treated as representing a transparent black image with zero natural width and height – in particular, it must not show a broken image icon. We added the method `ReplacedContents::zero_sized_invalid_image` to implement this. This patch adds support for image URL references, but not for color gradients, which are treated as invalid images. The reason for this is that currently Servo does not support gradients in `ReplacedContentKind`. This is left as a follow-up change. Testing: Existing `css/css-content/element-replacement*` WPT tests that now pass with this patch. `element-replacement-gradient.html` still fails because this patch does not add support for gradients. Fixes: web-platform-tests#41479 Signed-off-by: Andreu Botella <[email protected]>
servo-wpt-sync
pushed a commit
to servo/wpt
that referenced
this pull request
Jan 28, 2026
Per CSS-CONTENT-3, one of the possible values of the `content` CSS property is `<content-replacement>`, which evaluates to a single `<image>`. This value is also allowed on regular elements, not just on pseudo-elements, and it will make the element into a replaced element representing the given image, discarding its contents. This patch implements this in `traverse_element`: if the `display` value is not `none` or `contents`, we first check whether the `contents` property should make the element replaced, and if it shouldn't, then we check whether the element itself is replaced or a widget. Per the spec, an invalid image must be treated as representing a transparent black image with zero natural width and height – in particular, it must not show a broken image icon. We added the method `ReplacedContents::zero_sized_invalid_image` to implement this. This patch adds support for image URL references, but not for color gradients, which are treated as invalid images. The reason for this is that currently Servo does not support gradients in `ReplacedContentKind`. This is left as a follow-up change. Testing: Existing `css/css-content/element-replacement*` WPT tests that now pass with this patch. `element-replacement-gradient.html` still fails because this patch does not add support for gradients. Fixes: web-platform-tests#41479 Signed-off-by: Andreu Botella <[email protected]>
servo-wpt-sync
pushed a commit
that referenced
this pull request
Jan 28, 2026
Per CSS-CONTENT-3, one of the possible values of the `content` CSS property is `<content-replacement>`, which evaluates to a single `<image>`. This value is also allowed on regular elements, not just on pseudo-elements, and it will make the element into a replaced element representing the given image, discarding its contents. This patch implements this in `traverse_element`: if the `display` value is not `none` or `contents`, we first check whether the `contents` property should make the element replaced, and if it shouldn't, then we check whether the element itself is replaced or a widget. Per the spec, an invalid image must be treated as representing a transparent black image with zero natural width and height – in particular, it must not show a broken image icon. We added the method `ReplacedContents::zero_sized_invalid_image` to implement this. This patch adds support for image URL references, but not for color gradients, which are treated as invalid images. The reason for this is that currently Servo does not support gradients in `ReplacedContentKind`. This is left as a follow-up change. Testing: Existing `css/css-content/element-replacement*` WPT tests that now pass with this patch. `element-replacement-gradient.html` still fails because this patch does not add support for gradients. Fixes: #41479 Signed-off-by: Andreu Botella <[email protected]>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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:
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
Reviewed-on: https://chromium-review.googlesource.com/4779533
WPT-Export-Revision: 8808ba4250ef951572837415a3deec8ee94e070f