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-values] Inconsistent position serialization #2274

Open
ewilligers opened this issue Feb 5, 2018 · 6 comments

Comments

Projects
None yet
6 participants
@ewilligers
Copy link
Contributor

commented Feb 5, 2018

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%
@css-meeting-bot

This comment has been minimized.

Copy link
Member

commented Jul 3, 2018

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

@astearns astearns removed the Agenda+ F2F label Jul 3, 2018

@ewilligers

This comment has been minimized.

Copy link
Contributor Author

commented Jul 4, 2018

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

This comment has been minimized.

Copy link
Contributor Author

commented Jul 4, 2018

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)

@css-meeting-bot

This comment has been minimized.

Copy link
Member

commented Jul 4, 2018

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.

moz-v2v-gh pushed a commit to mozilla/gecko-dev that referenced this issue Nov 12, 2018

Bug 1473184: Remove serialize_basicshape_position. r=xidorn
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

emilio added a commit to emilio/servo that referenced this issue Nov 17, 2018

style: Remove serialize_basicshape_position.
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

This comment has been minimized.

Copy link

commented Jul 10, 2019

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.