[css-box-4] Longhand values of `margin-trim` allow more combinations than shorthand values

[SebastianZ]

With the change of #6643 we can now have different combinations of block-* and inline-* values for the margin-trim property.

The current syntax is:

none | block | inline | [ inline-start || inline-end || block-start || block-end ]

This syntax allows combinations of *-start and *-end values that for both block and inline directions. Currently, those cannot be represented by the shorthand values block and inline.

To allow to express those cases in a more condense way, I suggest to allow to combine the longhand and shorthand values.

The syntax would then be:

none |
[ block || inline ] |
[ block || inline-start || inline-end ] |
[ inline || block-start || block-end ] |
[ inline-start || inline-end || block-start || block-end ]

Sebastian

[Loirooriol]

I think it looks simpler like this:

none | [ block | block-start || block-end ] || [ inline | inline-start || inline-end ]

[fantasai]

@Loirooriol Your version doesn't allow full reordering.

[SebastianZ]

@Loirooriol Your version doesn't allow full reordering.

Really? I think the issue is rather that some square brackets are missing, at least for readability.

So the above syntax can be interpreted as

none | [ [ block | [ block-start || block-end ] ] || [ inline | [ inline-start || inline-end ] ] ]

Which seems correct to me.

Sebastian

[Loirooriol]

The brackets can be omitted, see https://drafts.csswg.org/css-values-4/#component-combinators

the double bar is stronger than the bar. Thus, the following lines are equivalent:

  a b   |   c ||   d &&   e f
[ a b ] | [ c || [ d && [ e f ]]]

But yeah I guess || is not associative, since can only be reordered in the same grouping:

For reorderable combinators (||, &&), ordering of the grammar does not matter: components in the same grouping may be interleaved in any order.

[SebastianZ]

The brackets can be omitted, see https://drafts.csswg.org/css-values-4/#component-combinators

I know. That's why I wrote "at least for readability".

But yeah I guess || is not associative, since can only be reordered in the same grouping:

For reorderable combinators (||, &&), ordering of the grammar does not matter: components in the same grouping may be interleaved in any order.

I still don't get that. According to the binding rules and the examples in the spec., your syntax and the one with brackets provided by me seem to be the same. And they both allow all possible combinations and orders, e.g. also inline-start block-end or inline block-end block-start.

Though that aside, I think we agree that the current syntax needs to be changed to allow combining the shorthand with the longhand values, right?

Sebastian

[SebastianZ]

Ah, now I get it! @Loirooriol's suggested syntax doesn't allow combinations like inline-start block-start inline-end or block-end inline block-start.

Sebastian

[fantasai]

I'm not sure this is actually useful, and it certainly makes the grammar more convoluted, but the effect of it is fairly straightforward. Agenda+ to ask the WG what it thinks.

[tabatkins]

The one thing I do note, tho, is that it seems the only way to say you want to trim all the edges is, currently, to list all four explicitly. That seems weird, for what I suspect is a reasonable case.

I suggest either (1) add all, or (2) change the block | inline to [ block || inline]. I favor (1), it's a pattern we use plenty.

[fantasai]

My one hesitation with all is that we might add controls for what's affected in the future (mainly for blocks: does it affect floats, in-flow, or all content?)