- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Tue, 03 Jul 2018 23:50:15 +0000
- To: public-css-archive@w3.org
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.` <details><summary>The full IRC log of that discussion</summary> <myles> Topic: Inconsistent position serialization<br> <myles> Github: https://github.com/w3c/csswg-drafts/issues/2274<br> <myles> ericwilligers: For one of the properties, the spec is explicit about serialization, and that’s different from all the other ones<br> <myles> ericwilligers: another inconsistency is that all the browsers behave differently from one another<br> <myles> ericwilligers: suggestions?<br> <myles> leaverou: don’t we have a principle that shorter serializations are better?<br> <myles> TabAtkins: yes<br> <myles> leaverou: if we follow that, 50% should not be introduced<br> <myles> leaverou: do that mean if it was specified explicitly, it should be introduced?<br> <myles> dbaron: there are cases where you do need it to be disambiguated. center 10% and 10% center are different<br> <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<br> <myles> ericwilligers: the one that’s different from the others, is that a mistake and they should all the consistent?<br> <myles> emilio: yes<br> <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<br> <myles> emilio: Can we resolve on the special case being outside?<br> <myles> fantasai: All the cases should be the same<br> <emilio> s/outside/removed<br> <myles> Rossen: yes<br> <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”<br> <myles> fantasai: we’re trying to get rid of 3 values<br> <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)<br> <myles> ericwilligers: What about always serialize to a valid <position><br> <myles> fantasai: bgposition should not be allowed in serialization<br> <myles> Rossen: objections?<br> <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.<br> <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<br> <myles> Rossen: yeeeeeup<br> <myles> fantasai: Should we ask Edge to change? To match everyone else? Or are one-value serializations actually good<br> <myles> TabAtkins: This decision applies to typed OM too.<br> <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<br> <myles> heycam: Is this a general principle? Like pairs of numbers that are coordinates, they should always be serialized as two-values?<br> <myles> fantasai: I don’t think that’s valuable<br> <Rossen> s/Rossen: yeeeeeup//<br> <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<br> <myles> fantasai: a more important reason is the transform-origin syntax, which becomes ambiguous if you only have one value<br> <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<br> <myles> fantasai: The proposal: <position> always serializes at least two values<br> <myles> TabAtkins: I’m down with that<br> <myles> Rossen: It means some work for us, but ...<br> <myles> TabAtkins: It means some work for all of us because we’re inconsistent<br> <myles> Rossen: okay.<br> <myles> RESOLVED: All the <position> values serialize to at least two values.<br> <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?<br> <myles> fantasai: not really<br> <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<br> <myles> heycam: I don’t like having to check<br> <myles> fantasai: Are you volunteering to do the checking?<br> <myles> heycam: No<br> <myles> heycam: We should reflect our discussions back in the spec so we don’t have to check<br> <myles> ericwilligers: We may not be testing in all 4 browsers<br> <myles> heycam: So tests may serve this purpose?<br> <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<br> <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<br> <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<br> <myles> ericwilligers: We’re just talking about serialization, not computed value<br> <myles> emilio: It’s essentially the same thing<br> <myles> fantasai: yeah<br> <myles> fantasai: We’re talking about specified values, not computed styles<br> <myles> ericwilligers: Blink would never give you a keyword as a computed value<br> <fantasai> s/fantasai/ericwilligers/<br> <myles> Rossen: What are we thinkging about in terms of 4 value serialization?<br> <myles> Rossen: Should we attempt to do 2 when possible?<br> <myles> plinss: Turning a non-calc into a calc seems weird<br> <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<br> <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<br> <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<br> <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<br> <myles> fantasai: Eric, do you have the test you used for the 4-value syntax?<br> <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<br> <myles> ericwilligers: It takes me a while to get results because I use browser stack.<br> <myles> ericwilligers: If you tell me what you want to know, we can figure it out<br> <astearns> <position> in basic shapes is paragraph 2 of https://drafts.csswg.org/css-shapes/#basic-shape-serialization<br> <fantasai> top 10% left 20%<br> <myles> ericwilligers: With the suggestion that we go down do two unless it introduces a calc, what effect would that be fore background-position?<br> <myles> Rossen: The minute you have top 10% and then center ..<br> <myles> ericwilligers: Peopel were saying “we should never ever go to three”<br> <myles> ericwilligers: right 10% top wil go to 4<br> <myles> ericwilligers: 1 more question: right 10% top should serialize differently from left 10% top???<br> <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<br> <myles> Rossen: but this is after the discussion int eh morning?<br> <myles> fantasai: no, we can do it now<br> <Rossen> s/int eh/in the/<br> <myles> fantasai: Looka t the 3rd table: 30px center. Some of the serializations use 50%, some use the keyword center<br> <myles> fantasai: The table after that: 40px top, some use 0% and some use the keyword top<br> <myles> fantasai: So the question is, do we resolve on outputting the keyword when the percentage would work?<br> <myles> dbaron: The bulk of the boxes are they keyword except 3 of them<br> <myles> dbaron: That said, I don’t know if we should try to go through all of this<br> <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<br> <myles> fantasai: We can look into that over the break.<br> <myles> Rossen: This is where we are going to get a lot more calcs in percentages<br> <myles> Rossen: okay that’s everything for this for now<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2274#issuecomment-402322967 using your GitHub account
Received on Tuesday, 3 July 2018 23:50:21 UTC