[css-break] Empty fragment at fragmentainer boundary

[mstensho]

https://drafts.csswg.org/css-break/

If we have an empty, zero-height block, and it occurs exactly at a fragmentainer boundary, where should it end up? In the former fragmentainer, or in the latter?

<div style="columns:2: column-fill:auto; height:100px;">
    <div style="height:100px;"></div>
    <div id="empty"></div>
    <div style="height:50px;"></div>
</div>

Is #empty in the first or second column? If the answer is "second", then how about:

<div style="columns:2: column-fill:auto; height:100px;">
    <div style="height:100px;"></div>
    <div id="empty"></div>
</div>

Should we establish a second column just to hold an empty fragment?

This may not matter for painting and hit-testing, but it's exposable via e.g. getClientRect().

[MatsPalmgren]

Definitely in the former fragment. It's very observable if the zero-height block has abs.pos. children.

Edit: Hmm, on second thought, I take that back. It might just be a quirk/bug in our implementation (Gecko).

(BTW, your example markup isn't visible.)

[mstensho]

(Sorry - fixed the markup)

[fantasai]

This is technically undefined, since we don't define between which elements one is supposed to break--just where one is allowed / discouraged / forbidden from breaking. I'd imagine it'd go in the earlier fragmentainer, since that's what typically happens in other fragmenting modes like inline line breaking and flex line breaking.

[SelenIT]

I'd prefer it going in the earlier fragmentainer, too. I expect the new fragmentainer to be created only if the former one is overflowed, and adding a zero-sized item shouldn't cause overflowing if the fragmentainer wasn't overflowed without it.

[tabatkins]

Yes, everywhere else we do explicitly define breaking, we mandate that zero-size things at a boundary live on the previous line, not the next. (See flexbox, for example.)

Making this clearer in Fragmentation would be good.

[fantasai]

Agenda+ to ask the WG about mandating, specifically for zero-sized elements, that they stay with the earlier fragmentainer is a good idea.

[css-meeting-bot]

The Working Group just discussed Empty fragment at fragmentainer boundary, and agreed to the following:

• RESOLVED: Specify 0 size elements are positioned as early as possible in the fragmentation flow

The full IRC log of that discussion

<dael> Topic: Empty fragment at fragmentainer boundary
<dael> github: https://github.com//issues/1529
<dael> fantasai: About an empty fragment at a fragmentainer boundry. If you have a 0 height block or 0 width inline etc and the previous item that fi there filled the whole line does the 0 size element stay on the page?
<dael> fantasai: Specs don't say anything now about where required to break so UA can be intellengent.
<dael> fantasai: For 0 size might make sense to spec explicitly
<dael> fantasai: Question is do we want to spec that for fragmentation in general or just for flexbox?
<dael> fantasai: flexbox is only place w e define that percisely right now.
<dael> Rossen: I believe we discussedin the past. Don't remember if resolved.
<fantasai> because flexbox requires consistency more than quality-of-implementation, so its breaking rules are defined
<dael> Rossen: As far as I recall reason is the empty elements are exausted opportunitically as much as possible. If there are empty boxes at the end of fragment we assume they fit. Done so you can reduce subsequent fragments.
<dael> Rossen: That makes sense
<dael> Rossen: Other side is such elements or boxes are used for positioning or to create containing blocks or abspos items that go in and out for UI
<dael> Rossen: For those cases harder to argue it's better that such items are consumed asap or pushed. Again, counter is there are avoid break-inside and break-after properties where you can use such and control correctly
<dael> Rossen: In both cases makes snese to position and consume empty boxes a s early aspossible on frag where they are encountered rather then pushing
<dael> Rossen: That's how I remember previous
<dael> Rossen: Curious if there are other arguments or if we can resolve on that and spec it so we don't forget again
<bradk> +1
<dael> Rossen: Obj to Spec 0 size elements are positioned as early as possible in the fragmentation flow?
<dael> RESOLVED: Specify 0 size elements are positioned as early as possible in the fragmentation flow

[fantasai]

OK, added the following:

Additionally, CSS imposes one requirement: a zero-sized box fragment, since it does not take up space, must appear on the earlier side of a fragmentation break if it is able to fit within the fragmentainer.

Note: A zero-sized box fragment can be pushed to the next fragmentainer if it is placed immediately after content that itself overflows the fragmentainer.

Agenda+ to check on the subtleties of a zero-sized fragment that's placed after an overflowing piece of content. :/ CC @mstensho