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

[fantasai]

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:

1. 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.

2. 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:

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

[tabatkins]

+1 to both of these

[cdoublev]

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]

+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]

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]

@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]

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.

[BorisChiou]

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.

[css-meeting-bot]

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]

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]

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

[fantasai]

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