Websites Should Be Printable

I agree that websites should be printable. I'm a fan of RSS and eInk displays (Kindles, and when I can afford one, a PC monitor), and printable websites would make using them on paper-like displays easier.

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

I politely disagree. The original intent Tim Berners Lee had [1] was to create a navigable way of finding documents and information. Not printable. The entire issue we have today is that we have blurred both the navigable and the printable concepts. A website should just be a simple clean space for easily navigating and conveying intended information. To print, we have latex and other markup methods that are perfect for that.

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

Hilariously, when I hit CMD-P on this specific website, I end up with 4x pages: the first is 80% blank, the 2nd page is fairly nice, the 3rd page contains just the CSS code sample as a thin strip on the left-hand side, and the last page is again mostly blank space...

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/

Go talk to the browser vendors and have them roll in the CSS L3 PMM[1] specs, which have been in draft for . . . let's see here . . . oh, huh, two decades.

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 become a sorta-crappy sandbox for what we used to call client-server computing and a sort of 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.

[1] Paged Media Module

[2] Well, everywhere outside of high end print production, glossy prints, executive whitepapers. But even there, I […]

Debugging css issues related to print can be a bit of a PITA. Adding print options for dynamic content in a full stack page is not technically that hard. But getting it looking right can be a bit fussy. If you don't care about what things look like once printed, it's easy. But if you do care, it actually needs a bit of consideration.

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 w […]

If I'm totally honest, this feels like somethign that'd be quite low on my priority list. I'd muchrather focus on the on-screen UX and accessibility if I have limited time. I think making things printable makessense in certain contexts, and I think could actually replace a lot of the pDF generation sites do for things like tickets, invoices, etc.

Oh, wow, that's one naive print.css

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.