BUG: break-after:avoid ignored for table rows in certain situations

[Binarus]

According to the Weasyprint documentation, break-before and break-after are supported for pages:
https://doc.courtbouillon.org/weasyprint/stable/api_reference.html#css-fragmentation-module-level-3-4

I am not sure whether this is true especially for table elements. I am currently trying to avoid page breaks between certain table rows with different methods, but I have no success. This is what I have tried so far (only the relevant fragments):

Styles:

tr.main { break-after: avoid; }
tr.main td { break-after: avoid; }

HTML:

...
<table>
<tbody>
<tr class="main"><td>m1</td><td>m2></td></tr>
<tr class="detail"><td>d1</td><td>d2></td></tr>
... <!-- many repetitions of the above two lines here, so that the table takes more than one page -->
<tr class="main"><td>m1</td><td>m2></td></tr>
<tr class="detail"><td>d1</td><td>d2></td></tr>
</tbody>
</table>
...

The problem is that Weasyprint happily inserts a page break between a "main" and a "detail" table row, despite the CSS which should avoid such breaks.

I have to admit that it's not clear to me whether or not break avoids should work when applied to table elements. Some articles on the web state that they should work, some state that they shouldn't, and some state the browser support varies.

According to my own tests, they work in modern browsers. For example, in my tests, neither Chromium nor Firefox in Linux did page-break the table between a "main" and a "detail" row. But Weasyprint did.

Before eventually reporting a bug, I'd like to know what Weasyprint is expected to do in such situations.

Thank you very much in advance!

[grewn0uille]

Hi,

break-* are supported for table elements.

What do you get with this? I added backgrounds to highlight better the lines and a top margin to get the page break.

<style>
  table { margin-top: 22cm; background: pink;}
  tr.main { break-after: avoid; background: lightgreen; }
  tr.main td { break-after: avoid; }
</style>

<table>
<tbody>
<tr class="main"><td>m1</td><td>m2></td></tr>
<tr class="detail"><td>d1</td><td>d2></td></tr>
<tr class="main"><td>m1</td><td>m2></td></tr>
<tr class="detail"><td>d1</td><td>d2></td></tr>
<tr class="main"><td>m1</td><td>m2></td></tr>
<tr class="detail"><td>d1</td><td>d2></td></tr>
<tr class="main"><td>m1</td><td>m2></td></tr>
<tr class="detail"><td>d1</td><td>d2></td></tr>
</tbody>
</table>

On my side, here is what I get. The page break occurs after a detail row, while there is the space for the next row. The break-after: avoid looks respected.

[Binarus]

Thank you very much for that example. It helps a lot to know that it should work, and that it indeed does work in normal situations.

However, I have an example where it does not work (it's basically the same example as in my previous report). I'll try to shorten it as much as possible, and then post it here.

[Binarus]

Here is a reduced example to reproduce the error:

test.html

Please note the two lines at the end of the style declarations that should prevent a page break after a row of class "description".

The screenshot of the generated PDF shows that there is a page break between the second "Description" row and the "Service ID: 31" row. This means that tr.description { break-after: avoid } and tr.description td { break-after: avoid } are ignored (probably only one of these is needed).

Perhaps that could be related to the <thead> which does not exist in your sample, but exists in mine. That will be the next thing I'll investigate and report back.

I really hope that it's not a silly mistake in my CSS declarations that causes the problem.

Screenshot

[Binarus]

I have found the culprit.

The <thead> is not related to the problem. But please note the following fragment in the style declarations of my sample:

    h1, h2, h3, p, tr, .nopagebreak {
      break-inside: avoid-page;
    }

If I remove it, or even remove only the tr, from the first line, tr.description { break-after: avoid; } becomes effective, so that the second "Description" row is moved to the second page.

But that's only a workaround, and I don't understand why it changes things. It's not a solution to the problem because it causes a new (worse) problem: After removing that fragment there is nothing left which forbids page breaks in the (vertical) middle of a row.

Therefore, we need both in that situation: avoid page breaks inside every row, and avoid page breaks after rows of class description.

We'll see if we find a further workaround to achieve that. Perhaps Weasyprint has difficulties with combining these two avoids correctly if they are in different CSS declarations.

[grewn0uille]

Good call with the break-inside: avoid!

I can reproduce. Here is a smaller reproducer:

<html>
  <head>
    <style>
      table {
        border-collapse: collapse;
        margin-top: 19.5cm;
      }
      tr { break-inside: avoid; }
      tr.description { break-after: avoid; height: 5.5em;}
    </style>
  </head>
  <body>
    <table>
      <tr class="description"><td>Description</td></tr>
      <tr><td>Service ID: 1</td></tr>
      <tr><td>Service ID: 2</td></tr>
      <tr class="description"><td>Description</td></tr>
      <tr><td>Service ID: 31</td></tr>
      <tr><td>Service ID: 32</td></tr>
    </table>
  </body>
</html>

[Binarus]

Thank you very much for the reproducer!

After playing around a bit more, my gut feeling is that there's a piece of code somewhere in the processing pipeline that assumes that every <tr> has the same break-* properties assigned, regardless of which class(es) the <tr> belongs to, and regardless of the nesting of the <tr> in the chain of ancestors in the CSS or HTML, and that breaks things (pun intended) if that's not the case.

At the moment, we can circumvent the problem by removing the tr, from the code in question as shown in my previous post, then adding this to the styles:

    table.order > tbody > tr.description {
      break-after: avoid;
      break-inside: avoid;
    }

We're lucky here:

First, rows in <thead> and <tfoot> will not be broken across pages. Second, we have quite a few row classes other than description in that table (not shown in my samples so far, except rows of class service), but each cell in them contains one line only. We can safely assume (hopefully) that such rows will not be broken, too. Third, we have rows of class description, which will be covered by the code shown above.

That is, we're lucky in that we only need to cover one single class of rows.

In all of my tests, as soon as I attached break-after: avoid or break-inside: avoid to a tr that belongs to no class or to another class, things stopped to work, regardless of the chain of ancestors for that tr.

Sorry that this post is quite long again; I wrote it in the hope that it helps debug the problem.

[Binarus]

Before leaving the subject to the experts, here's a final statement (as a note to myself and in the hope to help with debugging). I have found a workaround that makes the code more ugly, but is a general approach to the problem. That is, different classes of rows with different chains of ancestors can be managed. Here are the steps:

First, remove any CSS declaration that contains any break-* property from my sample file (or @grewn0uille's sample file).

Then, add the following CSS declarations to the file:

    .noinsidebreak {
      break-inside: avoid;
    }
    .noafterbreak {
      break-after: avoid;
    }

Last, change the HTML code as follows (only a relevant fragment is shown):

<tr class="description noinsidebreak noafterbreak">
<td>1</td>
<td>2</td>
<td>Description<br />Description<br />Description<br />Description<br /></td>
<td></td>
<td></td>
</tr>

That is, simply add the noinsidebreak and / or the noafterbreak classes to the table rows that should not be broken inside / afterwards.

This seems to work reliably and eventually means that the problem is located in the parsing stage rather than in the layout and rendering stage.

Silly me that I didn't come to that idea earlier. We can implement that workaround easily just by changing the templates that are used to generate the tables.

Nevertheless, we would be glad if the bug could be resolved 😀. We'll happily assist with testing or other actions that help.