Re: [csswg-drafts] [css-values] Inconsistent position serialization

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.`

<details><summary>The full IRC log of that discussion</summary>
&lt;fantasai> Topic: serialization of &lt;position><br>
&lt;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.<br>
&lt;ericwilligers> github: https://github.com/w3c/csswg-drafts/issues/2274<br>
&lt;ericwilligers> "&lt;position> is always serialized as 2 or 4 values." or "Neither component may be omitted when serializing."<br>
&lt;fantasai> ericwilligers: I thin we've completely resolved serialization of &lt;position><br>
&lt;fantasai> fantasai: We already resolved that &lt;bg-position> should serialize same as &lt;position><br>
&lt;ericwilligers> How exactly does "left 10% center" serialize?<br>
&lt;fantasai> fantasai: Need to resolve that keywords are serialized out in specified value if originally specified as keywords (and not otherwise)<br>
&lt;fantasai> emilio: In which order?<br>
&lt;fantasai> ericwilligers: Horizontal first<br>
&lt;fantasai> emilio: And always both<br>
&lt;fantasai> ericwilligers: Yes<br>
&lt;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<br>
&lt;fantasai> dbaron: But you preserve the keywords<br>
&lt;fantasai> ericwilligers: ...<br>
&lt;fantasai> ericwilligers: We're talking about specified values only atm<br>
&lt;fantasai> ericwilligers: Edge sometimes serializes as percentages rather than keywords<br>
&lt;fantasai> ericwilligers: For certian properties<br>
&lt;fantasai> https://github.com/w3c/csswg-drafts/issues/2274#issuecomment-402330108<br>
&lt;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."<br>
&lt;fantasai> ...<br>
&lt;ericwilligers> https://drafts.csswg.org/css-values/#position<br>
&lt;ericwilligers> https://drafts.csswg.org/css-backgrounds-3/#propdef-background-position<br>
&lt;fantasai> astearns: Any objections to specifying that specified values are serialized as keywords if specified as keyword sand percentages if specified as percentages?<br>
&lt;fantasai> RESOLVED: above<br>
&lt;fantasai> RESOLVED: Any objections to specifying that specified values are serialized<br>
&lt;fantasai>                   as keywords if specified as keyword sand percentages if specified as<br>
&lt;fantasai>                   percentages?<br>
&lt;fantasai> ericwilligers: If 3 values are specified, we'll need to turn into 4 values<br>
&lt;heycam> ScribeNick: heycam<br>
&lt;heycam> ericwilligers: : "left 10% right" -> "left 10% right 0%"<br>
&lt;dbaron> There was a discussion about 'left 1% center" which is apparently no longer a valid &lt;position> but is a &lt;bg-position>.<br>
&lt;heycam> ericwilligers: "left 10% 20%" -> "left 10% top 20%"<br>
&lt;heycam> s/"left 10% right"/"left 10% bottom"/<br>
&lt;heycam> s/"left 10% right 0%"/"left 10% bottom 0%"/<br>
&lt;heycam> fantasai: if we need a keyword we use top or left, if we need an offset we add a percentage<br>
&lt;heycam> ericwilligers: plus a weird case for center<br>
&lt;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%"<br>
&lt;heycam> astearns: and there's text in Shapes that does everything you said, except that shapes will convert bottom to top 100%<br>
&lt;heycam> ericwilligers: we've resolved to remove that text, but I can reuse it<br>
&lt;heycam> astearns: I don't mind if it stays as bottom or converts to top<br>
&lt;heycam> fantasai: so left 10% bottom 0% would stay as is, but left 10% bottom would become left 10% top 90%?<br>
&lt;heycam> astearns: yes<br>
&lt;heycam> fantasai: if we're preserving the keyword in the case we have the offset, may as well when we don't too<br>
&lt;heycam> emilio: does everyone support 3 values on background-position?<br>
&lt;heycam> fantasai: yes<br>
&lt;heycam> astearns: we ripped it out everywhere we could, but had to leave it there<br>
&lt;heycam> emilio: ok, I'm fine with that<br>
&lt;heycam> RESOLVED: For &lt;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.<br>
&lt;heycam> ericwilligers: earlier talking about computed values, I was incorrect to say we never give keywords. we do sometimes!<br>
&lt;heycam> ... but I don't think we should<br>
&lt;heycam> ... I propose for computed values, it's always &lt;length-percentage><br>
&lt;heycam> Rossen: or calc()<br>
&lt;heycam> astearns: so for computed values of &lt;bg-position> and &lt;position>, they are always two &lt;length-percentage> values<br>
&lt;heycam> ... no keywords, calc() if needed<br>
&lt;heycam> RESOLVED: For computed values of &lt;bg-position> and &lt;position>, they are always two &lt;length-percentage> values.<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-402398299 using your GitHub account

Received on Wednesday, 4 July 2018 08:04:36 UTC