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-break] Empty fragment at fragmentainer boundary #1529

Closed
mstensho opened this issue Jun 14, 2017 · 10 comments
Closed

[css-break] Empty fragment at fragmentainer boundary #1529

mstensho opened this issue Jun 14, 2017 · 10 comments
Labels
Closed Accepted by CSSWG Resolution css-break-3 Current Work Needs Testcase (WPT)

Comments

@mstensho
Copy link

mstensho commented Jun 14, 2017 •
edited
Loading

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

MatsPalmgren commented Jun 14, 2017 •
edited
Loading

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

(Sorry - fixed the markup)

@fantasai fantasai added the css-break-3 Current Work label Jun 15, 2017
@fantasai
Copy link
Collaborator

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

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

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

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

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 added a commit that referenced this issue Aug 23, 2018
@fantasai
[css-break-3] Require zero-sized fragments that fit to stay on previo…
f08c0d1 
…us fragmentainer. #1529
@fantasai
Copy link
Collaborator

fantasai commented Aug 23, 2018 •
edited
Loading

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

@tabatkins
Copy link
Member

The most reasonable answer seems clear, and is already reflected in Flexbox: they go to the next fragmentainer.

@css-meeting-bot
Copy link
Member

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 fragmentainer
The 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

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-break-3 Current Work Needs Testcase (WPT)
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
6 participants
@SelenIT @tabatkins @fantasai @MatsPalmgren @mstensho @css-meeting-bot