Repository navigation
[css-box-4] Longhand values of margin-trim allow more combinations than shorthand values #7884
Description
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
Activity
Loirooriol commentedon Oct 15, 2022
I think it looks simpler like this:
fantasai commentedon Nov 3, 2022
@Loirooriol Your version doesn't allow full reordering.
SebastianZ commentedon Nov 3, 2022
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
Which seems correct to me.
Sebastian
Loirooriol commentedon Nov 3, 2022
The brackets can be omitted, see https://drafts.csswg.org/css-values-4/#component-combinators
But yeah I guess
||is not associative, since can only be reordered in the same grouping:SebastianZ commentedon Nov 3, 2022
I know. That's why I wrote "at least for readability".
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-endorinline 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 commentedon Nov 5, 2022
Ah, now I get it! @Loirooriol's suggested syntax doesn't allow combinations like
inline-start block-start inline-endorblock-end inline block-start.Sebastian
fantasai commentedon Mar 11, 2024
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 commentedon Mar 11, 2024
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 theblock | inlineto[ block || inline]. I favor (1), it's a pattern we use plenty.fantasai commentedon Mar 11, 2024
My one hesitation with
allis that we might add controls for what's affected in the future (mainly for blocks: does it affect floats, in-flow, or all content?)css-meeting-bot commentedon Jun 11, 2024
The CSS Working Group just discussed
[css-box-4] Longhand values of `margin-trim` allow more combinations than shorthand values, and agreed to the following:RESOLVED: Allow combination of 'block' and 'inline' keywords in 'margin-trim'The full IRC log of that discussion
<fantasai> none | block | inline | [ inline-start || inline-end || block-start || block-end ]<jarhar> fantasai: the current syntax of margin trim looks liek this, which doesnt very eaily allow the ability to say all of the sides
<fantasai> none |
<fantasai> [ block || inline ] |
<fantasai> [ block || inline-start || inline-end ] |
<fantasai> [ inline || block-start || block-end ] |
<fantasai> [ inline-start || inline-end || block-start || block-end ]
<jarhar> fantasai: there was a suggestion to allow all possible combinations that make any sense
<jarhar> fantasai: then there was tabs alternative proposal which was to change the block or inline the original syntax to a double or which would look like
<fantasai> none | [ block || inline] | [ inline-start || inline-end || block-start || block-end ]
<jarhar> fantasai: im not sure how often peoplw ant to trim 3 our of 4 sides and if they really want to they can list 3 keywords instead of 2
<jarhar> TabAtkins: the third keyword would be slightly longer
<jarhar> fantasai: i suggest we accept tabs proposal
<una> q+
<jarhar> una: i like it lets do it
<miriam> ack una
<bramus> +1
<jarhar> miriam: the other proposal in there about all, is that something that needs discussion?
<jarhar> TabAtkins: it was my suggestion, i dont care. elikas hesitation ??
<oriol> q+
<jarhar> una: i wouldnt mind having both all and block inline but if there is risk for future compat then im happy with just block inline
<miriam> ack oriol
<TabAtkins> s/??/hesitation about confusion with possible future additions makes sense to me/
<jarhar> oriol: are we then allowing combination of horziontal block wth inline keywords? the second thing you wrote isnt allowing those combinations?
<jarhar> fantasai: yeah you cant write block inline start if you wanted to do that youd have to write block start inline start block end
<jarhar> una: its like margin
<jarhar> fantasai: i think thats ok
<jarhar> fantasai: proposed resolution is to allow the combination of block and inline keywords
<jarhar> miriam: any objections to that resolution?
<fantasai> RESOLVED: Allow combination of 'block' and 'inline' keywords in 'margin-trim'