alt Hacker NewsWebsites Should Be Printable
Comments
While I'm on board with having good html structure that prints well, and I'm on board with hiding navigation elements, etc., I'm not so on board with changing the default font size or fonts in the print version.
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 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
If a browser can show it on a screen, in fact screens of many sizes, it should be able to render to a printer. With perfect fidelity. It frustrates me to no end this isn't the case.
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 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.
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
Mixed on this. I rarely use a printer. Once or twice a year to print a sign or some government form required to be paper. Maybe you shouldn't encourage printing?
That said, I've gone out of my way to make my sites printable so ...shrug...
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 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.
I have a caveman thing I do that I'm somewhat ashamed to admit. I straight up print websites and feed that into my LLMs to chat against. Or when I'm trying to get product detail pages into the LLM. For articles, I frequently go to reading mode and select all and share to the LLM app.
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.
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.
One issue with making websites printable is that printing, by default, removes background colors and images. So, for the chess diagrams I have on my webpage, I use background colors to have the chessboard be a checkerboard instead of a white background (the chess pieces are a color webfont)—but since web printing removes backgrounds, the chessboards have white backgrounds unless the person printing the webpage chooses “print backgrounds”.
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)
I've periodically struggled with an HTML resume that can be converted to a PDF using chrome headless / puppeteer wkhtmltopdf, and looks good both on screen and PDF/printed.
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.
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.
As most sites will have horrible CSS for printing, as it's not a big priority usually, I can recommend getting the page as a markdown file through something like the Obsidian Web Clipper and using that instead.
Obsidian Web Clipper: https://obsidian.md/clipper
I personally think printing unless absolutely necessary is a waste of resources.
https://tuhat.net allows you to set a page size for your post and input hidden page breaks for when people download the epub version or print your posts, it doesn't affect the web version.
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.
My read is that a lot of content - specifically of the infinite-scroll variety - is very intentionally not designed to be printed.
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."
And RSSable. But they aren't. If most web content was in easily processable formats, many people could use that for various purposes, e. g. for search. This would diminish the market position of search gigants. But if web formats were hard to process, only big players would have resources.
Most will find it unrealistic, but JavaScript should be an absolute last resort that should be avoided entirely or almost entirely.
My benchmark is that a website renders cleanly in `dillo`, which is rare, and would also include the website being cleanly printable.
An even bigger printing issue that exists on some sites is the use of scrollable elements. I haven't done extensive testing, but I tested on one site that uses `height:100vh;` around the main content of the page, with sub-sections using their own scroll settings. Printing the page only captured roughly what was visible in the browser window, but did NOT capture any of the internal scrollable sections. I imagine this would be more of a problem for web apps, as opposed to blog/article type content. But I imagine many blogs fall into this trap too.
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 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.
I have been loosely involved with very specific ‘web2print’ practices, aka using web technologies (html, css but also web as space for collaboration). For example: octomode [0]
>Octomode is a collective editing space for PDF making, using Etherpad, Paged.js and Flask.
I also think that websites should be printable, and years ago I've made an effort to make my website printable. I've lost my motivation to maintain the website, but printint still works.
> Here's the functions this does for me, in order:
Is for anyone else, the text that follows, unreadable black on almost black background?
I had no idea that the css rule '@media print' was a thing. Very interesting. I could see this being very useful for certain website. E.g., Cooking recipe websites comes to mind.
I find tremendous beauty in the idea that HTML is just a syntactically structured document and in a perfect world you can render it to paper, voice, braille reader, screen, e-ink, etc. I'm equally attracted to the idea of asking an HTTP API for your desired content-type.
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.
Thanks everyone for the feedback! I've implemented a lot of it into the website already to fix the glaring issues. There were a few comments about how "this can't be a real web developer", and you'd be correct! Merely a CS student who is starting to develop my art.
yes, ideally 'print to pdf' (save later for print) feature should be enough, but for more 'save for later' 'bookmark' it, i prefer and very often use https://github.com/gildas-lormeau/SingleFile
I thought this issue was fixed already by the browsers themselves. Mozilla Firefox solves this issue with the "Reader View (F9)" and Brave has "Speedreader" view, which is essentially the same. It automatically strips secondary content and formats the text in an uniform way.
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.
We members of the Bradley Taunt 1Mb club not only have simple but effective web sites but I think they print pretty well too. Mine renders nicely as PDF, ePub and Dead Tree. It's important to be able to preserve them as offline media because increased protection of allegedly at-risk user groups makes them liable to disappear at short notice.
We use a SaaS ticket management tool (like Jira) for internal company use to track projects, requirements, software designs, etc. The tool is hopelessly unable to generate a sensible export or print to pdf for archiving pages to share with customers or auditors. I’ve had to resort to stitching screenshots together in MS Paint to create the offline evidence documents that I need.
Let's add a AI powered beautification to Ctrl/Cmd + P in the browsers.
When I want to save a page for myself I usually use the PrintFriendly (https://www.printfriendly.com/) plugin to save to PDF, minus the cruft of images and ads.
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.
I've found either the speed reader in Brave useful for removing distractions. Or the send to obsidian extension that extracts the article, converts it to markdown then you can print it from the Obsidian app or fiddle with the font size.
And a Pony!
Reminds me of this blogpost from 20(!) years ago: https://blog.codinghorror.com/and-a-pony/
I'm currently working on rebuilding my personal blog from Jekyll set up about 10 years ago in Astro. One of the things I've also been doing is setting up a resume page designed to print to PDF, which I find a lot easier to maintain and format than the LaTeX resume I've been using forever.
Printability is not important to me per se, but one property that comes with it: A natural linearization of the whole site. Sites that could be read like a book show that their authors had the whole in mind and as a top-down person that naturally appeals to me.
Printing a web page (or a PDF) is not unreasonable provided the content is two pages or more and it's something that invites itself to depth and close reading or some sort of value like ordinary print.
Your everyday blog is not worth the cost or effort. Nor is a Wikipedia entry.
Immediately tried printing this HN comment section, it worked decently well. The author's website doesn't print well.
Maybe only websites with content that should be printed... Like sudoku and puzzles and stuff. As for the rest of them... IDK if I don't intend on reading something on an airplane there's no reason for me to print it
Websites should be usable first. Open this one on a phone and see what happens
Everybody is focusing on responding to the title
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 wish there was a way to provide alternate html too
I have used CSS for print layouts before. My stance on this is: If you can reasonably expect someone will print your website or (more likely) parts of it, because of its nature, add a nice add free, no tracking cookie print layout. If not, don't.
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.
Can't the website just lay itself out for print differently?
printing webpages feels like trying to view the internet on a mobile browser in the old days.
Heavily depends on what your site is trying to accomplish. Marketing sites aren't supposed to be printable because we're very visual creatures. We see before we read, and so something like the iPhone product page shouldn't be printable, but something like arXiv where I'm trying to read something, not see it should.
I like to print content from websites and marking/writing on it. It is such a helpful feature to print only the core content. It is a prime example of an obvious need lying in plain sight, and that's ignored. Glad that someone has worked on it.