[css-shapes-1] Optional values shouldn't be serialized #8695

fantasai · 2023-04-06T21:13:05Z

Currently the CSS Shapes draft specifies:

To serialize the functions, serialize as per their individual grammars, in the order the grammars are written in, avoiding calc() expressions where possible, avoiding calc() transformations, omitting components when possible without changing the meaning, joining space-separated tokens with a single space, and following each serialized comma with a single space.

This seems mostly fine, except there's a couple problems:

There's an example that says:

Omitting components means that some default values do not show up in the serialization. But since always uses the 2- or 4-value form, a default is not omitted.

which is nonsense, because omitting a default at <position> is required by the normative text above.

This example is then tested in WPT, which shows that we (unfortunately) have interop on the example rather than on the normative text. However, having special rules that go against our general serialization principles without good reason is an anti-pattern. We should be consistent and allow at <position> to be omitted from the serialization just like any other optional component.
The guidance about “avoiding calc() expressions where possible, avoiding calc() transformations” conflicts with our more generally-applicable rules about serializing <position> and calc() values, which distinguish specified-value and computed-value serializations in very particular ways.

Proposal:

Fix the examples and tests, and file implementation bugs, allowing at <position> to be omitted, consistent with our general serialization principles.
Remove guidance about calc() serialization, allowing the spec to defer to the more specific serialization rules in css-values-4.

The text was updated successfully, but these errors were encountered:

tabatkins · 2023-04-06T21:25:29Z

+1 to both of these

cdoublev · 2023-04-11T05:46:44Z

I do not think the resolution for #2274 (always serialize with 2 or 4 values) was meant to be taken literally, but for the record (quoted from #368):

circle(), circle(at center), circle(at 50%), ... are all valid and means the same value, and my guess would have been to serialize them as circle(). I am not claiming that they should be serialized like this, but I just woud like to understand the current browser outputs.

@cdoublev (and others) take a look at the discussion in #2274 for some of the things that led us to decide to only serialize to 2- and 4-value forms.

Aside

It would be nice to clarify if a math function simplified to a numeric value representing a default value can be omitted, like in circle(at calc(50%)).

There seems to have interop on generally not omitting a math function representing a default value. But it is not always simple see #5642 (comment).

BorisChiou · 2023-05-24T21:39:17Z

+1 to the proposal to omit the at <position>. This is especially necessary to motion path because offset-path doesn't use the standard default for at <position> if the component is omitted.

tabatkins · 2023-05-25T20:57:28Z

We definitely need to omit the at <position> when it was omitted by the author, for offset-path to work correctly, but we also need to preserve the at <position> even if it specifies the default value, for the same reason - circle(at center) works differently than circle() when used as an offset path, because the latter will use 'offset-position' for the default instead.

emilio · 2023-05-25T22:01:57Z

@tabatkins It's a bit weird to have a magic value by omission, I don't think we have many precedents for such thing? None come to mind right now but I haven't tried too hard...

Maybe there should be an at default keyword value to represent that magic state?

tabatkins · 2023-05-25T22:04:20Z

We do have some behaviors that can only be expressed by omission. I can't name them off the top of my head, but I know they exist because I've been annoyed by them in the past. I'd be fine with adding such a value, but that's a separate issue.

1) As per https://drafts.csswg.org/css-box-4/#typedef-coord-box <coord-box> can't be defined with margin-box. 2) Comes from w3c/csswg-drafts#8695 (comment) Change-Id: I6fe865d5248c7004257cd17669353d810f6e3d09

1) As per https://drafts.csswg.org/css-box-4/#typedef-coord-box <coord-box> can't be defined with margin-box. 2) Comes from w3c/csswg-drafts#8695 (comment) Resolved here: web-platform-tests/interop#340 Change-Id: I6fe865d5248c7004257cd17669353d810f6e3d09

1) As per https://drafts.csswg.org/css-box-4/#typedef-coord-box <coord-box> can't be defined with margin-box. 2) "at <position" changes come from w3c/csswg-drafts#8695 (comment) Resolved here: web-platform-tests/interop#340 Change-Id: I6fe865d5248c7004257cd17669353d810f6e3d09

1) As per https://drafts.csswg.org/css-box-4/#typedef-coord-box <coord-box> can't be defined with margin-box. 2) "at <position" changes come from w3c/csswg-drafts#8695 (comment) Resolved here: web-platform-tests/interop#340 Change-Id: I6fe865d5248c7004257cd17669353d810f6e3d09 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4551246 Reviewed-by: Anders Hartvoll Ruud <andruud@chromium.org> Commit-Queue: Daniil Sakhapov <sakhapov@chromium.org> Cr-Commit-Position: refs/heads/main@{#1150434}

BorisChiou · 2023-06-07T20:57:47Z

Per #8695 (comment), it'd be great to specify the expected behaviors for interpolation as well, especially for offset-path. I noticed there is a wpt test like this:
ellipse(10% 10%) -> ellipse(40% 50% at 25% 25%).

This test expects to do interpolation by assigning center as the default value. However, omitted at <position> is special, so I expect these two values can not be interpolated (i.e. fall back to discrete animation). So it'd be great to add the omitted at position case in Interpolation of Basic Shapes as well.

… a=testonly Automatic update from web-platform-tests Change WPT test for offset-path parsing 1) As per https://drafts.csswg.org/css-box-4/#typedef-coord-box <coord-box> can't be defined with margin-box. 2) "at <position" changes come from w3c/csswg-drafts#8695 (comment) Resolved here: web-platform-tests/interop#340 Change-Id: I6fe865d5248c7004257cd17669353d810f6e3d09 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4551246 Reviewed-by: Anders Hartvoll Ruud <andruud@chromium.org> Commit-Queue: Daniil Sakhapov <sakhapov@chromium.org> Cr-Commit-Position: refs/heads/main@{#1150434} -- wpt-commits: 77e63377e0476fe25da513b11b78f1525c5c91ee wpt-pr: 40120

… a=testonly Automatic update from web-platform-tests Change WPT test for offset-path parsing 1) As per https://drafts.csswg.org/css-box-4/#typedef-coord-box <coord-box> can't be defined with margin-box. 2) "at <position" changes come from w3c/csswg-drafts#8695 (comment) Resolved here: web-platform-tests/interop#340 Change-Id: I6fe865d5248c7004257cd17669353d810f6e3d09 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4551246 Reviewed-by: Anders Hartvoll Ruud <andruudchromium.org> Commit-Queue: Daniil Sakhapov <sakhapovchromium.org> Cr-Commit-Position: refs/heads/main{#1150434} -- wpt-commits: 77e63377e0476fe25da513b11b78f1525c5c91ee wpt-pr: 40120 UltraBlame original commit: 6af80ffc63102ca16a772daca958c3ad783d4eab

css-meeting-bot · 2023-08-02T23:51:16Z

The CSS Working Group just discussed [css-shapes-1] Optional values shouldn't be serialized, and agreed to the following:

RESOLVED: We fix the example and tests based on it
RESOLVED: Remove the part about serializing calc expressions from Shapes spec

The full IRC log of that discussion

<dael_> fantasai: The css shapes spec tries to spec serialization but does a couple of things that don't make sense. In an example it says omitting components shows some default values don't show in serialization.
<dael_> fantasai: You can omit @position so taht doesn't make sense. We have interop that we always serialize, but since you can omit you should allow to omit. Shortest serialization principle.
<dael_> fantasai: Second is some guidance about avoiding calc and calc transforms, but that conflicts with rules about serializing position in calc.
<dael_> fantasai: In this case, should defer to rules in values 4
<TabAtkins> strong +1 to making these consistent now
<dael_> astearns: This was written before the rules. Internt was always to be superceeded by calc. Happy to defer to existing text now
<dael_> astearns: First bit needs to stay in shapes b/c talks about specific shapes values, right?
<dael_> fantasai: I think we just need to correct the example and remove/fix the tests
<dael_> astearns: Any concerns about anybody relying on this? I don't think I have any
<dael_> astearns: Prop: We fix the example and tests based on it
<dael_> astearns: Obj?
<dael_> RESOLVED: We fix the example and tests based on it
<dael_> astearns: Prop: Remove the part about serializing calc expressions from Shapes spec
<dael_> astearns: Obj?
<dael_> RESOLVED: Remove the part about serializing calc expressions from Shapes spec
<dael_> astearns: Did you happen to look at the tests for serializing calc in Shapes? There may be some that need updates
<dael_> fantasai: I think there are tests, but I don't remember where they are
<dael_> astearns: Anything else on this one?

cdoublev · 2023-09-15T03:53:50Z

edit: I think I misunderstood the resolution (serialize without position when it was omitted, serialize with default position when it was specified), sorry.

Off topic

Should at center/at center center be the only values omitted when serializing a specified value?

I cannot find any WPT tests that omit <position> anywhere, and I do not think general serialization principles currently define whether 50% can be considered equivalent to center or more generally, if a keyword can be considered equivalent to a numeric value, when serializing a specified value.

In FF, any combination of center and 50% is omitted as a <position> in conic-gradient() and radial-gradient(), when serializing a specified value.

But still in FF, any combination of left/top and 0% are preserved as a <bg-position> in background or mask, when serializing a specified value, whereas 0% 0% (the initial value of background-position or mask-position) is omitted.

Also, FF omits 400 as a font-weight (its initial value is normal) in font.

emilio · 2023-09-26T16:53:08Z

@tabatkins @fantasai so to be clear the expected behavior is to always serialize to a <length-percentage>?

Per the spec issue: w3c/csswg-drafts#8695, we should convert the position components into `<length-percentage>` for the specified values of `at <position>`, for basic shapes. Also, update shape-outside/values/support/parsing-utils.js a little bit to make sure we convert the absolute length into px if it is in `calc()`, for the specified values. And remove calc() if possible for computed values. Differential Revision: https://phabricator.services.mozilla.com/D188780 bugzilla-url: https://bugzilla.mozilla.org/show_bug.cgi?id=1823475 gecko-commit: a3e9e98d521c05808ed81bc5e49e9b1f181fa388 gecko-reviewers: emilio

…s. r=emilio Per the spec issue: w3c/csswg-drafts#8695, we should convert the position components into `<length-percentage>` for the specified values of `at <position>`, for basic shapes. Also, update shape-outside/values/support/parsing-utils.js a little bit to make sure we convert the absolute length into px if it is in `calc()`, for the specified values. And remove calc() if possible for computed values. Differential Revision: https://phabricator.services.mozilla.com/D188780

Per the spec issue: w3c/csswg-drafts#8695, we should convert the position components into `<length-percentage>` for the specified values of `at <position>`, for basic shapes. Also, update shape-outside/values/support/parsing-utils.js a little bit to make sure we convert the absolute length into px if it is in `calc()`, for the specified values. And remove calc() if possible for computed values. Differential Revision: https://phabricator.services.mozilla.com/D188780 bugzilla-url: https://bugzilla.mozilla.org/show_bug.cgi?id=1823475 gecko-commit: a3e9e98d521c05808ed81bc5e49e9b1f181fa388 gecko-reviewers: emilio

…s. r=emilio Per the spec issue: w3c/csswg-drafts#8695, we should convert the position components into `<length-percentage>` for the specified values of `at <position>`, for basic shapes. Also, update shape-outside/values/support/parsing-utils.js a little bit to make sure we convert the absolute length into px if it is in `calc()`, for the specified values. And remove calc() if possible for computed values. Differential Revision: https://phabricator.services.mozilla.com/D188780

Per the spec issue: w3c/csswg-drafts#8695, we should convert the position components into `<length-percentage>` for the specified values of `at <position>`, for basic shapes. Also, update shape-outside/values/support/parsing-utils.js a little bit to make sure we convert the absolute length into px if it is in `calc()`, for the specified values. And remove calc() if possible for computed values. Differential Revision: https://phabricator.services.mozilla.com/D188780 bugzilla-url: https://bugzilla.mozilla.org/show_bug.cgi?id=1823475 gecko-commit: a3e9e98d521c05808ed81bc5e49e9b1f181fa388 gecko-reviewers: emilio

fantasai · 2023-12-18T22:06:18Z

@emilio The expected serialization of <position> is defined in https://drafts.csswg.org/css-values-4/#position-serialization

…les. #8695

…s. r=emilio Per the spec issue: w3c/csswg-drafts#8695, we should convert the position components into `<length-percentage>` for the specified values of `at <position>`, for basic shapes. Also, update shape-outside/values/support/parsing-utils.js a little bit to make sure we convert the absolute length into px if it is in `calc()`, for the specified values. And remove calc() if possible for computed values. Differential Revision: https://phabricator.services.mozilla.com/D188780

w3c/csswg-drafts#8695, w3c/fxtf-drafts#504.

fantasai added css-values-4 Current Work Agenda+ css-shapes-1 Current Work and removed css-values-4 Current Work labels Apr 6, 2023

This was referenced May 23, 2023

[motion-1] Fix offset-path parsing test web-platform-tests/interop#340

Closed

[motion-1] What is the expected serialization for <position> in circle and ellipse if the explicit center is not given? w3c/fxtf-drafts#514

Closed

chromium-wpt-export-bot mentioned this issue May 26, 2023

Change WPT test for offset-path parsing web-platform-tests/wpt#40120

Merged

BorisChiou mentioned this issue Jul 14, 2023

[css-shapes-1] The interpolation for at <position> when it is omitted #9068

Open

css-meeting-bot removed the Agenda+ label Aug 2, 2023

mozilla-apprentice mentioned this issue Aug 2, 2023

[css-shapes-1] Optional values shouldn't be serialized mozilla/wg-decisions#1209

Closed

chromium-helper mentioned this issue Aug 2, 2023

[css-shapes-1] Optional values shouldn't be serialized chromium-helper/csswg-resolutions#199

Closed

cdoublev mentioned this issue Sep 15, 2023

[css-animations-1] Undefined procedures to get/set CSSOM attributes #9364

Open

moz-wptsync-bot mentioned this issue Oct 3, 2023

[Gecko Bug 1823475] Convert position into length-percentage for basic shapes. web-platform-tests/wpt#42325

Merged

tabatkins added a commit that referenced this issue Dec 18, 2023

[css-shapes-1] Targeted fix of shape serialization section, fix examp…

37b5a39

…les. #8695

tabatkins mentioned this issue Dec 18, 2023

Shapes edits #9723

Merged

astearns pushed a commit that referenced this issue Dec 19, 2023

[css-shapes-1] Targeted fix of shape serialization section, fix examp…

d898d07

…les. #8695

astearns closed this as completed Dec 19, 2023

cdoublev mentioned this issue Jul 31, 2024

[css-shapes] Should circle() serialization omit the center value? #10645

Open

cdoublev added a commit to cdoublev/css that referenced this issue Oct 8, 2024

Omit default circle/ellipse position except for offset-path

6b2c2d0

w3c/csswg-drafts#8695, w3c/fxtf-drafts#504.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[css-shapes-1] Optional values shouldn't be serialized #8695

[css-shapes-1] Optional values shouldn't be serialized #8695

[css-shapes-1] Optional values shouldn't be serialized #8695

[css-shapes-1] Optional values shouldn't be serialized #8695

Comments