[css-values] Inconsistent position serialization #2274
Comments
The Working Group just discussed
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 |
Some more test results:
|
All of the above were specified values. There is also variation in computed values.
|
FWIW, Servo's / Firefox's logic for computed And specified: |
The Working Group just discussed
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 |
moz-v2v-gh pushed a commit to mozilla/gecko-dev that referenced this issue
Nov 12, 2018
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
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
It seems this issue is resolved, so could anyone please help update the spec? |
gecko-dev-updater pushed a commit to marco-c/gecko-dev-comments-removed that referenced this issue
Oct 3, 2019
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
gecko-dev-updater pushed a commit to marco-c/gecko-dev-wordified that referenced this issue
Oct 3, 2019
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
gecko-dev-updater pushed a commit to marco-c/gecko-dev-wordified-and-comments-removed that referenced this issue
Oct 3, 2019
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
fantasai added a commit that referenced this issue
Oct 11, 2022
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. |
Marking Needs Edits for the referencing specs (css-backgrounds, etc.) |
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%'
|
For Agenda+ to discuss reverting the previous resolution to force these into 4-value serializations, and preserving the author's 3-value expression. |
The CSS Working Group just discussed
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 |
Then is there any reason to keep serializing 1-value inputs with 2 values? edit: never mind, 3-value is specific to Also, does it mean that 4 values can be simplified to 3 values (in
I am also not sure if 4 values should be simplified to 2 values:
|
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
and others
The
positionspec mentionsbut 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 centerascenter.)Browsers are currently inconsistent with themselves and each other:
<position>, red, blue)<bg-position><position><position><position>)<position>, red, blue)<bg-position><position><position><position>)<position>, red, blue)<bg-position><position><position><position>)<position>, red, blue)<bg-position><position><position><position>)<position>, red, blue)<bg-position><position><position><position>)<position>, red, blue)<bg-position><position><position><position>)<position>, red, blue)<bg-position><position><position><position>)<position>, red, blue)<bg-position><position><position><position>)<position>, red, blue)<bg-position><position><position><position>)<position>, red, blue)<bg-position><position><position><position>)<position>, red, blue)<bg-position><position><position><position>)<position>, red, blue)<bg-position><position><position><position>)<position>, red, blue)<bg-position><position><position><position>)<position>, red, blue)<bg-position><position><position><position>)<position>, red, blue)<bg-position><position><position><position>)<position>, red, blue)<bg-position><position><position><position>)<position>, red, blue)<bg-position><position><position><position>)<position>, red, blue)<bg-position><position><position><position>)The text was updated successfully, but these errors were encountered: