Bugzilla

Not wanting to debate really (particularly not on Bugzilla), but I want to clarify/address a few points:

(In reply to chris.spittles from comment #6)
> People will use this to lay out pages or page parts that will require printing. Deciding behaviour like this massively affects how it can be used.

It's worth emphasizing that this is **only an issue when a single grid row is taller than a page**.  If someone uses a grid to lay out "pages or page-parts" as you mentioned, with grid-rows that are smaller than a page or simply as-large-as a printed page, then everything should be fine and they wouldn't run into this issue. It's only when there's a single grid-row that is taller-than-a-page that will cause that grid-row to get pushed to the next page. 

Having said that, this is admittedly easy-to-trip for some sorts of layout, e.g. a traditional 3-column layout with a tall multiple-pages-long article in the middle.  If the grid container in this situation is only defined with a single row, then it'll likely run up against this issue.

> Whether that [printing/splitting] behaviour was decided by Mozilla, or by W3,

The CSS grid spec has a [fragmentation (pagination) section](https://drafts.csswg.org/css-grid-1/#pagination) that doesn't define how pagination should work -- it does say page-breaks can occur between grid rows, and doesn't really say more than that.   That happens to be roughly what we do right now, allowing pagebreaks between grid-rows (with more complicated behavior to handle splitting up the child elements that happen to straddle those pagebreaks-between-rows).

> I can't see this issue in any other browser, they behave as you might expect.

Other browsers absolutely do have rough edges in this neighborhood. :) It's possible their heuristics for simple cases have happened to avoid this sort of issue for the particular content you've been working on, but there are absolutely variants of testcase 1 that render in a similarly-broken way in WebKit and Chrome (which we handle better in some cases).

I'll attach one example that I just came up with, which renders broken in Chrome and WebKit (and "differently-broken").  Suffice to say that splitting a **grid row** that's taller than a page is non-trivial in general, and any approach will be problematic for some set of content.  It's possible we could add special cases for simple situations (and perhaps that's what Chrome and/or Safari have done?), though for now we've just got our general approach discussed in comment 2.

Not wanting to debate really (particularly not on Bugzilla), but I want to clarify/address a few points:

(In reply to chris.spittles from comment #6)
> People will use this to lay out pages or page parts that will require printing. Deciding behaviour like this massively affects how it can be used.

It's worth emphasizing that this is **only an issue when a single grid row is taller than a page**.  If someone uses a grid to lay out "pages or page-parts" as you mentioned, with grid-rows that are smaller than a page or simply as-large-as a printed page, then everything should be fine and they wouldn't run into this issue. It's only when there's a single grid-row that is taller-than-a-page that will cause that grid-row to get pushed to the next page (if it looks like the next page will have more space).

Having said that, this is admittedly easy-to-trip for some sorts of layout, e.g. a traditional 3-column layout with a tall multiple-pages-long article in the middle.  If the grid container in this situation is only defined with a single row, then it'll likely run up against this issue.

> Whether that [printing/splitting] behaviour was decided by Mozilla, or by W3,

The CSS grid spec has a [fragmentation (pagination) section](https://drafts.csswg.org/css-grid-1/#pagination) that doesn't define how pagination should work -- it does say page-breaks can occur between grid rows, and doesn't really say more than that.   That happens to be roughly what we do right now, allowing pagebreaks between grid-rows (with more complicated behavior to handle splitting up the child elements that happen to straddle those pagebreaks-between-rows).

> I can't see this issue in any other browser, they behave as you might expect.

Other browsers absolutely do have rough edges in this neighborhood. :) It's possible their heuristics for simple cases have happened to avoid this sort of issue for the particular content you've been working on, but there are absolutely variants of testcase 1 that render in a similarly-broken way in WebKit and Chrome (which we handle better in some cases).

I'll attach one example that I just came up with, which renders broken in Chrome and WebKit (and "differently-broken").  Suffice to say that splitting a **grid row** that's taller than a page is non-trivial in general, and any approach will be problematic for some set of content.  It's possible we could add special cases for simple situations (and perhaps that's what Chrome and/or Safari have done?), though for now we've just got our general approach discussed in comment 2.

Not wanting to debate really (particularly not on Bugzilla), but I want to clarify/address a few points:

(In reply to chris.spittles from comment #6)
> People will use this to lay out pages or page parts that will require printing. Deciding behaviour like this massively affects how it can be used.

It's worth emphasizing that this is **only an issue when a single grid row is taller than a page**.  If someone uses a grid to lay out "pages or page-parts" as you mentioned, with grid-rows that are smaller than a page or simply as-large-as a printed page, then everything should be fine and they wouldn't run into this issue. It's only when there's a single grid-row that is taller-than-a-page that will cause that grid-row to get pushed to the next page (if it looks like the next page will have more space).

Having said that, this is admittedly easy-to-trip for some sorts of layout, e.g. a traditional 3-column layout with a tall multiple-pages-long article in the middle.  If the grid container in this situation is only defined with a single row, then it'll likely run up against this issue if there's content before it; it'll get pushed to the next page in an attempt to fit better.

> Whether that [printing/splitting] behaviour was decided by Mozilla, or by W3,

The CSS grid spec has a [fragmentation (pagination) section](https://drafts.csswg.org/css-grid-1/#pagination) that doesn't define how pagination should work -- it does say page-breaks can occur between grid rows, and doesn't really say more than that.   That happens to be roughly what we do right now, allowing pagebreaks between grid-rows (with more complicated behavior to handle splitting up the child elements that happen to straddle those pagebreaks-between-rows).

> I can't see this issue in any other browser, they behave as you might expect.

Other browsers absolutely do have rough edges in this neighborhood. :) It's possible their heuristics for simple cases have happened to avoid this sort of issue for the particular content you've been working on, but there are absolutely variants of testcase 1 that render in a similarly-broken way in WebKit and Chrome (which we handle better in some cases).

I'll attach one example that I just came up with, which renders broken in Chrome and WebKit (and "differently-broken").  Suffice to say that splitting a **grid row** that's taller than a page is non-trivial in general, and any approach will be problematic for some set of content.  It's possible we could add special cases for simple situations (and perhaps that's what Chrome and/or Safari have done?), though for now we've just got our general approach discussed in comment 2.

Not wanting to debate really (particularly not on Bugzilla), but I want to clarify/address a few points:

(In reply to chris.spittles from comment #6)
> People will use this to lay out pages or page parts that will require printing. Deciding behaviour like this massively affects how it can be used.

It's worth emphasizing that this is **only an issue when a single grid row is taller than a page**.  If someone uses a grid to lay out "pages or page-parts" as you mentioned, with grid-rows that are smaller than a page or simply as-large-as a printed page, then everything should be fine and they wouldn't run into this issue. It's only when there's a single grid-row that is taller-than-a-page that will cause that grid-row to get pushed to the next page (if it looks like the next page will have more space).

Having said that, this is admittedly easy-to-trip for some sorts of layout, e.g. a traditional 3-column layout with a tall multiple-pages-long article in the middle.  If the grid container in this situation is only defined with a single row, then it'll likely run up against this issue if there's content before it; it'll get pushed to the next page in an attempt to fit better.

> Whether that [printing/splitting] behaviour was decided by Mozilla, or by W3,

The CSS grid spec has a [fragmentation (pagination) section](https://drafts.csswg.org/css-grid-1/#pagination) that doesn't define how pagination should work -- it does say page-breaks can occur between grid rows, and doesn't really say more than that.   That happens to be roughly what we do right now, allowing pagebreaks between grid-rows (with more complicated behavior to handle splitting up the child elements that happen to straddle those pagebreaks-between-rows).

> I can't see this issue in any other browser, they behave as you might expect.

Other browsers absolutely do have rough edges in this neighborhood. :) It's possible their heuristics for simple cases have happened to avoid this sort of issue for the particular content you've been working on, but there are absolutely variants of the attached testcase from comment 0 here that render in a similarly-broken way in WebKit and Chrome (which we handle better in some cases).

I'll attach one example that I just came up with, which renders broken in Chrome and WebKit (and "differently-broken").  Suffice to say that splitting a **grid row** that's taller than a page is non-trivial in general, and any approach will be problematic for some set of content.  It's possible we could add special cases for simple situations (and perhaps that's what Chrome and/or Safari have done?), though for now we've just got our general approach discussed in comment 2.