Repository navigation
[css-break] Empty fragment at fragmentainer boundary #1529
Description
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().
Activity
MatsPalmgren commentedon Jun 14, 2017
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 commentedon Jun 14, 2017
(Sorry - fixed the markup)
fantasai commentedon Jun 15, 2017
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 commentedon Jun 23, 2017
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 commentedon Jul 28, 2017
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 commentedon Aug 20, 2018
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 commentedon Aug 22, 2018
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 flowThe 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
[css-break-3] Require zero-sized fragments that fit to stay on previo…
fantasai commentedon Aug 23, 2018
OK, added the following:
Agenda+ to check on the subtleties of a zero-sized fragment that's placed after an overflowing piece of content. :/ CC @mstensho
tabatkins commentedon Aug 23, 2018
The most reasonable answer seems clear, and is already reflected in Flexbox: they go to the next fragmentainer.
css-meeting-bot commentedon Aug 29, 2018
The CSS Working Group just discussed
Empty fragment at fragmentainer boundary, and agreed to the following:RESOLVED: have 0 sized fragments pushed to next fragmentainer if content before has overflows its fragmentainerThe full IRC log of that discussion
<dael> Topic: Empty fragment at fragmentainer boundary<fantasai> issue about including padding in scrollable overflow area -- 12 upvootes, more than pretty much any other issue I've seen, + 18 on a comment further down the line supporting it https://github.com//issues/129
<dael> github: https://github.com//issues/1529#issuecomment-415592931
<dael> fantasai: I added text to spec but realized we saida 0 size fragment stays with previous page. Doesn't seem to becase if whatever came before overflows fragmentaner.
<dael> fantasai: If I've got an unbreakable box that overflows and a 0 height after it moves to the next column.
<dael> fantasai: Wanted to check that's what we want.
<dael> fantasai: If anyone wants to look more
<dael> astearns: Makes sense to me. In your note say can be pushed. Perhaps must be pushed?
<dael> fantasai: Makes sense. Change from can to will
<dael> astearns: Okaya
<dael> ??: Should it still be pushed if not content after 0 height thing?
<dbaron> s/??/bradkemper/
<dael> fantasai: Yeah
<dael> bradk: Create a new column with nothing in it
<dael> fantasai: Might have something in it
<dael> bradk: That's useful thing?
<dael> fantasai: is what happens currently. If something is visible generally don't want it below fragmentainer height
<dael> bradk: Alright, you've convinced me
<Rossen_> Are we still preserving the model of minimizing the number of empty boxes due to 0 size fragments
<dael> astearns: Other concerns?
<dael> astearns: Rossen_ on IRC asks [reads]
<dael> astearns: I think that's restating bradk concern...
<dael> fantasai: We're not. Making sure no element starts below end of fragmentaner. Which is good because sometimes can't see below end of fragmentainer it gets clipped
<astearns> Rossen_: OK with that?
<fantasai> s/:/,/
<dael> [waiting for Rossen_ to answer in IRC]
<Rossen_> OK, that's fine. My question was - once an element is to be positined (margins are consumed) and is 0 size - it gets placed on the current fragment right?
<fantasai> see also Tab's note about how this is how Flexbox works already
<fantasai> If we haven't already overflowed the current fragmentainer, yes
<fantasai> If we've already overflowed, no, it moves to the next one
<Rossen_> OK, that makes more sence, thanks
<dael> astearns: Any other questions or concerns?
<dael> astearns: Objections to have 0 sized fragments pushed to next fragmentainer if content before has overflows its fragmentainer?
<dael> RESOLVED: have 0 sized fragments pushed to next fragmentainer if content before has overflows its fragmentainer