This is nice, I learned a couple of new tricks. The attr one is great.

For many years now, and alongside my "regular" CV, I've had a Markdown to PDF script that uses @page and @media in a small HTML template and essentially creates custom 1-pagers in US format. Instant recruiter turnaround.

In between this and the OP's table splitting trick, this was a good 15m spent on HN.

Awesome, thank you.

I don't think that h7 and h8 exist?! Are you sure this is necessary? And why no h1?

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/He...

Not sure how those got in there and git-blame is not helpful. Maybe just me typing out as many as I could imagine? :v

No h1 because there is only ever one of those and it's at the top of the first page.

Thanks :-)

While they're not valid, I believe the browser will still respect non standard headings. The browser will treat them like non semantic elements (similar to a div), but you can kind of make it legit with a couple different aria attributes. I would recommend staying within the standard heading sizes though.

This is useful, but note that with `table {break-inside: avoid;}`, if there are tables longer than the page, the browser will add a break before it, and that could be not desirable.

I have used, too:

    footer {
        page-break-inside: avoid;
    }

    summary {
        page-break-after: avoid;
    }

    body {
        min-width: 992px;
    }

Explanation:

- I usually don't want to break the page footer.

- Similar to headings, usually it is not desirable to produce a break after the summary element (for details element). If the details elements are never longer than the page, `details {break-inside: avoid;}`can be useful.

- Avoids rendering the mobile version of a page

Wow, great use of the attr function, thank you!

If the anchor tag already has the URL as text, then will the URL be printed twice?

Like if I've got

  <a href="https://www.google.com/">https://www.google.com/</a>

Will it print like this?

  https://www.google.com (https://www.google.com)

Based on the above, yes.

would recommend printing URLs in a very narrow font so they don't eat up the entire page

That's a pretty common Accessibility best practice for print CSS!

Shouldn't this be an option in the browser print dialog instead?

No

Great argument.

They asked a yes/no question. In the spirit of HN pedantic comments, I answered their question fully.

Sounds like all of these should be the default for print-like output devices.