[css-shapes] Serialization of computed value of <position> in circle() and ellipse() function

[upsuper]

If I specify circle(0px at 0px 0px), how should the computed value looks like after serialization?

In "3.2. Computed Values of Basic Shapes", the spec says:

A <position> value in circle() or ellipse() is computed as a pair of offsets (horizontal then vertical) from the top left origin, each given as a combination of an absolute length and a percentage.

It seems to me that means the value would be computed to something like circle(0px at calc(0px + 0%) calc(0px + 0%)), and eventually serialized in this form.

This matches Gecko's current implementation, and I do think having the computed value in a most general form makes sense, but I'm not completely sure whether this is the desired result.

I'm confused because the section "3.3. Serialization of Basic Shapes" states

avoiding calc() expressions where possible, avoiding calc() transformations

but I guess that wouldn't change the result of serialization of computed value, as the computed value has already been in a form with calc(). Is that correct?

[astearns]

This was meant to match the computed value of background-position, but that text has changed a couple of times since then. It currently says each given as a computed <length-percentage> value

I'm not clear whether the current background-position definition preserves the animatability of the property as was discussed in https://lists.w3.org/Archives/Public/www-style/2013Dec/0388.html , though

@tabatkins @fantasai Should I change shapes-1 to match the current background-position text, or do we need to revisit what's defined in backgrounds-3?

[tabatkins]

I don't think anything should serialize as calc(0px + 0%) unless it was specified as a calc() with % and length in it to begin with. It violates both shortest-serialization principle of generic serialization rules, and the "don't change shape" principle of calc() serialization which preserves 0s if they were specified.

This applies to both background-position and shape functions.

[fantasai]

@tabatkins What edits would be needed to specify that behavior clearly?

[tabatkins]

Hm, perhaps just restating the computed value to be explicitly a <length-percentage>, as that value only using calc() when necessary is already clear and well-established.

[fantasai]

Done. @upsuper Does that work for you?

[upsuper]

Sounds good to me.