[css-values] Inconsistent position serialization #2274

ewilligers · 2018-02-05T02:59:37Z

The position spec mentions

The canonical order when serializing is the horizontal component followed by the vertical component.

but does not discuss if the serialization should contain the author's supplied keywords or if they should be converted to equivalent percentages.

The spec also doesn't mention if 'center' should be added or removed when serializing. (Edge and Safari sometimes serialize center center as center.)

Browsers are currently inconsistent with themselves and each other:

10%	Chrome 64	Edge 16	Firefox 58	Safari 11
background-image: radial-gradient(at `<position>`, red, blue)	10% center	10%	10% center	10% center
background-position: `<bg-position>`	10% center	10%	10% center	10% center
object-position: `<position>`	10% center	10% 50%	10% center	10% center
perspective-origin: `<position>`	10% center	10% 50%	10% center	10% center
shape-outside: circle(at `<position>`)	10% 50%	10%	10%	10% 50%

20% 30px	Chrome 64	Edge 16	Firefox 58	Safari 11
background-image: radial-gradient(at `<position>`, red, blue)	20% 30px	20% 30px	20% 30px	20% 30px
background-position: `<bg-position>`	20% 30px	20% 30px	20% 30px	20% 30px
object-position: `<position>`	20% 30px	20% 30px	20% 30px	20% 30px
perspective-origin: `<position>`	20% 30px	20% 30px	20% 30px	20% 30px
shape-outside: circle(at `<position>`)	20% 30px	20% 30px	20% 30px	20% 30px

30px center	Chrome 64	Edge 16	Firefox 58	Safari 11
background-image: radial-gradient(at `<position>`, red, blue)	30px center	30px	30px center	30px center
background-position: `<bg-position>`	30px center	30px	30px center	30px center
object-position: `<position>`	30px center	30px 50%	30px center	30px center
perspective-origin: `<position>`	30px center	30px center	30px center	30px center
shape-outside: circle(at `<position>`)	30px 50%	30px center	30px center	30px 50%

40px top	Chrome 64	Edge 16	Firefox 58	Safari 11
background-image: radial-gradient(at `<position>`, red, blue)	40px top	40px top	40px top	40px top
background-position: `<bg-position>`	40px top	40px top	40px top	40px top
object-position: `<position>`	40px top	40px 0%	40px top	40px top
perspective-origin: `<position>`	40px top	40px top	40px top	40px top
shape-outside: circle(at `<position>`)	40px 0%	40px top	40px top	40px 0%

bottom 10% right 20%	Chrome 64	Edge 16	Firefox 58	Safari 11
background-image: radial-gradient(at `<position>`, red, blue)	right 20% bottom 10%	right 20% bottom 10%	right 20% bottom 10%	right 20% bottom 10%
background-position: `<bg-position>`	right 20% bottom 10%	right 20% bottom 10%	right 20% bottom 10%	right 20% bottom 10%
object-position: `<position>`	right 20% bottom 10%	calc(80%) calc(90%)	right 20% bottom 10%	right 20% bottom 10%
perspective-origin: `<position>`	right 20% bottom 10%	undefined	right 20% bottom 10%	right 20% bottom 10%
shape-outside: circle(at `<position>`)	80% 90%	bottom 10% right 20%	bottom 10% right 20%	80% 90%

bottom right	Chrome 64	Edge 16	Firefox 58	Safari 11
background-image: radial-gradient(at `<position>`, red, blue)	right bottom	right bottom	right bottom	right bottom
background-position: `<bg-position>`	right bottom	right bottom	right bottom	right bottom
object-position: `<position>`	right bottom	100% 100%	right bottom	right bottom
perspective-origin: `<position>`	right bottom	right bottom	right bottom	right bottom
shape-outside: circle(at `<position>`)	100% 100%	bottom right	bottom right	100% 100%

center	Chrome 64	Edge 16	Firefox 58	Safari 11
background-image: radial-gradient(at `<position>`, red, blue)	center center	center	center center	center center
background-position: `<bg-position>`	center center	center	center center	center center
object-position: `<position>`	center center	50% 50%	center center	center
perspective-origin: `<position>`	center center	center 50%	center center	center center
shape-outside: circle(at `<position>`)	50% 50%	center	center	50% 50%

center 50px	Chrome 64	Edge 16	Firefox 58	Safari 11
background-image: radial-gradient(at `<position>`, red, blue)	center 50px	center 50px	center 50px	center 50px
background-position: `<bg-position>`	center 50px	center 50px	center 50px	center 50px
object-position: `<position>`	center 50px	50% 50px	center 50px	center 50px
perspective-origin: `<position>`	center 50px	center 50px	center 50px	center 50px
shape-outside: circle(at `<position>`)	50% 50px	center 50px	center 50px	50% 50px

center bottom	Chrome 64	Edge 16	Firefox 58	Safari 11
background-image: radial-gradient(at `<position>`, red, blue)	center bottom	bottom	center bottom	center bottom
background-position: `<bg-position>`	center bottom	bottom	center bottom	center bottom
object-position: `<position>`	center bottom	50% 100%	center bottom	center bottom
perspective-origin: `<position>`	center bottom	center bottom	center bottom	center bottom
shape-outside: circle(at `<position>`)	50% 100%	center bottom	center bottom	50% 100%

center center	Chrome 64	Edge 16	Firefox 58	Safari 11
background-image: radial-gradient(at `<position>`, red, blue)	center center	center	center center	center center
background-position: `<bg-position>`	center center	center	center center	center center
object-position: `<position>`	center center	50% 50%	center center	center
perspective-origin: `<position>`	center center	center center	center center	center center
shape-outside: circle(at `<position>`)	50% 50%	center center	center center	50% 50%

center left	Chrome 64	Edge 16	Firefox 58	Safari 11
background-image: radial-gradient(at `<position>`, red, blue)	left center	left	left center	left center
background-position: `<bg-position>`	left center	left	left center	left center
object-position: `<position>`	left center	0% 50%	left center	left center
perspective-origin: `<position>`	left center	left center	left center	left center
shape-outside: circle(at `<position>`)	0% 50%	center left	center left	0% 50%

left	Chrome 64	Edge 16	Firefox 58	Safari 11
background-image: radial-gradient(at `<position>`, red, blue)	left center	left	left center	left center
background-position: `<bg-position>`	left center	left	left center	left center
object-position: `<position>`	left center	0% 50%	left center	left center
perspective-origin: `<position>`	left center	left 50%	left center	left center
shape-outside: circle(at `<position>`)	0% 50%	left	left	0% 50%

left bottom	Chrome 64	Edge 16	Firefox 58	Safari 11
background-image: radial-gradient(at `<position>`, red, blue)	left bottom	left bottom	left bottom	left bottom
background-position: `<bg-position>`	left bottom	left bottom	left bottom	left bottom
object-position: `<position>`	left bottom	0% 100%	left bottom	left bottom
perspective-origin: `<position>`	left bottom	left bottom	left bottom	left bottom
shape-outside: circle(at `<position>`)	0% 100%	left bottom	left bottom	0% 100%

left center	Chrome 64	Edge 16	Firefox 58	Safari 11
background-image: radial-gradient(at `<position>`, red, blue)	left center	left	left center	left center
background-position: `<bg-position>`	left center	left	left center	left center
object-position: `<position>`	left center	0% 50%	left center	left center
perspective-origin: `<position>`	left center	left center	left center	left center
shape-outside: circle(at `<position>`)	0% 50%	left center	left center	0% 50%

right 30% top 60px	Chrome 64	Edge 16	Firefox 58	Safari 11
background-image: radial-gradient(at `<position>`, red, blue)	right 30% top 60px	right 30% top 60px	right 30% top 60px	right 30% top 60px
background-position: `<bg-position>`	right 30% top 60px	right 30% top 60px	right 30% top 60px	right 30% top 60px
object-position: `<position>`	right 30% top 60px	calc(70%) 60px	right 30% top 60px	right 30% top 60px
perspective-origin: `<position>`	right 30% top 60px	undefined	right 30% top 60px	right 30% top 60px
shape-outside: circle(at `<position>`)	70% 60px	right 30% top 60px	right 30% top 60px	70% 60px

right 40%	Chrome 64	Edge 16	Firefox 58	Safari 11
background-image: radial-gradient(at `<position>`, red, blue)	right 40%	right 40%	right 40%	right 40%
background-position: `<bg-position>`	right 40%	right 40%	right 40%	right 40%
object-position: `<position>`	right 40%	100% 40%	right 40%	right 40%
perspective-origin: `<position>`	right 40%	right 40%	right 40%	right 40%
shape-outside: circle(at `<position>`)	100% 40%	right 40%	right 40%	100% 40%

top	Chrome 64	Edge 16	Firefox 58	Safari 11
background-image: radial-gradient(at `<position>`, red, blue)	center top	top	center top	center top
background-position: `<bg-position>`	center top	top	center top	center top
object-position: `<position>`	center top	50% 0%	center top	center top
perspective-origin: `<position>`	center top	50% top	center top	center top
shape-outside: circle(at `<position>`)	50% 0%	top	top	50% 0%

top center	Chrome 64	Edge 16	Firefox 58	Safari 11
background-image: radial-gradient(at `<position>`, red, blue)	center top	top	center top	center top
background-position: `<bg-position>`	center top	top	center top	center top
object-position: `<position>`	center top	50% 0%	center top	center top
perspective-origin: `<position>`	center top	center top	center top	center top
shape-outside: circle(at `<position>`)	50% 0%	top center	top center	50% 0%

The text was updated successfully, but these errors were encountered:

css-meeting-bot · 2018-07-03T23:50:14Z

The Working Group just discussed Inconsistent position serialization, and agreed to the following:

RESOLVED: 1) All the positions serialize the same way (background-position,m object-position, etc.) 2) All of them resolve as <position>. Background-position 3-value syntax’s are not allowed.
RESOLVED: All the <position> values serialize to at least two values.

The full IRC log of that discussion

<myles> Topic: Inconsistent position serialization
<myles> Github: https://github.com//issues/2274
<myles> ericwilligers: For one of the properties, the spec is explicit about serialization, and that’s different from all the other ones
<myles> ericwilligers: another inconsistency is that all the browsers behave differently from one another
<myles> ericwilligers: suggestions?
<myles> leaverou: don’t we have a principle that shorter serializations are better?
<myles> TabAtkins: yes
<myles> leaverou: if we follow that, 50% should not be introduced
<myles> leaverou: do that mean if it was specified explicitly, it should be introduced?
<myles> dbaron: there are cases where you do need it to be disambiguated. center 10% and 10% center are different
<myles> dbaron: someone should go through, figure out what the compatible behavior is, figure out what the same behavior is, and figure out what should actually happen. This table is rather large for going through in the WG meeting
<myles> ericwilligers: the one that’s different from the others, is that a mistake and they should all the consistent?
<myles> emilio: yes
<myles> dbaron: some of these things are very easy to write as a spec editor, but we should be careful to stick them in when they cause inconsistencies like this. Implementors should be suspicious of them too, if they say to do something different from everything else
<myles> emilio: Can we resolve on the special case being outside?
<myles> fantasai: All the cases should be the same
<emilio> s/outside/removed
<myles> Rossen: yes
<myles> ericwilligers: we should think about transform origin and background position, because transform origin is 3D, and background position accepts the 3 value grammar. So “left 10% top”
<myles> fantasai: we’re trying to get rid of 3 values
<myles> fantasai: we can resolve on 2 things: 1) all the serializsations should be the same, 2) we never serialize to the three value serializations, unless one of the three values is center, and 3)
<myles> ericwilligers: What about always serialize to a valid <position>
<myles> fantasai: bgposition should not be allowed in serialization
<myles> Rossen: objections?
<myles> RESOLVED: 1) All the positions serialize the same way (background-position,m object-position, etc.) 2) All of them resolve as <position>. Background-position 3-value syntax’s are not allowed.
<myles> fantasai: We have more questions. 1) Do we ever serialize to a 1-value syntax? Eric made an amazing chart of compat data. Edge takes the shortest backwards-compatible serialization principle very seriously, and when it can, drops down to a single value. The other implementations will always have at least 2 values
<myles> Rossen: yeeeeeup
<myles> fantasai: Should we ask Edge to change? To match everyone else? Or are one-value serializations actually good
<myles> TabAtkins: This decision applies to typed OM too.
<myles> fantasai: I think two-value syntax is more understandable to work with. Because if you happen to land on 50% arbitrarily, it would be awkward otherwise. And we have 3 implementations this way. So, because of minimizing the amount of work, we should standardize on 2-values
<myles> heycam: Is this a general principle? Like pairs of numbers that are coordinates, they should always be serialized as two-values?
<myles> fantasai: I don’t think that’s valuable
<Rossen> s/Rossen: yeeeeeup//
<myles> dbaron: One reason position is different is that it has a relatively complicated set of rules, where you’re allowed to do X Y order, or Y X order much of the time but not all of the time, which makes it complicated to figure out which values will round-trip correctly if you reduce it to just one
<myles> fantasai: a more important reason is the transform-origin syntax, which becomes ambiguous if you only have one value
<myles> fantasai: You wouldn’t be able to consider position as a single value without considering whether or not you have a Z component. That creates a serialization of position cannot be self-contained
<myles> fantasai: The proposal: <position> always serializes at least two values
<myles> TabAtkins: I’m down with that
<myles> Rossen: It means some work for us, but ...
<myles> TabAtkins: It means some work for all of us because we’re inconsistent
<myles> Rossen: okay.
<myles> RESOLVED: All the <position> values serialize to at least two values.
<myles> heycam: Is there a way to tell for a given property whether or not we have considered its serialization and what’s in the spec is a considered decision?
<myles> fantasai: not really
<myles> fantasai: In most cases, you follow the general principle of “shortest most backwards-compatible serialization” and the exceptions are where we will have to explicitly say something. The spec says “it’s probably this” but you need to check in case there’s some legacy something
<myles> heycam: I don’t like having to check
<myles> fantasai: Are you volunteering to do the checking?
<myles> heycam: No
<myles> heycam: We should reflect our discussions back in the spec so we don’t have to check
<myles> ericwilligers: We may not be testing in all 4 browsers
<myles> heycam: So tests may serve this purpose?
<myles> fantasai: When we have a 4-value syntax, do you serialize it out to 4 values or do you compress it using calc to two values
<myles> Rossen: I looked at this a year ago int he context of object-position. Most of the testing I did cross browsers suggested that almost all implementations attempt to serialize down to calc for computed values on getComputedStyle(), and were inconsistent as described in this one for style serialization
<myles> emilio: I don’t think we synthesize calc in any case for computed value serialization. If you specify it as calc(), and we cannot simplify it, but I dont’ think we should use calc to shorten the result
<myles> ericwilligers: We’re just talking about serialization, not computed value
<myles> emilio: It’s essentially the same thing
<myles> fantasai: yeah
<myles> fantasai: We’re talking about specified values, not computed styles
<myles> ericwilligers: Blink would never give you a keyword as a computed value
<fantasai> s/fantasai/ericwilligers/
<myles> Rossen: What are we thinkging about in terms of 4 value serialization?
<myles> Rossen: Should we attempt to do 2 when possible?
<myles> plinss: Turning a non-calc into a calc seems weird
<myles> astearns: Ifwe can simplify a 4-value into a 2 value without calc, that makes sense, but if you have to use calc, then it’s not a simplification
<myles> dbaron: I agree as well, though the principle that would say to use calc() is the most compatible syntax principle, because calc() got implemented in background-position background to the 4-value syntax
<myles> dbaron: So for a while you were able to do the effects of the 4-value syntax with calc, without the real 4-value syntax. BUt for now we shouldn’t do it because it’s less compatible
<myles> astearns: We went through this when we were deciding how to use these values in basic shapes. What I thought we were doing was coming up with general principles that would generally be applied to other things than basic shapes. Basic shapes prefers two values, if you can express it without calc, so we may look to that as what we were trying to do years ago
<myles> fantasai: Eric, do you have the test you used for the 4-value syntax?
<myles> fantasai: Can you modify it from bottom right to top left to see if the values get dropped, or if we keep the 4 value syntax even in that case
<myles> ericwilligers: It takes me a while to get results because I use browser stack.
<myles> ericwilligers: If you tell me what you want to know, we can figure it out
<astearns> <position> in basic shapes is paragraph 2 of https://drafts.csswg.org/css-shapes/#basic-shape-serialization
<fantasai> top 10% left 20%
<myles> ericwilligers: With the suggestion that we go down do two unless it introduces a calc, what effect would that be fore background-position?
<myles> Rossen: The minute you have top 10% and then center ..
<myles> ericwilligers: Peopel were saying “we should never ever go to three”
<myles> ericwilligers: right 10% top wil go to 4
<myles> ericwilligers: 1 more question: right 10% top should serialize differently from left 10% top???
<myles> fantasai: That was the question I wanted to ask. We should see what the output is. If there is consensus, we tend to go with that. So I think we should investigate this question a little more over the break. And then go on to the issue of whether to serialize out keywords when you put serialize as a percentage
<myles> Rossen: but this is after the discussion int eh morning?
<myles> fantasai: no, we can do it now
<Rossen> s/int eh/in the/
<myles> fantasai: Looka t the 3rd table: 30px center. Some of the serializations use 50%, some use the keyword center
<myles> fantasai: The table after that: 40px top, some use 0% and some use the keyword top
<myles> fantasai: So the question is, do we resolve on outputting the keyword when the percentage would work?
<myles> dbaron: The bulk of the boxes are they keyword except 3 of them
<myles> dbaron: That said, I don’t know if we should try to go through all of this
<myles> fantasai: 2 questions: 1) How do we deal with keywords, both if the author supplies them and do we turn 50% into center, and 2) the two-value vs 4-value question
<myles> fantasai: We can look into that over the break.
<myles> Rossen: This is where we are going to get a lot more calcs in percentages
<myles> Rossen: okay that’s everything for this for now

See official minutes

ewilligers · 2018-07-04T00:42:48Z

Some more test results:

left 10% top	Chrome 67	Edge 17	Firefox 60	Safari 11.1
background-position: `<bg-position>`	left 10% top	10% top	left 10% top	left 10% top

right 10% top	Chrome 67	Edge 17	Firefox 60	Safari 11.1
background-position: `<bg-position>`	right 10% top	right 10% top 0%	right 10% top	right 10% top

top 10% left 20%	Chrome 67	Edge 17	Firefox 60	Safari 11.1
background-image: radial-gradient(at `<position>`, red, blue)	left 20% top 10%	20% 10%	left 20% top 10%	left 20% top 10%
background-position: `<bg-position>`	left 20% top 10%	20% 10%	left 20% top 10%	left 20% top 10%
object-position: `<position>`	left 20% top 10%	20% 10%	left 20% top 10%	left 20% top 10%
perspective-origin: `<position>`	left 20% top 10%	undefined	left 20% top 10%	left 20% top 10%
shape-outside: circle(at `<position>`)	20% 10%	top 10% left 20%	top 10% left 20%	20% 10%

0% 50%	Chrome 67	Edge 17	Firefox 60	Safari 11.1
background-image: radial-gradient(at `<position>`, red, blue)	0% 50%	0% 50%	0% 50%	0% 50%
background-position: `<bg-position>`	0% 50%	0% 50%	0% 50%	0% 50%
object-position: `<position>`	0% 50%	0% 50%	0% 50%	0% 50%
perspective-origin: `<position>`	0% 50%	0% 50%	0% 50%	0% 50%
shape-outside: circle(at `<position>`)	0% 50%	0% 50%	0% 50%	0% 50%

(raw results)

ewilligers · 2018-07-04T01:23:01Z

All of the above were specified values. There is also variation in computed values.

left 10% top	Chrome 67	Edge 17	Firefox 60	Safari 11.1
background-position: `<bg-position>`	left 10% 0%	10% 0%	10% 0%	left 10% 0%

right 10% top	Chrome 67	Edge 17	Firefox 60	Safari 11.1
background-position: `<bg-position>`	right 10% 0%	right 10% top 0%	90% 0%	right 10% 0%

top 10% left 20%	Chrome 67	Edge 17	Firefox 60	Safari 11.1
background-image: radial-gradient(at `<position>`, red, blue)	left 20% top 10%	20% 10%	20% 10%	left 20% top 10%
background-position: `<bg-position>`	left 20% top 10%	20% 10%	20% 10%	left 20% top 10%
object-position: `<position>`	20% 10%	20% 10%	20% 10%	20% 10%
perspective-origin: `<position>`	20px 0px	50px 0px	20px 0px	20px 0px
shape-outside: circle(at `<position>`)	20% 10%	undefined	undefined	20% 10%

0% 50%	Chrome 67	Edge 17	Firefox 60	Safari 11.1
background-image: radial-gradient(at `<position>`, red, blue)	0% 50%	0% 50%	0% 50%	0% 50%
background-position: `<bg-position>`	0% 50%	0% 50%	0% 50%	0% 50%
object-position: `<position>`	0% 50%	0% 50%	0% 50%	0% 50%
perspective-origin: `<position>`	0px 0px	0px 0px	0px 0px	0px 0px
shape-outside: circle(at `<position>`)	0% 50%	undefined	undefined	0% 50%

(raw results)

emilio · 2018-07-04T05:36:46Z

FWIW, Servo's / Firefox's logic for computed <position>:

https://searchfox.org/mozilla-central/rev/403038737ba75af3842ba6b43b6e2fb47eb06609/servo/components/style/values/computed/position.rs#43

And specified:

https://searchfox.org/mozilla-central/rev/403038737ba75af3842ba6b43b6e2fb47eb06609/servo/components/style/values/specified/position.rs#159

css-meeting-bot · 2018-07-04T08:04:23Z

The Working Group just discussed serialization of <position>, and agreed to the following:

RESOLVED: above
RESOLVED: Any objections to specifying that specified values are serialized
RESOLVED: For <bg-position>, preserve keywords where we can, center turns to top 50%, and where we need to add a keyword use top/left, where we add an offset, use percentages.
RESOLVED: For computed values of <bg-position> and <position>, they are always two <length-percentage> values.

The full IRC log of that discussion

<fantasai> Topic: serialization of <position>
<TabAtkins> The preprocessor features that are :matches()-equivalent explode combinatorially, so the preprocessors trim what they generate. In the common case, nesting expands merely multiplicatively , so they fully expand; so you are already *parsing* a fully-expanded set of selectors.
<ericwilligers> github: https://github.com//issues/2274
<ericwilligers> "<position> is always serialized as 2 or 4 values." or "Neither component may be omitted when serializing."
<fantasai> ericwilligers: I thin we've completely resolved serialization of <position>
<fantasai> fantasai: We already resolved that <bg-position> should serialize same as <position>
<ericwilligers> How exactly does "left 10% center" serialize?
<fantasai> fantasai: Need to resolve that keywords are serialized out in specified value if originally specified as keywords (and not otherwise)
<fantasai> emilio: In which order?
<fantasai> ericwilligers: Horizontal first
<fantasai> emilio: And always both
<fantasai> ericwilligers: Yes
<fantasai> dbaron: It feels like this is saying you have to remember the syntax level, but you don't preserve the number of values in the syntax
<fantasai> dbaron: But you preserve the keywords
<fantasai> ericwilligers: ...
<fantasai> ericwilligers: We're talking about specified values only atm
<fantasai> ericwilligers: Edge sometimes serializes as percentages rather than keywords
<fantasai> ericwilligers: For certian properties
<fantasai> https://github.com//issues/2274#issuecomment-402330108
<ericwilligers> Existing spec: "If only one value is specified, the second value is assumed to be center." "The canonical order when serializing is the horizontal component followed by the vertical component."
<fantasai> ...
<ericwilligers> https://drafts.csswg.org/css-values/#position
<ericwilligers> https://drafts.csswg.org/css-backgrounds-3/#propdef-background-position
<fantasai> astearns: Any objections to specifying that specified values are serialized as keywords if specified as keyword sand percentages if specified as percentages?
<fantasai> RESOLVED: above
<fantasai> RESOLVED: Any objections to specifying that specified values are serialized
<fantasai> as keywords if specified as keyword sand percentages if specified as
<fantasai> percentages?
<fantasai> ericwilligers: If 3 values are specified, we'll need to turn into 4 values
<heycam> ScribeNick: heycam
<heycam> ericwilligers: : "left 10% right" -> "left 10% right 0%"
<dbaron> There was a discussion about 'left 1% center" which is apparently no longer a valid <position> but is a <bg-position>.
<heycam> ericwilligers: "left 10% 20%" -> "left 10% top 20%"
<heycam> s/"left 10% right"/"left 10% bottom"/
<heycam> s/"left 10% right 0%"/"left 10% bottom 0%"/
<heycam> fantasai: if we need a keyword we use top or left, if we need an offset we add a percentage
<heycam> ericwilligers: plus a weird case for center
<dbaron> ericwilligers: we can convert 3 values to 4 values by converting "center" to "top 50%", "bottom" to "bottom 0%", and "20%" to "top 20%"
<heycam> astearns: and there's text in Shapes that does everything you said, except that shapes will convert bottom to top 100%
<heycam> ericwilligers: we've resolved to remove that text, but I can reuse it
<heycam> astearns: I don't mind if it stays as bottom or converts to top
<heycam> fantasai: so left 10% bottom 0% would stay as is, but left 10% bottom would become left 10% top 90%?
<heycam> astearns: yes
<heycam> fantasai: if we're preserving the keyword in the case we have the offset, may as well when we don't too
<heycam> emilio: does everyone support 3 values on background-position?
<heycam> fantasai: yes
<heycam> astearns: we ripped it out everywhere we could, but had to leave it there
<heycam> emilio: ok, I'm fine with that
<heycam> RESOLVED: For <bg-position>, preserve keywords where we can, center turns to top 50%, and where we need to add a keyword use top/left, where we add an offset, use percentages.
<heycam> ericwilligers: earlier talking about computed values, I was incorrect to say we never give keywords. we do sometimes!
<heycam> ... but I don't think we should
<heycam> ... I propose for computed values, it's always <length-percentage>
<heycam> Rossen: or calc()
<heycam> astearns: so for computed values of <bg-position> and <position>, they are always two <length-percentage> values
<heycam> ... no keywords, calc() if needed
<heycam> RESOLVED: For computed values of <bg-position> and <position>, they are always two <length-percentage> values.

See official minutes

Per w3c/csswg-drafts#2274. There's a whole lot of new failures, but those need to be updated along with the spec changes in that issue. We did resolve that position serialized the same everywhere though. Differential Revision: https://phabricator.services.mozilla.com/D1933 --HG-- extra : moz-landing-system : lando

Per w3c/csswg-drafts#2274. There's a whole lot of new failures, but those need to be updated along with the spec changes in that issue. We did resolve that position serialized the same everywhere though. Differential Revision: https://phabricator.services.mozilla.com/D1933

BorisChiou · 2019-07-10T21:05:59Z

It seems this issue is resolved, so could anyone please help update the spec?

Per w3c/csswg-drafts#2274. There's a whole lot of new failures, but those need to be updated along with the spec changes in that issue. We did resolve that position serialized the same everywhere though. Differential Revision: https://phabricator.services.mozilla.com/D1933 UltraBlame original commit: cb6837c0ee5a192ff57bcba2e7dab3a9ff1a5580

tabatkins · 2022-10-12T19:59:29Z

Should be well-defined now. The minutes were slightly unclear, but we believe what's now specified in 0742ad6 matches the details and the intent of the conversation.

fantasai · 2022-10-12T20:04:33Z

Marking Needs Edits for the referencing specs (css-backgrounds, etc.)

cdoublev · 2023-01-21T12:57:10Z

Can I assume the expected changes (in CSS Backgrounds 3) are as follows?

If three values are given, the missing offset is assumed to be zero.
 
  Serializing the 'background-position' is the same as [[css-values-4#position-serialization]].
  If three components are specified:
 
    * 'center' is replaced with 'left 50%' when it is the first component, otherwise with 'top 50%'
    * an omitted offset is replaced with '0%'

fantasai · 2023-10-27T20:50:06Z

For <bg-position>’s 3-value syntax, we currently have interop across all browsers on serializing 3-value inputs as 3-value output, exactly preserving the author's specified components (but rearranging them to horizontal-vertical order, if needed), see testcase.

Agenda to discuss reverting the previous resolution to force these into 4-value serializations, and preserving the author's 3-value expression.

css-meeting-bot · 2023-11-01T23:11:59Z

The CSS Working Group just discussed [css-values] Inconsistent position serialization, and agreed to the following:

RESOLVED: Revert the previous resolution and the serialization for spec value is a 3-value serialization

The full IRC log of that discussion

<TabAtkins> vmpstr, yeah, we'll spec it to just be an OR between the two aliases for each option
<dael> fantasai: We dug through a lot of serialization issues in the past. most edited in. There was some edits for backgrounds to handle 3-value syntax that's not allowed outside of bg-position
<dael> fantasai: Decided we would forse 3 value to 4 value. Looking at impl we noticed we have interop with 3-value serialized as 3-value. Note this is for for computed values. For specified when serialized out all browsers are serializing out as 3 values
<dael> fantasai: Prop reverting previous resolution and keep what browsers are doing now
<dael> astearns: Mainly b/c this is not a big enough deal to force a change?
<dael> fantasai: Yeah, we don't have actual problems with serialization. If you try and take it and put it into a different property there might be problems, but don't do that you're fine. Or grab the computed value and it works.
<dael> astearns: Comments?
<dael> astearns: Prop: Revert the previous resolution and the serialization for spec value is a 3-value serialization
<dael> astearns: Obj?
<dael> RESOLVED: Revert the previous resolution and the serialization for spec value is a 3-value serialization

cdoublev · 2023-11-02T08:18:49Z

Then is there any reason to keep serializing 1-value inputs with 2 values?

edit: never mind, 3-value is specific to <bg-position> whereas 1-value is common to all position-like syntaxes and serializing 2 values simplified to a single value could change the parsing of transform-origin (as noted in CSS Values).

Also, does it mean that 4 values can be simplified to 3 values (in background-position)?

left 1px top 0% to left 1px top
left 1px top 50% to left 1px center
left 1px top 100% to left 1px bottom

I am also not sure if 4 values should be simplified to 2 values:

left 0px top 0% to left top
left 50% top 50% to center center
left 100% top 100% to right bottom

fantasai added cssom-1 Current Work css-values-3 css-values-4 Current Work css-backgrounds-4 labels Feb 5, 2018

fantasai mentioned this issue Feb 14, 2018

[css-shapes] Why does this spec need to special-case serialization of <position>? #2301

Closed

ewilligers mentioned this issue Apr 9, 2018

[css3-images] Parsing tests for images properties web-platform-tests/wpt#9339

Merged

fantasai added Agenda F2F and removed css-values-3 labels Jun 21, 2018

astearns removed the Agenda F2F label Jul 3, 2018

fantasai added the topic: serialization label Sep 30, 2021

astearns mentioned this issue Nov 27, 2021

[css-shapes][css3-backgrounds] No explicit <position> serialization steps in background spec #368

Open

fantasai added a commit that referenced this issue Oct 11, 2022

[css-values-4] Define serialization of specified <position> #2274

0742ad6

fantasai added Closed Accepted by CSSWG Resolution Needs Edits labels Oct 11, 2022

tabatkins removed the Needs Edits label Oct 12, 2022

fantasai added the Needs Edits label Oct 12, 2022

cdoublev mentioned this issue Apr 11, 2023

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

Closed

cdoublev mentioned this issue Jun 22, 2023

[css-values-4][cssom] Serialization of <position> #8996

Closed

fantasai added the Agenda label Oct 27, 2023

css-meeting-bot removed the Agenda label Nov 1, 2023

chromium-helper mentioned this issue Nov 1, 2023

[css-values] Inconsistent position serialization chromium-helper/csswg-resolutions#265

Closed

mozilla-apprentice mentioned this issue Nov 1, 2023

[css-values] Inconsistent position serialization mozilla/wg-decisions#1290

Open

astearns added the Needs Testcase (WPT) label Nov 2, 2023

fantasai added a commit that referenced this issue Nov 22, 2023

[css-backgrounds-3] Define background-position serialization. #2274

ed78c13

fantasai closed this as completed Nov 22, 2023

fantasai removed the Needs Edits label Nov 22, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[css-values] Inconsistent position serialization #2274

[css-values] Inconsistent position serialization #2274

ewilligers commented Feb 5, 2018 •

edited

Loading

css-meeting-bot commented Jul 3, 2018 •

edited by fantasai

Loading

ewilligers commented Jul 4, 2018 •

edited

Loading

ewilligers commented Jul 4, 2018 •

edited

Loading

emilio commented Jul 4, 2018

css-meeting-bot commented Jul 4, 2018 •

edited by fantasai

Loading

BorisChiou commented Jul 10, 2019

tabatkins commented Oct 12, 2022

fantasai commented Oct 12, 2022

cdoublev commented Jan 21, 2023 •

edited

Loading

fantasai commented Oct 27, 2023

css-meeting-bot commented Nov 1, 2023

cdoublev commented Nov 2, 2023 •

edited

Loading

[css-values] Inconsistent position serialization #2274

[css-values] Inconsistent position serialization #2274

Comments

ewilligers commented Feb 5, 2018 • edited Loading

css-meeting-bot commented Jul 3, 2018 • edited by fantasai Loading

ewilligers commented Jul 4, 2018 • edited Loading

ewilligers commented Jul 4, 2018 • edited Loading

emilio commented Jul 4, 2018

css-meeting-bot commented Jul 4, 2018 • edited by fantasai Loading

BorisChiou commented Jul 10, 2019

tabatkins commented Oct 12, 2022

fantasai commented Oct 12, 2022

cdoublev commented Jan 21, 2023 • edited Loading

fantasai commented Oct 27, 2023

css-meeting-bot commented Nov 1, 2023

cdoublev commented Nov 2, 2023 • edited Loading

ewilligers commented Feb 5, 2018 •

edited

Loading

css-meeting-bot commented Jul 3, 2018 •

edited by fantasai

Loading

ewilligers commented Jul 4, 2018 •

edited

Loading

ewilligers commented Jul 4, 2018 •

edited

Loading

css-meeting-bot commented Jul 4, 2018 •

edited by fantasai

Loading

cdoublev commented Jan 21, 2023 •

edited

Loading

cdoublev commented Nov 2, 2023 •

edited

Loading