[css-align] gap properties for block layout

[benface]

From the CSS Box Alignment Module Level 3 Editor’s Draft:

The gap property, and its row-gap and column-gap sub-properties, provide this functionality for multi-column, flex, and grid layout.

Shouldn't gap and row-gap be functional in block layout too?

e.g.

<ul style="row-gap: 2em;">
    <li>
        No space above this item
    </li>
    <li>
        Space between this item and the ones above and below it
    </li>
    <li>
        No space below this item
    </li>
</ul>

Of course you can get the same effect with margins, but the gap properties are considerably more elegant/cleaner.

[tabatkins]

Margin collapsing and floats and similar complexities of block layout make this much more complicated than for flex/grid/multicol, so we're not planning on trying to make it work. :/

[benface]

Yeah, I don't have a solution for that. I was hoping this could allow us to overrule margin collapsing completely. I didn't think about floats though. Oh well, I guess it's always possible to make that <ul> a column flex container.

[fantasai]

That's a reasonable use case, and it's come up a bunch in the past. How about we repurpose this issue to solve the use case by controlling margins? :) An “eat the first/last margins inside me” switch has been wanted for awhile; Quirks mode tables even did this automatically on table cells.

Here's a first proposal (riffing off https://drafts.csswg.org/css-text-4/#white-space-trim)

margin-trim: none |  in-flow | all

• in-flow trims in-flow collapsed block-axis margins at the start/end of a block container
• all also trims the start/end margins of floated elements at the start/end of the block container

Open question: Should this also trim the edge-adjacent margins of flex items? Grid items?

[jonjohnjohnson]

@fantasai #2848 ???

[css-meeting-bot]

The CSS Working Group just discussed gap properties for block layout, and agreed to the following:

• RESOLVED: Add the margin-trim property with values [ none | in-flow | all ] to css-box-3
• RESOLVED: margin-break controls not just margins at fragmentation breaks, but also at the beginning and end of the fragmentation chain

The full IRC log of that discussion

<heycam> Topic: gap properties for block layout
<fantasai> github: https://github.com//issues/3068
<fantasai> https://github.com//issues/2848
<heycam> fantasai: basically the request from authors is to get rid of the margin at the very top and bottom of an element
<heycam> ... so top before the first element, and bottom of the last element
<heycam> ... suggestion in one is to have a different box-sizing value of some kind
<heycam> ... other suggestion was can we have gaps to do this, add gaps to block layout
<heycam> ... I don't thinkI want to add gaps to block layout
<heycam> ... margin collapsing is its own special thing, fairly complicated
<heycam> ... but we can solve the problem by having a property that gets rid of the margins in the interior of an element
<heycam> ... I think tables do this automatically in quirks mode
<heycam> ... so this proposal is to add a property that would do this, and have an on/off switch, or do it for all items, or only in flow items, or something
<heycam> ... I want to see what people think about this, and whether to add it to the css-box-3 spec
<heycam> TabAtkins: we already have a use case for it in css specs themselves
<heycam> ... notes, examples, etc. have a :first-child { margin-top: 0 } rule, which works unless you start the element with raw text
<heycam> ... so the necessity of making this actually robust seems fairly clear to me
<fantasai> https://github.com//issues/3068#issuecomment-417486499
<heycam> fantasai: there's a rough proposal in this comment
<fantasai> margin-trim: none | in-flow | all
<heycam> ... up for bikeshedding, etc., but that's the starting point proposal
<heycam> florian: that would work on elements that establish a BFC?
<Jia_An> join #tpac-chat
<heycam> fantasai: yes, also reasonable to do on flex containers
<heycam> TabAtkins: does it work on blocks taht don't establish a BFC?
<heycam> fantasai: yes
<heycam> s/taht/that/
<heycam> iank_: is this the same thing as the -webkit-margin-collapse?
<heycam> TabAtkins: I don't know what those are
<heycam> fantasai: it doesn't control collapsing, it switches to discarding
<heycam> TabAtkins: might just be a terminology issue
<heycam> ... I don't know what those properties do
<heycam> iank_: I believe one of the values nukes the whole margin collapsing result
<heycam> ... and just makes it go to 0
<heycam> fantasai: this is different in that it keeps the margin of the element itself, it kills the margin of its first child
<heycam> TabAtkins: the reason why this is important, rather than putting prop on first child, is when the first child is a text node
<heycam> ... if there's an element right after that you want to keep the margin
<heycam> ... either that or have the ability to target text node, which I would rather avoid
<heycam> iank_: is there an example of that in an issue somewhere?
<heycam> TabAtkins: I'll find one
<fantasai> <div>
<fantasai> some text
<fantasai> <p>more text</p>
<fantasai> </div>
<fantasai> <div>
<heycam> florian: if you select the first child with a selector, it might be display none, which would do the wrong thing
<fantasai> <p>some text</p>
<fantasai> <p>more text</p>
<fantasai> </div>
<heycam> eae: sounds like a good idea
<heycam> ... would like to see an example
<heycam> fantasai: in this example, in either case, you don't want margins at the top and bottom of htethe div
<heycam> ... you just want the margin to go away because you've specified how much space you want between the border hwich is visisble, and hte text which is visible
<heycam> ... if you were trying to rely on hte :first-child selector, you could not do this correctly
<heycam> ... since it would select the <p>
<heycam> ... which is after some amount of text
<heycam> ... this is the example Tab pulled from the specs
<fantasai> s/is visible/is visible as 'padding'/
<heycam> TabAtkins: it ends up happening rarely in CSS, since it relies on the first text child not having links in it
<heycam> ... which is rare
<heycam> Rossen: what spec is this going in?
<heycam> fantasai: I would suggest css-box-3, which has no new features right now
<heycam> ... it's just what's in CSS 2 with updated terminoligy
<fantasai> https://www.w3.org/TR/css-box-3/
<heycam> TabAtkins: I agree
<heycam> Rossen: would margin-break go there too?
<heycam> fantasai: there or fragmentation level 4
<heycam> ... which is where box-decoration-break is
<heycam> ... should xref from here for sure
<heycam> Rossen: proposal is to add margin-trim with the values as above
<heycam> TabAtkins: does the all value affect all floats touching the start edge of the container?
<heycam> ... want to make sure that's a reasonable thing to do
<heycam> iank_: I'll have to check
<heycam> Rossen: should be straightforward
<heycam> ... you're positioning your floats in the beginning of your container, and at that time you can decide to trim the margin
<heycam> ... you're not going to affect anything below you at this point
<heycam> ... the thing that will be a bit iffy is when you start pushing margins to the next line
<heycam> ... want to make sure you're not losing the margins, but these are impl details
<heycam> fremy: does the all value also affect the margin at the bottom of a float?
<heycam> ... that seems more problematic
<heycam> ... you don't know when you place the float if you're going to be at the bottom of the element
<heycam> fantasai: if you get to the bottom and the float is what it's causing it to be taller, you can back up to the border edge
<heycam> ... but you're right that is a trickier situation than the top
<heycam> florian: if the margin of the float is pushing the bottom edge, and you can just remove it by changing the rest of the layout, it's fine
<heycam> ... but if removing it entirely, some lines could intrude where they couldn't before
<heycam> ... trim only the amount of the margin that is extending
<heycam> iank_: does this eat just the first and last margin of the first element? or eat the whole collapsing margin?
<heycam> fantasai: the whole collapsed margin
<heycam> florian: the element, its first child, etc., as long as they're collapsing
<heycam> Rossen: just to be sure, when we talk about the first float, we're talking about floats that are at the beginning? two or many adjacent?
<heycam> florian: yes because your goal is to get visual alignment
<heycam> Rossen: just want to be explicit since we keep talking about "the first"
<heycam> ... but with float you can have many
<heycam> TabAtkins: all margins touching the start edge
<heycam> RESOLVED: Add the margin-trim property with values [ none | in-flow | all ] to css-box-3
<heycam> florian: now that we have this and the thing we resolved on before the break, discarding margins around frag breaks, if we go back to Jen's use case
<heycam> ... the first para of first multicol column, we can address it with the thing we just created
<heycam> ... maybe we should also address it with the margin-break thing we were discussing
<heycam> fantasai: I think I would lean towards having both of those properties controlling this particular break
<heycam> florian: in the frag context, you probably want the same beahvioru after the first forced break, and at the beginning
<heycam> ... because there's no desire for the second chapter to look different from the first chapter
<TabAtkins> http://software.hixie.ch/utilities/js/live-dom-viewer/saved/6305 <-- an example of the "zero out the margins of first/last child" strategy giving bad results
<heycam> florian: the summary is that margin-break, the value that causes the margin to be discarded causes it to be discarded not only after breaks, but also at the beginning of the first fragmentainer
<heycam> s/margin-break/margin-break:discard/
<heycam> ... when you explicitly opt in to discarding things, not only discard around breaks, but also at the start
<jensimmons> and at the end?
<heycam> ... effectively you count the start as a forced break
<heycam> fantasai: proposed resolution is that margin-break controls not just margins at fragmentation breaks, but also at the beginning and end of the fragmentation chain
<heycam> Rossen: and this will be an additional requirement on margin-break?
<heycam> fantasai: yes
<heycam> Rossen: and this also applies at the end, not just the start
<heycam> RESOLVED: margin-break controls not just margins at fragmentation breaks, but also at the beginning and end of the fragmentation chain
<gregwhitworth> florian & fantasai: is there a reason that we NEED two seperate properties that are doing the same thing, just in two different contexts?
<fantasai> gregwhitworth, yes, you want to control behavior at breaks and behavior of a container separately
<fantasai> gregwhitworth, also one applies to the element's own margins and one applies to its contents :)

[fantasai]

Added draft of margin-trim to http://drafts.csswg.org/css-box-3/#margin-trim

@benface Would you mind having a look and letting me know if this addresses your use cases? Also if you have any thoughts on the open issues. :)

[fantasai]

See also follow-up issues about whether this should affect flexbox/grid and whether floats should have an independent control at #3256 and #3255

[benface]

@fantasai Yes, that would allow some kind of gap functionality in block layout. :) Thank you!

[ByteEater-pl]

@fantasai

margin-trim: none | in-flow | all

How about adding {1,2} to enable different settings for before and after?