[css-contain] Computed value of shortcut values

[Loirooriol]

contain has 2 shortcut values, strict and content:

strict: This value turns on all forms of containment except style containment for the element. In other words, it behaves the same as contain: size layout paint;.
content: This value turns on all forms of containment except size containment and style containment for the element. In other words, it behaves the same as contain: layout paint;.

But do they compute to themselves, or do they compute to the expanded list of values?

document.documentElement.style.contain = "content";
getComputedStyle(document.documentElement).contain;
// "content" in both Chromium and Firefox

document.documentElement.style.contain = "layout paint";
getComputedStyle(document.documentElement).contain;
// "content" in Chromium, "layout paint" in Firefox

So Chromium expands the shortcuts in the computed value, and when serializing it uses the shortest serialization principle

If component values can be omitted or replaced with a shorter representation without changing the meaning of the value, omit/replace them.

And in Firefox the specified value computes as-is, so content and layout paint are considered to be different values that just happen to produce the same behavior.

Who is correct? Firefox obeys "Computed value: specified keyword(s)", but "[contain: content] behaves the same as contain: layout paint;" could be understood to mean that they have the same computed value.

[SebastianZ]

One solution for that is to add a note to step 2 of the serialization algorithm to handle that case. Something like

If either of the above syntactic translations would be less backwards-compatible or doesn't have a distinct representation, do not perform them.

With that addition in place, the longhand values are kept in case two representations conflict.

Sebastian

[tabatkins]

Hmm. So, the shortcut values don't do anything that's not expressible by just writing some of the longhands. So shortest-serialization would normally imply that a specified contain: layout paint; should serialize as contain: content;.

However, in #5506 (comment) Oriol points out that if we introduce more shorthands that no longer form a strict hierarchy (currently they do), we'll have to deal with ambiguous shortest serializations. Not necessarily a problem, we can just spec our way out of it if necessary.

I'm inclined to specify that the computed value is the set of containments being applied, and they serialize using SSP. That would allow the internal impl to be a bitfield, which is reasonable, and I don't anticipate ever adding something that wouldn't be part of that. I'm happy to specify the application of SSP more specifically, too, to make sure that this is utterly clear.

[emilio]

FWIW Firefox Nightly doesn't give the results from the OP, it gives contain both for specified and computed value.

[css-meeting-bot]

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

The full IRC log of that discussion

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