Prince renders HTML somewhat different than browsers and doesn't support the latest HTML + CSS standards, why choose it for new stuff over headless chrome and/or puppeteer?

I use PrinceXML at work, for generating press-ready output. (E.g. a catalog, generated straight from the product database and ready to be sent to the printer. Previously they were doing this all manually with PageMaker, which was very tedious and prone to mistakes.) It supports the CSS Paged Media spec, so you have full control over page layout: margins, widows and orphans, page breaks, bleeds, and so on. It also understands page numbers, and gives you full control over headers and footers. Other things it supports include press crop marks, color management, and PDF options like bookmarks and PDF link regions.

Headless browser rendering is fine if all you need is a two-page invoice PDF, but it falls down when you need control of anything other than basic stuff like the font size.

> it falls down when you need control of anything other than basic stuff like the font size

This is definitely not the case anymore, and BreezyPDFLite supports most of the features you mention, while supporting the same HTML/CSS/JS you might be displaying to end users across evergreen browsers.

Does BreezyPDFLite support CSS like this? Chrome didn't support any of this last I checked.

  h2 {flow: static(header);}
  @page :right {
      margin-bottom: 1.4cm;
      @top-left {content: flow(header);}
      @bottom-right {content: counter(page);}
  }

Edit: Also, tables of contents, with page numbers and links in the PDF:

  ul.toc a::after {content: leader('.') target-counter(attr(href), page);}

No browsers support those features from all the testing I've been doing over the past month or two. Weasyprint supports everything I tried except target-counters and dot leaders which I've only found support for with princexml. Weasyprint does author a proper outline within the PDF so my current workflow (no $ for prince) is to use Weasyprint to make the PDF with a TOC that has no page numbers, extract the outline from the PDF with a python tool to get the page numbers, update the original HTML with page numbers then run it through Weasyprint again. That'll be bundled in an automated build thing triggered by a git commit of the original markdown file straight to PDF so it's not something I have to do manually each time.

I'm not sure about those specific selectors, you'd need to check caniuse.com

Building TOC is just as easy as building the HTML and linking to the ID's appropriately.

Page numbers are supported in header/footer templates, or via manual computation when you render the HTML or with JS.

No browser supports CSS paged media features. So there's no proper control over repeated elements, paging etc