[css-box-4] Longhand values of `margin-trim` allow more combinations than shorthand values · Issue #7884 · w3c/csswg-drafts · GitHub
Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

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

Closed
SebastianZ opened this issue Oct 15, 2022 · 10 comments · Fixed by #10427
Closed

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

SebastianZ opened this issue Oct 15, 2022 · 10 comments · Fixed by #10427
Labels
Closed Accepted by CSSWG Resolution css-box-4

Comments

@SebastianZ
Copy link
Contributor

SebastianZ commented Oct 15, 2022 •
edited
Loading

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
Copy link
Contributor

I think it looks simpler like this:

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

@fantasai
Copy link
Collaborator

fantasai commented Nov 3, 2022

@Loirooriol Your version doesn't allow full reordering.

@SebastianZ
Copy link
Contributor Author

@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
Copy link
Contributor

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
Copy link
Contributor Author

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

@Loirooriol Loirooriol mentioned this issue Nov 4, 2022
Closed
@SebastianZ
Copy link
Contributor Author

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
Copy link
Collaborator

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
Copy link
Member

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
Copy link
Collaborator

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?)

@astearns astearns moved this to Unsorted in CSSWG June 2024 meeting Jun 3, 2024
@astearns astearns moved this from Unsorted to Wednesday morning in CSSWG June 2024 meeting Jun 3, 2024
@astearns astearns closed this as completed by moving to Wednesday morning in CSSWG June 2024 meeting Jun 3, 2024
@astearns astearns reopened this Jun 3, 2024
@astearns astearns moved this from Wednesday morning to Wed morning in CSSWG June 2024 meeting Jun 3, 2024
@css-meeting-bot
Copy link
Member

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'

@chromium-helper chromium-helper mentioned this issue Jun 11, 2024
Closed
@mozilla-apprentice mozilla-apprentice mentioned this issue Jun 11, 2024
Open
@SebastianZ SebastianZ mentioned this issue Jun 11, 2024
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Closed Accepted by CSSWG Resolution css-box-4
Projects
CSSWG June 2024 meeting
Status: Tuesday afternoon
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

[css-box-4] Allowed combination of block and inline keywords in margin-trim SebastianZ/csswg-drafts
6 participants
@tabatkins @fantasai @SebastianZ @astearns @Loirooriol @css-meeting-bot