Skip to content

Relative Color Syntax (RCS)#41479

Closed
chromium-wpt-export-bot wants to merge 1 commit intomasterfrom
chromium-export-cl-4779533
Closed

Relative Color Syntax (RCS)#41479
chromium-wpt-export-bot wants to merge 1 commit intomasterfrom
chromium-export-cl-4779533

Conversation

@chromium-wpt-export-bot
Copy link
Copy Markdown
Collaborator

@chromium-wpt-export-bot chromium-wpt-export-bot commented 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 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
Reviewed-on: https://chromium-review.googlesource.com/4779533
WPT-Export-Revision: 8808ba4250ef951572837415a3deec8ee94e070f

Copy link
Copy Markdown
Collaborator

@wpt-pr-bot wpt-pr-bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The review process for this patch is being conducted in the Chromium project.

@chromium-wpt-export-bot chromium-wpt-export-bot force-pushed the chromium-export-cl-4779533 branch 4 times, most recently from f357ae7 to af1b7e5 Compare August 17, 2023 14:13
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
Copy link
Copy Markdown
Collaborator Author

Close this PR because the Chromium CL has been abandoned.

@chromium-wpt-export-bot chromium-wpt-export-bot deleted the chromium-export-cl-4779533 branch September 1, 2023 20:46
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]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants