WebKit print engine silently ignores break-inside: avoid-page — complex CSS layouts require Chrome workaround

Question

Product: Marked 3
Component: PDF Export / Print Engine
Severity: High — affects all complex CSS print layouts
Type: Known Engine Limitation (WebKit) — Documentation & Workaround Needed

Summary

Safari/WebKit's print engine does not support break-inside: avoid-page in paged media contexts. This is confirmed by both MDN Browser Compatibility Data and caniuse — version_added: false for Safari, meaning it has never been implemented and is not on a known roadmap.

For documents using complex CSS print layouts, this causes silent, unfixable fragmentation at the PDF export stage inside Marked.

Symptoms

Users with complex CSS stylesheets will experience the following during Marked's native PDF export:

Page fragmentation mid-block on elements that should be treated as atomic units
Blockquote and decorative box containers splitting across page boundaries
Clipping of elements using custom font engines or RTL text (Hebrew, Arabic, etc.)
CSS fragmentation rules appearing to have no effect despite correct syntax

Root Cause

WebKit's print engine does not implement break-inside: avoid-page. The property is part of the CSS Fragmentation Module Level 3 spec but has never shipped in Safari or any WebKit-based renderer.

Confirmed sources:

MDN Browser Compatibility Data — version_added: false for Safari in paged media context
caniuse: break-inside: avoid-column — confirms column variant supported, page variant absent

This means any CSS rule of the form:

break-inside: avoid-page;

is silently ignored by WebKit at print time. No error, no fallback, no warning — the property simply has no effect.

Note: break-inside: avoid (the generic, unsuffixed value) is supported in Safari since v10 and should be used instead where possible. The specific avoid-page variant is what is absent.

Impact

This is not a Marked bug — it is a WebKit engine limitation outside Marked's control. However, because Marked's PDF export uses WebKit as its print backend, users will hit this ceiling and spend significant time attempting CSS fixes that are silently no-ops.

For power users relying on Marked as a complete Markdown-to-PDF pipeline — particularly those with custom stylesheets, Hebrew/RTL typography, complex blockquote layouts, or decorative print elements — this creates a broken link in the core value proposition of the product.

Workaround

The only currently reliable workaround is:

Use Marked to preview and process the document
Export to standalone HTML
Open in Google Chrome
Print to PDF via Chrome's Blink/Chromium print engine

Chrome has supported break-inside: avoid-page in paged media since v51 (2016) and handles complex CSS fragmentation correctly.

This workaround is functional but requires leaving Marked's native workflow entirely for the final export step.

Questions for Marked Support

Is there a known CSS pattern or Marked-specific workaround for this limitation beyond the Chrome export path?
Is an alternative print engine (e.g. Chromium-based) on the roadmap for Marked's PDF export?
Would a documentation note or warning in Marked's CSS/print guide be feasible to prevent other users from spending time debugging this?

Report prepared by a Marked power user. Diagnostic work confirmed via MDN BCD data, caniuse, and extensive cross-browser testing.

Brett Terpstra · Answer

Marked 3 does not actually use the WebKit print system anymore, as the version of WebKit used in Marked causes an immeediate crash on Apple Silicon machines when printing with headers and footers.

Marked uses JavaScript to handle pagination, and does its best to respect page-break rules. If you're having specific issues as noted abo ve, please provide examples of the CSS and Markdown that demonstrates the issue.