[css-overflow-4] overflow-clip-margin longhands

[fantasai]

In #7245 we resolved to add the full set of longhands to overflow-clip-margin, but didn't resolve on what we want the shorthand syntax to look like. As a reminder, the current syntax looks like this:

overflow-clip-margin*: <visual-box> || <length [0,∞]>

Since the keyword and length are reorderable and each is optional, we can't simply quadruple the single-value syntax as it would be ambiguous. Possible options are:

• Use a different delimiter, e.g. /, as we did in the grid properties.
• Allow for {1,4} on length but not keyword: <visual-box> || <length [0,∞]>{1,4}
• Allow for {1,4} on keyword but not length: <visual-box>{1,4} || <length [0,∞]>

The middle option gives us syntax that's closest to margin so my suggestion would be to take that. But that does mean some combinations of longhands are not representable in the shorthand.

[Loirooriol]

Analogous for overflow-clip-margin-inline and overflow-clip-margin-block (with 2 values instead of 4).

I suspect that in most cases authors will want to use the same box. That's more tedious to write with the 1st option (and there is the risk of authors writing it only once and assuming it will be used for all sides), and it's not possible with the 3rd option (if the lengths are different).

A 4th option could be <visual-box>{1,4} || <length [0,∞]>{1,4}, which would allow all possible values without having to repeat common ones. But it may be confusing if the values for a given side don't appear next to each other.

Or we could just leave the shorthands as <visual-box> || <length [0,∞]> for now, authors can use longhands if they want something more customized. The grammar can always be extended in the future.

[css-meeting-bot]

The CSS Working Group just discussed [css-overflow-4] overflow-clip-margin longhands, and agreed to the following:

• RESOLVED: Go with (2) for now

The full IRC log of that discussion

<emilio> fantasai: question is how does the shorthand looks like
<emilio> ... one is to use different delimiter as grid
<emilio> ... another is to have box then up to four lengths
<emilio> ... then /missed/
<TabAtkins> I support option 2 (single box keyword, 1-4 lengths)
<emilio> ... oriol proposed 1-to-4 lengths-and-box
<emilio> fantasai: I prefer oriol proposal, then (2)
<emilio> TabAtkins: seems to be the one that matches up most cleanly what people want to do
<emilio> ... single kw and multiple length addresses most cases
<emilio> fantasai: (4) allows you to do one kw but also multiple
<emilio> ... full expansion might be unusual but you don't have to use it
<emilio> ... and it allows all of them
<emilio> astearns: all combinations are allowed in the longhands
<emilio> astearns: oriol, are you ok with (2) or wanna argue for (4)
<emilio> oriol: no strong opinion, would be fine with (2) or even just restricting to 1kw + length
<emilio> proposal is to start with one keyword, we can always expand if needed
<emilio> RESOLVED: Go with (2) for now

[SebastianZ]

I'd argue to split out the <visual-box> value from the longhands into its own overflow-clip-margin-box-* properties. This allows to have a shorthand overflow-clip-margin-box to cover the common use case to set the same box for all sides while still allowing to set the sides individually.

@Loirooriol:

I suspect that in most cases authors will want to use the same box. That's more tedious to write with the 1st option (and there is the risk of authors writing it only once and assuming it will be used for all sides), and it's not possible with the 3rd option (if the lengths are different)

That assumption by authors could actually be specified. I.e. if the box is only specified in the first part, apply it to all four sides. So e.g. content-box 2em / 4em would apply content-box to all four sides while content-box 2em / padding-box 4em would apply content-box in the block axis and padding-box in the inline axis.

The question then is whether 2em / padding-box 4em is interpreted as using the default box (padding-box on non-replaced elements and content-box on replaced elements) in the block axis or being invalid.

Sebastian