[css-contain-2] Combination of shortcuts and values

[TimVevida]

In the CSS containment spec, the values strict and content are shortcut values, indicating multiple values. The spec says either a shortcut value or a combination of values can be used, but not both.

However, in the example of the content value, the combination of strict style is shown, which should not be possible according to the spec.

So either:

• Allow both shortcut values and regular values in the declaration.
• Update the said example.

[tabatkins]

Hm, indeed.

I think the example is useful - being able to say "everything that strict does, plus style containment" seems reasonable, which is presumably why I wrote the example that way in the first place. ^_^

So I'm inclined to allow combination. Further questions, then:

• do we want to be strict about combining the shorthands only with additional values? That is, would strict size be valid (equivalent to just strict) or invalid? I'm inclined to say it's fine, but I could go either way. Saying it's invalid is slightly annoying to specify in the grammar, but not too bad.
• if we rule that the previous question is "it's valid", is it okay to repeat the same keyword, like size size? I'm inclined to say no, that's a clearer error.

[TimVevida]

I agree that a combination of shorthands and values should be possible. Just yesterday, I wanted to use content style but this was not permitted (in Chrome) and I had to write layout paint style which is not terrible, but raises more questions than being able to use the shorthand.

I am inclined to say that any combination of unique shorthands and values should be possible. I assume UAs already expand the shorthands to a set of values and it is relatively easy to add a single value to this set. And when this value already exists in the set it is ignored (because it is a set and not a list).
That being said, it could be an argument that users should be trained to use the correct values and allowing duplicates - even via a shorthand - is therefore not permitted.

[SebastianZ]

I am slightly inclined to only allowing combinations with additional values as it pushes authors to read a bit about the values, as @TimVevida wrote, it's logically a bit cleaner, and because there are no other properties with such duplications.

The syntax would then be

none | [ strict || style ] | [ content || size || style ] | [ size || layout || style || paint ]

Sebastian

[Loirooriol]

IMO this depends on #5511. If shortcut values have the same computed value as the expanded list of values, according to the shortest serialization principle the serialization should try to use shortcuts.

However, if we allow mixing shortcuts with other values, we may end up having multiple minimal solutions. For example, we have content = layout paint, if in the future we add foobar = style paint, then layout style paint could be serialized as either content style or foobar layout.

So if we allow mixing shortcuts with other values, I think we should either:

• In [css-contain] Computed value of shortcut values #5511 say that shortcut values compute as-is and not to the expanded list of values
• Do not use the shortest serialization principle, serialize using the expanded list of values instead of shortcuts
• Never add a new shortcut which has some values in common with another shortcut but some values are different (i.e. non-disjoint sets which are not subsets one of the other).

[SebastianZ]

Good point about the serialization! As the decision in #5511 will also apply to the changes requested here, let's discuss them there.

Sebastian

[frivoal]

Note that currently, all implementations (Gecko and Blink at least, is there another one) reject combining the shortcut values and the other values. I think the syntax shown in #5506 (comment) is pretty reasonable, but that's not the one we specified or that was implemented.

It might have been a little better if we started out this way, but I don't see a whole lot of value changing at this point, and I suggest we just fix the non conforming note.

That said, if implementations are interested in changing, I don't think it's a bad idea per se, so I'm not opposed.