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.