CSS page-break-after / before / inside (avoid / always / etc.).

[danielweck]

Issue moved from readium-js-viewer:
readium/readium-js-viewer#217

[acepub]

It would be really helpful if Readium can support page-break-inside: avoid property. The tables and images splitting across the page don't look professional.

[danielweck]

@olivierkorner wrote a nice ContentFilter for ReadiumSDK:
readium/readium-sdk#229

A similar approach in ReadiumJS would not be implemented in _contentDocumentTextPreprocessor (as that's only for transforming HTML files):
https://github.com/readium/readium-js/blob/develop/js/Readium.js#L27

Instead, this would require the full "programmatic resource fetching" triggered by zipped EPUB loading, or by obfuscated fonts, see shouldConstructDomProgrammatically in:
https://github.com/readium/readium-js/blob/develop/js/epub-fetch/iframe_zip_loader.js#L69
...and the actual resource fetcher resolveDocumentLinkStylesheets and resolveDocumentEmbeddedStylesheets:
https://github.com/readium/readium-js/blob/develop/js/epub-fetch/content_document_fetcher.js#L77
Also see _shouldConstructDomProgrammatically = true when _encryptionHandler.isEncryptionSpecified():
https://github.com/readium/readium-js/blob/develop/js/epub-fetch/publication_fetcher.js#L422

Bottom line: I do not think that this is a very realistic approach, because of the caveats associated with "programmatic resource fetching" via BlobURIs (performance, error prone-ness, lack of audio/video streaming, broken Media Overlays).

So, a better approach for ReadiumJS could be to perform a second layout / render path after modifying the CSS-OM (after the DOM is loaded)? to update the computed style?

[kidwm]

I think that after Houdini giving more control to CSSOM would help to solve this problem.

[jccr]

@danielweck
The better approach would be to perform a second layout/render like you said, but we can leverage Shadow DOM and its scoped CSS approach. Using the shadow DOM would also keep CFI references intact :)