Pre-h1 page breaks are not suppressed in Windows 11 / Chrome 116

[fraserbennett]

When printing a page, h1 elements have a page break inserted via css/custom.css:

  h1 {
    page-break-before: always;
  }

...but the first h1 element should not have the break inserted:

  h1:first-child {
    page-break-before: unset;
  }

Chrome 116 (at least on Windows 11) does not observe the h1:first-child rule, and merrily inserts a page break before the first h1 element. https://docs.bloomlibrary.org/installing-bloom/ provides a good example of this behavior.

On a possibly related note, https://developer.mozilla.org/en-US/docs/Web/CSS/page-break-before says that page-break-before is deprecated, and that break-before should be used instead.

[andrew-polk]

Maybe I'm not understanding.
Are you reporting the problem on the "Installing Bloom" page due to there being a page break before the "Installing Bloom" heading? Or the "System requirements" heading?

I see no page break for "Installing Bloom". This is properly being prevented by

 h1:first-child {
    page-break-before: unset;
  }

I do see a page break for "System requirements".
This does not match the selector h1:first-child which means match h1 if that element is the first of all its siblings, regardless of the type of those siblings.

If we wanted to not break before the first h1 on the page (after the initial page heading, which is wrapped in an additional heading tag -- in this case "Installing Bloom") we would need

h1:first-of-type {
    page-break-before: unset;
  }

but I don't think we can apply that rule universally. What if there is a significant amount of content between the initial page heading and the next h1?

[fraserbennett]

Yeah, I didn't make myself clear. I didn't catch the fact that the page title (in this case, "Installing Bloom") is the first h1. It's the second h1 that's the problem.

1. Both Chrome 116 and Firefox 117 correctly avoid placing a page break before the first h1, which contains the page title ( "Installing Bloom" ).

2. Chrome puts a page break before the second h1 element ("System requirements"), which is what would be expected from h1 { page-break-before: always; }.
   

3. Firefox, in contrast, does not put a page break before "System requirements" (but does put a page break before the third h1, which also has the content of "Installing Bloom").
   

On the whole, I think the Firefox rendering is better, at least here. I see your point about "what if there is a significant amount of content between the initial page heading and the next h1, but Installing Bloom presents the opposite case of not enough content before the second h1 for a page break to make sense.

This would seem to leave us with 2 options:

Option 1: Train documentation authors not to use h1 in the body of pages, and to insert page breaks via hr when they're needed.

Option 2: Remove the automatic page break before h1, and let authors insert page breaks via hr when they're needed

The problem, of course, is that the location of the desired page breaks may change depending on whether the page is in landscape or portrait orientation -- and different users may want different orientations for different purposes (e.g., printed reference documents vs. screen-projected training materials).

---

FWIW, here's how I might implement Option 2.

-  h1 {
-    page-break-before: always;
-  }
-  h1:first-child {
-    page-break-before: unset;
-  }
-  h2,
-  h3 {
-    page-break-after: avoid;
-  }

+  header h1 {
+    break-before: avoid-page;
+   }
+  h1,
+  h2,
+  h3 {
+    break-after: auto;
+  }