[jugaor]

Hello everyone
(and apologies for my bad English… not my native language).

I've been experimenting quite a bit with page-breaks lately and have noticed a few issues:

1. In several places (including a recent post by RbnJrg) I've read that it should be used

  page-break-before: always;
  break-before: column;

as fallback, since "old" apps (CSS2) only recognize the first line, and "modern" apps (CSS3) the second discarding the initial one.
Although there are sites that insist that the second should be break-before: always/all, these don't work (or have stopped doing so).
The other one that does have a little support is break-before: page…

BUT, as always, there are problems:
Google Play Books, Colibrio Reader and Pocketbook don't break with this combination, they only do so if the lines' order is reversed.
Although then Aldiko (Next), Lithium, Reasily and others don't do it.

I have done many many tests (even with the obsolete commands), giving the results I detail in the table.
[attached: 'break tests' epub and table pdf (The "S" is for "SÍ" = "YES")].

Spoiler:

Moon+ ('Preview w/ publisher formatting'), ReadEra, ReadMe, SupReader and many others only use "scroll" mode, so I don't include them.

2. I have also noticed some odd behavior in Android Webview based apps (from v102 onwards), such as Lithium/Reasily/Infinity…
If break-before:column is used, the paragraphs are broken down into multiple pages.
[attached: screenshots]


So, looking to fix issues 1 and 2:

Rather:

.nota {
  page-break-before: always;
  break-before: column;
}

I'm trying:

.nota {
  page-break-before: always;
}

@supports (break-before: column) {
  .nota {
    page-break-before: auto;
    break-before: column;
    break-inside: avoid-column;
  }
}

[attached: example 'simple notes' epub2 (epub3 has the same behavior). If an app uses the second key, the text will be green as a visual clue.]

It has the advantage of
a) work on those that don't read @supports (like Google Play Books and ADE… unfortunately, not Colibrio or Pocketbook)
b) avoid the Webview 102+ bug (and a double page jump in Lithium).

What do you think?
Do you see it as a reliable solution? Could it cause problems in the long run (if they ever fix the bug)?


TIA!

.