This WPT test (in the interop-2023 set) has some failures in Firefox: http://wpt.live/css/css-masking/parsing/clip-path-valid.html The failures are for things like: > e.style['clip-path'] = "circle()" should set the property value >assert_equals: serialization should be canonical > expected "circle(at 50% 50%)" but got "circle(at center center)" We're using keywords (`center`) in the computed style, while the test is expecting `50%`. I think this is a valid bug (i.e. the test's expectations are correct and we're wrong), per spec. Spec references: * https://drafts.csswg.org/css-shapes-1/#funcdef-basic-shape-circle says the circle's position is a `<position>` * https://w3c.github.io/csswg-drafts/css-values-4/#typedef-position defines ` <position>` and includes a NOTE about what happens in the computed value: > Note: Computed values are always serialized as two offsets (**without keywords**) because the computed value does not preserve syntactic distinctions. (From context, the spec is using "offsets" here to mean `<length-percentage>`, as opposed to a keyword.)
Bug 1823475 Comment 0 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
This WPT test (in the interop-2023 set) has some failures in Firefox: https://wpt.fyi/results/css/css-masking/parsing/clip-path-valid.html http://wpt.live/css/css-masking/parsing/clip-path-valid.html The failures are for things like: > e.style['clip-path'] = "circle()" should set the property value >assert_equals: serialization should be canonical > expected "circle(at 50% 50%)" but got "circle(at center center)" We're using keywords (`center`) in the computed style, while the test is expecting `50%`. I think this is a valid bug (i.e. the test's expectations are correct and we're wrong), per spec. Spec references: * https://drafts.csswg.org/css-shapes-1/#funcdef-basic-shape-circle says the circle's position is a `<position>` * https://w3c.github.io/csswg-drafts/css-values-4/#typedef-position defines ` <position>` and includes a NOTE about what happens in the computed value: > Note: Computed values are always serialized as two offsets (**without keywords**) because the computed value does not preserve syntactic distinctions. (From context, the spec is using "offsets" here to mean `<length-percentage>`, as opposed to a keyword.)
This WPT test (in the interop-2023 set) has some failures in Firefox: https://wpt.fyi/results/css/css-masking/parsing/clip-path-valid.html http://wpt.live/css/css-masking/parsing/clip-path-valid.html The failures are for things like: > e.style['clip-path'] = "circle()" should set the property value >assert_equals: serialization should be canonical > expected "circle(at 50% 50%)" but got "circle(at center center)" We're using keywords (`center`) in the computed style, while the test is expecting `50%`. I think this is a valid bug (i.e. the test's expectations are correct and we're wrong), per spec. Spec references: * https://drafts.csswg.org/css-shapes-1/#funcdef-basic-shape-circle says the circle's position is a `<position>` * https://drafts.csswg.org/css-values-4/#typedef-position defines ` <position>` and includes a NOTE about what happens in the computed value: > Note: Computed values are always serialized as two offsets (**without keywords**) because the computed value does not preserve syntactic distinctions. (From context, the spec is using "offsets" here to mean `<length-percentage>`, as opposed to a keyword.)
This WPT test (in the interop-2023 set) has some failures in Firefox: https://wpt.fyi/results/css/css-masking/parsing/clip-path-valid.html http://wpt.live/css/css-masking/parsing/clip-path-valid.html The failures are for things like: > e.style['clip-path'] = "circle()" should set the property value >assert_equals: serialization should be canonical > expected "circle(at 50% 50%)" but got "circle(at center center)" We're using keywords (`center`) in the computed style, while the test is expecting `50%`. I think this is a valid bug (i.e. the test's expectations are correct and we're wrong), per spec. Spec references: * https://drafts.csswg.org/css-shapes-1/#funcdef-basic-shape-circle says the circle's position is a `<position>` * https://drafts.csswg.org/css-values-4/#typedef-position defines ` <position>` and includes a note to say what happens in the computed value: > Note: Computed values are always serialized as two offsets (**without keywords**) because the computed value does not preserve syntactic distinctions. (From context, the spec is using "offsets" here to mean `<length-percentage>`, as opposed to a keyword.)
This WPT test (in the interop-2023 set) has some failures in Firefox: https://wpt.fyi/results/css/css-masking/parsing/clip-path-valid.html http://wpt.live/css/css-masking/parsing/clip-path-valid.html The failures are for things like: > e.style['clip-path'] = "circle()" should set the property value >assert_equals: serialization should be canonical > expected "circle(at 50% 50%)" but got "circle(at center center)" We're using keywords (`center`) in the computed style, while the test is expecting `50%`. I think this is a valid bug (i.e. the test's expectations are correct and we're wrong), per spec. Spec references: * https://drafts.csswg.org/css-shapes-1/#funcdef-basic-shape-circle says the circle's position is a `<position>` (which defaults to `center` if omitted) * https://drafts.csswg.org/css-values-4/#typedef-position defines ` <position>` and includes a note to say what happens in the computed value: > Note: Computed values are always serialized as two offsets (**without keywords**) because the computed value does not preserve syntactic distinctions. (From context, the spec is using "offsets" here to mean `<length-percentage>`, as opposed to a keyword.)