I don't think we want to change that behavior. It seems to me functions usually have special serialization rules, but not general property values.

Does this mean we can serialize any way we want provided that it parses to the same thing?

I don't think so. For one thing it makes writing web-platform-tests hard (not to mention making life hard for scripts that want to parse the result of getComputedStyle). We recently specced <timing-function> serialization (and fixed it in Gecko so far, Blink later) so we can write interop tests. We should probably spec background-position / <position> too.

It doesn't seem to me serialization of general specified value is defined anywhere... If we are trying to define it, it should match what engines are currently doing.

My guess is that engines general just put the parsed tokens in the grammar order, so top center => center top.

This should probably be defined in css-values spec I suppose.

There's a fair bit of serialization defined in CSSOM, e.g. serializing a CSS value. But I don't think it covers <position>.

I was looking for issues related to the serialization of <position> (ie. the "generic" <position>) and <bg-position> because I do not understand the rationale for the following (quoted from CSS Shapes, 3.3 Serialization of Basic Shapes), which is matching the current browser outputs and WPT tests:

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.

circle(closest-side at center) serializes as circle(at 50% 50%)

I guess that always uses the 2- or 4-value form comes from an old version of CSS Shape, but why this rule is also applied to <bg-position>? And why would it be required? Furthermore, the following (quoted from CSSOM, 6.7.2 Serializing CSS Values) is a normative text against it:

If component values can be omitted or replaced with a shorter representation without changing the meaning of the value, omit/replace them.

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. The text in css-shapes was also supposed to also go in css-backgrounds-3 (I remember having plans to remove as much as I could from css-shapes and just refer to bg-position serialization when I could)

Thanks, I would have found this issue if I had searched on this topic without the css-shapes label.

If I understood correctly :

1. a list of values matching <position> or <bg-position> should serialize to at least 2 values, ie. it should not be simplified either to a single value, because it would complicate round-tripping and parsing transform-origin would become ambiguous, or to 3 values (eg. from circle(at left 10px bottom 10%) to circle(at left 10px 90%)
2. a list of values matching the 3-value syntax <bg-position> should serialize to 4 values by adding a missing offset (percentage) or by replacing center by top 50% or left 50%
3. the specified values are serialized, ie. a keyword is not replaced by a percentage and vice-versa (except for 2)

This is now edited into css-values-4, see 0742ad6

Marking Needs Edits for CSS Shapes

The issue seems also about missing serialization steps for background-position (<bg-position>) in CSS Backgrounds.