[css-shapes] Serialization of computed value of <position> in circle() and ellipse() function · Issue #402 · w3c/csswg-drafts · GitHub
Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
upsuper opened this issue Aug 12, 2016 · 6 comments
Labels
Closed Accepted as Editorial Commenter Satisfied Commenter has indicated satisfaction with the resolution / edits. css-backgrounds-3 Current Work css-shapes-1 Current Work

Comments

@upsuper
Copy link
Member

upsuper commented Aug 12, 2016

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?

@upsuper upsuper added the css-shapes-1 Current Work label Aug 16, 2016
@astearns
Copy link
Member

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?

@astearns astearns added the css-backgrounds-3 Current Work label Jan 22, 2020
@tabatkins
Copy link
Member

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
Copy link
Collaborator

fantasai commented Mar 6, 2020

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

@tabatkins
Copy link
Member

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
Copy link
Collaborator

Done. @upsuper Does that work for you?

@upsuper
Copy link
Member Author

upsuper commented Oct 30, 2020

Sounds good to me.

@fantasai fantasai added Commenter Satisfied Commenter has indicated satisfaction with the resolution / edits. and removed Commenter Response Pending labels Dec 16, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Closed Accepted as Editorial Commenter Satisfied Commenter has indicated satisfaction with the resolution / edits. css-backgrounds-3 Current Work css-shapes-1 Current Work
Projects
None yet
Development

No branches or pull requests

4 participants