Skip to content

[css-break][css-floats] Do fragments float independently? #4434

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
Open
emilio opened this issue Oct 18, 2019 · 6 comments
Open

[css-break][css-floats] Do fragments float independently? #4434

emilio opened this issue Oct 18, 2019 · 6 comments
Labels
css-break-4

Comments

@emilio
Copy link
Collaborator

emilio commented Oct 18, 2019

cc/ #3407.

Consider this test-case:

<!doctype html>
<style>
body { margin: 0 }
#floating {
  width: 25%;
  float: left;
  height: 100px;
  background: green;
}
#content {
  width: 75%;
  float: left;
  height: 100000px;
  background: blue;
}
#container {
  columns: 2;
  column-gap: 0;
}
</style>
<div id="container">
  <div id="floating">
  </div>
  <div id="content">
  </div>
</div>

Should there be a gap between the two columns?

Gecko floats each fragment individually, so the tall blue element's second fragment floats to the left and thus there is no gap between the two columns.

It's not clear to me what is Chromium / WebKit doing, but off-hand I'd expect Gecko's behavior.

That being said, this causes issues in Gecko when printing, when people put fixed positioned stuff inside the other floats, and fixed-positioned elements do appear in multiple pages (and thus content overlaps).

/cc @fantasai @dbaron @aethanyc @MatsPalmgren @mstensho (in case any of you have strong opinions)

A description of what Blink is doing would be useful here.
@emilio
Copy link
Collaborator Author

emilio commented Oct 18, 2019

Test-case in a viewable format: https://bugzilla.mozilla.org/attachment.cgi?id=9102664

emilio added a commit to emilio/rmarkdown that referenced this issue Oct 18, 2019
@emilio
Fix overlapping content while printing on Firefox with a TOC.
6ef6223 
Since there's only one empty left-float, only one page gets pushed to the right.

This is a deeper issue which as far as I can tell is not defined in the
specification, see w3c/csswg-drafts#4434 for an
example with multicol.

This fixes the print issue on Firefox by floating the content to the right,
which produces the desired layout and prevents overlapping the table of
contents.
@emilio emilio mentioned this issue Oct 18, 2019
Merged
@mstensho
Copy link
Contributor

What Gecko does makes sense. Blink does what it does due to implementation limitations. Essentially, the old Blink engine doesn't understand block fragments (the boxes are just tall strips sliced into fragments during painting and hit-testing). LayoutNG fixes this, but NG block fragmentation hasn't shipped yet.

Positioning and sizing each fragment individually makes sense to me - especially since we may have variable inline-size fragmentainers (such as regions or named pages).

@dbaron
Copy link
Member

dbaron commented Oct 22, 2019

So I remembered Gecko code that I thought tried to position later fragments of floats based on where (in the inline-axis) they were in earlier fragments. But maybe I'm misremembering.

I'd also note that the spec should probably go into more detail on what the rules for positioning of floats mean in the presence of fragmentation. The Gecko implementation tries to interpret them, but it should probably be clearer. For example:

  • The rules constraining the "outer top" of a float mean that if one of the things that the "outer top" can't be higher than is pushed to the next fragment, then the float must do so as well, as a matter of logically extending the rules for float positioning to a fragmented context. But where this refers to earlier floats, it only refers to the first fragment of such earlier floats. (I think... there's perhaps the interesting question of whether, given floats A and B within container C, if fragments A1 and B1 both fit within C1, and A2 can't fit at all within C2, is it allowable to fit B2 within C2?)
  • The order of floats is a function of the order of their placeholders; the fragment number doesn't matter (or at least shouldn't; the Gecko code that actually does this is pretty sketchy in the presence of incremental relayout), so the third fragment of a float whose placeholder is earlier comes before the first fragment of a float whose placeholder is later.
  • Only one fragment of a given float can be in a given fragment of its BFC (block formatting context); other than the above (or maybe there are other additions?) the float positioning rules refer to the fragments within the same fragment of the BFC.

yihui pushed a commit to rstudio/rmarkdown that referenced this issue Oct 29, 2019
@emilio @yihui
Fix overlapping content while printing on Firefox with a TOC. (#1675)
26ffc0c 
Since there's only one empty left-float, only one page gets pushed to the right.

This is a deeper issue which as far as I can tell is not defined in the
specification, see w3c/csswg-drafts#4434 for an
example with multicol.

This fixes the print issue on Firefox by floating the content to the right,
which produces the desired layout and prevents overlapping the table of
contents.
@fantasai
Copy link
Collaborator

Related: https://www.w3.org/TR/css-break-3/#breaking-boxes

I think Gecko's behavior is implied in “Layout is performed per-fragmentainer”, but it's not entirely clear. Particularly in light of your examples, it might make more sense to maintain float offsets as if the float that ended is paginated for as long as there are floats stacked alongside it that paginate...

@fantasai fantasai changed the title Do fragments float independently? [css-break][css-floats] Do fragments float independently? Mar 11, 2020
@dbaron
Copy link
Member

dbaron commented Mar 11, 2020

The one other thing I'd note is that the rules for fragmenting floats should probably makes sense in a situation where the fragmentainers are different sizes. I think this can happen today with @page, and there are likely to be more things in the future that cause it. In those cases, the first fragments of floats might fit next to each other, but then later fragments might not.

@mstensho
Copy link
Contributor

The new Blink fragmentation engine shipped in Chrome 102 (almost two years ago), and there's now interop between Gecko and Blink, now that Blink actually performs layout per-fragmentainer. WebKit still behaves like Chrome < 102.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
css-break-4
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@dbaron @fantasai @emilio @mstensho