Websites Should Be Printable

I just made a simple site that didn't set any font sizes anywhere, and a friend of mine complained that the font was too small on mobile. Do I detect a lo-res screen and increase the font size?

I know a lot of sites do exactly that, but I feel it's wrong. The user controls their default font size on their platform. What if they'd already increased it, and now I'm just making it bigger?

What if they'd decreased their default print font size and then I shrink it again?

I think it's best to leave those to the user entirely.

I've been using the PrintFriendly [1] browser extension for years (to print otherwise unprintable websites), but it gotten worse, so while looking at alternatives I started with The Printliminator [2] (which uses the Haartija CSS framework [3]) and have currently ended up using CopyAsMarkdown [4] (with Pandoc) and WebToEpub [5]

[1] https://www.printfriendly.com/ [2] https://github.com/CSS-Tricks/The-Printliminator [3] https://github.com/vladocar/Hartija---CSS-Print-Framework [4] https://github.com/yorkxin/copy-as-markdown/ [5] https://github.com/dteviot/WebToEpub

[1] https://info.cern.ch/hypertext/WWW/TheProject.html

I posit the reason it sucks is because the Chrome team doesn't care (at least not enough) about the print feature. Firefox is a little better. But I haven't seen decent printing since the days of Internet Explorer.

Some of the most annoying culprits are website terms of service where printing to PDF produces page breaks in places that cut off lines of text.

I also attempted something like this, but only to format my resume[1], since many employers require it to be submitted as a PDF

[1]: https://www.trist.am/resume/

I've done a few custom things with an application that generates labels for a label printer using just css and javascript. This is not that hard. But it does involve dealing with a lot of weirdness related to native print dialogs, vs. browser specific print dialogs (and their print previews), feature interaction with native printer settings and their scaling options, browsers adding footers to the printed document, and just general weirdness related to layout issues, page sizes, margins, etc.

My general feeling dealing with this is that CSS for print just gets a lot less scrutiny than regular CSS by browser developers.

One of the hacks you can do is generate a dom tree just for print. Replace the root of your dom tree with that, trigger the print, and then put the old dom tree back (with your full stack application and all the rest). Seems very hacky to have to do it like that. But it kind of works and is simple enough to do. And the benefit is that it stops the rest of your application (which probably does not take print into account at all) out of the equation and will stop that from interfering with your print layout. Conceptually, makes you wonder why you can't just hand a separate document tree + CSS to the print api call. This is a lot simpler than having one unified dom tree and one flattened unified CSS file. Separation of concerns is a good thing.

The only way to work around this is to have two sets of chess pieces in the font, one with a white background for pieces on light squares, and one with a colored background for pieces on dark squares.

Printing web pages is rare enough I just assume someone doing that will also click on “print backgrounds”.

(The reason to not use images for the chessboard diagrams is because they use more bandwidth and can’t have usable “dark mode” colors)

Admittedly I'm not an HTML/css guru, but I know a bit... and it really feels like it shouldn't be this hard / require so many tricks to get it working even half ok.

The biggest issue is that the pages kind of fight against the DOM structure of the HTML. Like lets say I have big:

<div> <h2>Experience<h2>

  <div> <h3> Job A </h3> <p>Description</p>

  <div> <h3> Job B </h3> <p>Description</p>

  <div> <h3> Job C </h3> <p>Description</p>

  <div> <h3> Job D </h3> <p>Description</p>

There isn't really a good way to say...

* Keep "Experience" and "Job A" on the same page.

* Don't break after Job X / before Description.

* Don't try to keep the whole toplevel div on one page by breaking before, just break within it, sensibly.

Whatever tweaks/hints/hacks one applies to achieve that tend to be pretty brittle across browsers/page sizes/etc.

It's very tempting to just give up and go back to... something actually page-centric like word, pagemaker or whatever, instead of HTML and then having print as a second class citizen.

Missing things like resizing media to not occupy everything, blocking certain elements from getting broken up, and so on, wrap when needed, printing links (sic), etc

The latter is why I moved links into footnotes instead of inline linking - also to prevent breaking up the reading flow.

Also: adding page counters is virtually impossible.

Anyhow, I do think it's a good idea, but mostly for archival reasons: if you really want an archival copy, you'll need to print it.

I often have to print for example online shopping baskets so others can decide which offer they will take. Meaning how your shopping basket looks print absolutely will have an impact by annoying or pleasing the people who make the decisions. Needless to say, 99% of all shopping baskets look like trash when printed out.

If you have a blog, it would be reasonably that someone might want to read your article offline or store it for archival purposes. Having that look decent is not a bad thing. And it is not that hard.

But jeez, I remember doing consulting for an ecommerce site and adding print media queries to make the printouts look better. I am so impressed whenever I see a page print cleanly. I know how much care goes into doing it or thinking that users would do such a thing.

There are a number of Slack and Discord conversations I'd have liked to export off to PDF, for instance (where a solid 90% of my "prints" go). I'm reminded that one of Slack's boot messages used to be, "Consider the environment before printing this Slack."

There is also a zine booklet mode which works out page imposition to print out a zine (eg. double sided, folded in half)

Click the printer icon on any tuhat post.

This was something that sort of escaped my notice until I finally had to replace my 2011-era HP printer. I chose a SOHO HP printer, and basically, it can't properly print anything, not even 2-sided, unless I go through the Linux subsystem on the Chromebook. This is fine, because I seldom print stuff, but it's just emblematic that neither ChromeOS nor Android really wants anyone to print anything, ever at all.

When choosing to replace my printer with a modern one, my other option was to not replace it at all. I could easily upload documents and print them at the UPS Store, or Staples, or FedEx Kinko's, the public library, or a pharmacy photo department or something. There is not a shortage of outsourced print shops around here. Perhaps I spent way too much money on a SOHO model. But at least I can scream and rage at the printer drivers in the comfort of my own home!

>Octomode is a collective editing space for PDF making, using Etherpad, Paged.js and Flask.

[0] https://cc.vvvvvvaria.org/wiki/Octomode

I guarantee the instant - the millisecond - that CSS PMM goes into the browser, that is the second the PDF ecosystem goes poof[2].

Aside from all that, back to the core point, it's quite late in the day to restrict HTML to page-based UX. It's been at least a decade since the "browser" has officially become a sorta-crappy sandbox for what we used to call client-server computing and just-in-time software development. But the thing about software, writing software, is that it's diametrically opposed to language, natural language, like the kind you use in documents. That's why we call one a "formal" language versus what we call "natural" language. The interface of these two, trying to make them the same thing, is an ever-bountiful cornucopia of suffering.

You see this in complex markup constructs, like conditionals and transcludes[3], that cross blades with natural language, i.e., documents. This is a big part of why every WYSIWYG "just like paper" XML editor ever made sucks so horribly. It's not that the developers are all idiots - I know a lot of them, and they're some of the smartest/canniest developers I've ever known - it's that they're taking on a task that is conceptually unworkable. A document markup that supports conditionals, or transclusion, the file stops being a document and becomes a part of a system that makes documents. Oh look another cornucopia what could be inside . .

[1] Paged Media Module

[2] Well, everywhere outside of high end print production, glossy prints, executive whitepapers. But even there, I predict a huge falloff, due to the existential pain of developing custom PDF pipelines.

[3] AsciiDoc (include::[] with tag=/lines= partials; ifdef::[], ifndef::[], ifeval::[], endif::[]); DITA (@conref, @conkeyref, @conrefend, @keyref; blah blah blah blah); S1000D (CIR, applics, whatever your Program Officer says); DocBook (all sorts of stuff); ATA iSpec 2200 (SGML crap); reStructuredText/Sphinx (.. include::, .. literalinclude::; .. only::, .. ifconfig::); and new kid on the block Typst[a] (#include, #import; #if … else expressions).

[3a] Speaking of which, if you want to see what paper markup looks like, I seriously recommend a look at Typst. It's like LaTeX for humans.

Is for anyone else, the text that follows, unreadable black on almost black background?

My benchmark is that a website renders cleanly in `dillo`, which is rare, and would also include the website being cleanly printable.

Some people see a website as a medium for reading, like this person does, but to me a website is a medium for experiencing. I find websites where the elements interact with each other fun. I like fun websites. Of course, you could strip out the animations and just show a print-style document instead, but in the end, having a particular philosophy comes from freedom. A website doesn't have to be quiet and efficient. I'd actually rather websites be fun. There are plenty of media for reading—PDFs, for one.

But in practical terms it's often just a distraction. You should do it if it's worth doing. I can imagine some websites having almost zero audience for "I want this printed" while others probably have a considerable audience (though oftentimes they just point to a .pdf which offers better layout guarantees). Some websites should be printable.

Obsidian Web Clipper: https://obsidian.md/clipper

[1]: https://veravandeseyp.com/

You can print 10 pages from 10 different websites this way and they'll all look identical.

Don't know if Chrome has something similar, but I'd expect it should've.

It feels like over the past year or so it usually fails. One page on screen goes to 5-10 pages of mainly blank space, certainly not just the details.

I've taken to screen-grabbing and printing that.

It's ridiculous.

[0] https://www.myunscroll.com

This way, I've built an archchive of useful pdf's that are now (since they are clean text) fully indexed and searchable on my devices.

That said, I've gone out of my way to make my sites printable so ...shrug...

[1] https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/V...

[2] https://developer.mozilla.org/en-US/docs/Web/CSS/Guides/Frag...

Your everyday blog is not worth the cost or effort. Nor is a Wikipedia entry.

Reminds me of this blogpost from 20(!) years ago: https://blog.codinghorror.com/and-a-pony/

hypertext should be printable.

hypermedia should be highly interactive.

but I thought this bit was far more interesting:

> I read a lot of printed papers these days. While I enjoy reading on a laptop as much as the next guy, marking up a printed document engages me better. Also, there's something about sitting with a whiteboard and a printed document that makes me rightly feel like I'm doing something important.

would be interesting to consider a totally new workflow of automatically printing off any "read later" stuff, including interesting HN posts.. and then actually sit down and read the paper, no distractions.

I used to file tickets for developers to check if their doc building tool supported output to PDF/HTML. A few humored me and did it, but mostly I'm ignored. So I stopped.

Haven't tried doing it myself with the help of an LLM!

And you watch how fast “responsive and accessible” from the RFP turns into, “Well let’s just support desktop and one phone screen size and we won’t bother to even spend 1 hour testing tablet or 4K or horizontal on any device or printed versions.” Clients just want low prices. Printed is always the first to get removed by clients.