Re: [csswg-drafts] [css-contain] Computed value of shortcut values (#5511)

The CSS Working Group just discussed `computed value of shortcuts`, and agreed to the following:

* `RESOLVED: contain keywords representing a combination of other keywords are defined to compute to those keywords so that they serialize under shortest-serialization princple`

<details><summary>The full IRC log of that discussion</summary>
&lt;fantasai> Topic: computed value of shortcuts<br>
&lt;fantasai> github: https://github.com/w3c/csswg-drafts/issues/5511<br>
&lt;fantasai> TabAtkins: not clear how serialization should work in certain cases<br>
&lt;fantasai> TabAtkins: the 'content' value is equivalent to 'layout paint'<br>
&lt;fantasai> TabAtkins: should it serialize as 'content' or 'layout paint'?<br>
&lt;fantasai> TabAtkins: some differences between browsers<br>
&lt;fantasai> TabAtkins: if we specify shortest serialization principle to use shorthand when possible<br>
&lt;fantasai> TabAtkins: that assumes we'll always have a strict hierarchy of shorthand variables<br>
&lt;fantasai> TabAtkins: if partial overlap, might have multiple shortest-possible serializations<br>
&lt;fantasai> TabAtkins: I think we can spec our way out of that if needed<br>
&lt;fantasai> TabAtkins: Right now, means that the exact value is used<br>
&lt;fantasai> TabAtkins: essentially make ..<br>
&lt;fantasai> TabAtkins: and then go through and use shortest serialization<br>
&lt;fantasai> TabAtkins: so I propose that we serialize the 'contain' property using shortest serialization<br>
&lt;fantasai> TabAtkins: and use shorter values rather than how written<br>
&lt;heycam> fantasai: worth distinguishing between specified and computed values<br>
&lt;fantasai> fantasai: if talking about computed values, then just say that 'content' computes to 'layout paint' and it'll serialize appropriately per rules<br>
&lt;fantasai> fantasai: if talking about specified values, need to be explicit<br>
&lt;fantasai> oriol: Generally, specified values keep keyword as specified, just normalize the order<br>
&lt;fantasai> florian: Doesn't that fall out?<br>
&lt;emilio> q+<br>
&lt;fantasai> TabAtkins: Then it sorts in a particular order<br>
&lt;astearns> ack fantasai<br>
&lt;heycam> fantasai: canonical ordering in our propdef tables<br>
&lt;heycam> fantasai: it'll look at how you've defined the grammar, and serialize based on that order<br>
&lt;fantasai> fantasai: unless you define differently<br>
&lt;fantasai> TabAtkins: I think we need more detail in CSSOM to be clear<br>
&lt;fantasai> TabAtkins: about computed value, sounds like we can just resolve on doing the normal thing and then write tests<br>
&lt;fantasai> florian: don't we need to say that the "compute to" each other?<br>
&lt;fantasai> florian: otherwise they're similar but different values<br>
&lt;astearns> ack emilio<br>
&lt;fantasai> emilio: behavior in Firefox is because we only partially implement some of contain<br>
&lt;fantasai> emilio: but generally, we should serialize the same, the computed and specified values<br>
&lt;fantasai> emilio: I don't see why they should be different. Most properties behave like that if there's no conversion<br>
&lt;fantasai> TabAtkins: I would prefer avoiding specified value conversion here<br>
&lt;fantasai> TabAtkins: so let's leave that off to the side, leave it for computed value serialization<br>
&lt;fantasai> TabAtkins: so I'm find to say that shorthand values compute to appropriate longhands and that falls out<br>
&lt;fantasai> astearns: So proposed resolution is that values are ...?<br>
&lt;fantasai> fantasai: You say the shorthand computes to the longhand, and it'll serialize as the short one<br>
&lt;fantasai> RESOLVED: contain keywords representing a combination of other keywords are defined to compute to those keywords so that they serialize under shortest-serialization princple<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5511#issuecomment-713161854 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Tuesday, 20 October 2020 21:53:42 UTC