Websites Should Be Printable
brennenputh.me
brennenputh.me
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.
The one counter argument to this that I would accept is that users don't know about font settings. But the proper solution if for browsers to make it easier those settings rather than every single website having to add font controls.
For some harder C code (implementing `malloc` for example) my preferred debugging method was printing out the code and debugging it with a pen between classes.
I eventually realized being inside an editor gave me too much attraction to thrash with "just one more quick iteration & debug run..." and could actually end up more time consuming than being forced to reconcile my mental model with what I had already written by me double checking my assumptions.
Interestingly, some of my peers started picking up the habit for their own projects and we ended up having small "debugging" sessions by trading print-outs .
Though I also remember sketching programs on paper as a teenager for my TI-83, since it was annoying to type everything out and then have to make a bunch of edits.
Initially, it was much harder to read, both because of the habit I've developed and because, I think, the author also didn't use a "fancy" editor to write their code, so it wasn't formatted properly, didn't observe naming conventions. Well, your typical college professor writing. My first reaction was to type the code into the editor so I can explore it easier. This, of course, also provided syntax highlighting.
Of course, it took extra time. So, eventually, for shorter snippets, I'd just suffer, skipping all the typing part. I later discovered it to be somewhat helpful exercise when using Git diff or other Git commands that displayed code snippets in terminal w/o highlighting. But then the industry caught up to it, and now I don't have to read unadulterated Git output like that.
So, my conclusion so far: highlighting helps to discern the structure, to process larger blocks of code and to navigate it more efficiently. You can get better at reading code that's not highlighted, but it's never going to be as good as reading the highlighted code. It just seems like the struggle to even get to the level where it's palatable not worth it as there are very few situations where it would come in handy.
I can read my code just fine.
The only exception is that the layout of your website requires multiple columns so increasing either font size or page zoom doesn’t work well. For example gcc.gnu.org is challenging for a mobile browser if one prefers larger font sizes. You are fine if you aren’t doing that.
The person making the site however wanted someone to change their default font size
We have to also consider that the person in question is most likely not having a bad experience on every app and website, and that this guy just had a tiny font size on his site
Even this famously tiny fonted site is readable on mobile
https://support.mozilla.org/en-US/kb/font-size-and-zoom-incr...
So no, you don’t have to set the default.
Did you use
<meta name="viewport" content="width=device-width, initial-scale=1.0">
Drawing a line can be hard, but clearly the basic font should be contrast-y enough so that most people can read it, no? The user can control the defaults of many things on their devices, but we shouldn't require them to change settings to have a good experience. We already customize websites a lot.
I think it depends on the goals of the print version, but people spend a lot of time picking fonts and styles so things look good on a screen. I take this as saying you should supply the same type of attention to your print style sheet.
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
After all TeX is all about high quality printing on paper.
Even now this is not that uncommon; I have worked with an entrepreneur masking significant dyslexia in just the last five years. Printability was just something he needed so he could properly scrutinise.
Print is still an accessibility thing, I think.
So I don’t think there’s much merit arguing about what doesn’t exist any longer.
This distinction is important especially because people are notoriously confusing the two and expect web apps to be like websites and conversely implement websites with tech that is supposed to be used to build web applications bloating internet pipes with JS where HTML and CSS would be sufficient.
Beyond that, the distinction is purely arbitrary. Same tech stacks, same delivery methods, and the same client-side display tools.
This kind of fairly idealistic thinking is so far from the ordinary web development norm that you have to go past "supporting that version of IE with 0.7% market share" to get to it.
Most "I need a printout of this" information is timely and dynamic and needs fixing in a physical form.
A print stylesheet seems like something you could get an LLM to write.
I mean, everyone has their own workflow preferences so I wouldn’t criticise you for wanting to use AI in your own personal set up. But it feels like your two statements there should be moral opposites of each other.
I politely disagree, the problem is we have made websites a javascript hellscape with all that original intent broken by design.
Years ago I was never using the "print" command in browsers. I used the "save" command. But now the "save" command is useless for most sites, because the saved scripts frequently do not work offline or they do not work even online, but from local files. So the only alternative is "print", which is extraordinarily buggy in both Firefox and Chrome, but their developers do not give a ****, so there are many years or perhaps decades since printing in Firefox or Chrome renders completely incorrectly almost all Web pages.
As a workaround for the stupid rendering in Firefox and Chrome, I frequently print twice a Web page, once in Portrait and once in Landscape, because the corrupted parts of the printed page will typically occur in different locations. Moreover, I may have to fiddle with other printing parameters, e.g. whether to print backgrounds or not, or with different margins and paper sizes, because it is unpredictable which settings will work best with a given site.
And I politely disagree right back. My particular problem with this has to do with purchasing. When I make a purchase at work, I need something I can attach to a purchase request as a quote. Note that this is often not a formal quote, but rather evidence of what whatever I want to buy will cost.
A simple way to do this is to print a shopping cart to PDF and attach that to the PR. Some web sites do this just fine and others do it horribly. They should do better.
Maybe you could capture the full height of the website as a screenshot? There are extensions that do this, and there is some degree of native support for the feature nowadays.
Thankfully, most of the web sites for which I want to do this — banks and other financial institutions, but others also — have easy ways to create printable receipts because they know that people want to do things like this.
And you can disagree, but when I come across some e-commerce site where printing what I want or need to PDF doesn't work because the site just makes a horrible unreadable mess out of it, I think, well here's a set of "web developers" who are just not good at what they do.
(And yes, I fall back to screen shots when I must.)
But to expect every author also upload a PDF? I mean, TeX is great for what it is, but there's a reason _the web_ adapted print stylesheets.
Even if (La)TeX (or Typst, or Postscript or anything else) were easy to learn, you're left with maintaining 2 copies or a compilation system which is also a challenge.
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.
For some reason, the print command works much better in the Vivaldi browser. It frequently renders correctly pages that are garbled by Firefox and Chrome. Moreover, its print command also works many times faster. Thus even if I usually browse with Firefox, when I want to save a page I frequently reopen it in Vivaldi, in order to print it from there. Unfortunately, not even Vivaldi does it always perfectly.
It is very annoying that the print command does not work in browsers, because nowadays that is the only reliable way to save a Web page. Saving a page with the "Save" command rarely works, especially when attempting to read the saved page offline, because too many pages rely on scripts to generate the displayed content, and those frequently do not work offline or even just inside local files.
I do a lot of teaching, and for many reasons share PDFs of articles in addition to the web pages and URLs. I know how to work around these things, but lots of reasons to print and article and what are normal folks supposed to do? Hell, sometimes I don't even notice until the cut is buried in the middle of the long document...
If you click through them, you will often notice that they are squeezed into the most inconvenient popups, modal dialogs, and other interstitial windows that are abused for this purpose. They are also insufferably long-winded.
I often try to capture the text of these so-called "legal agreements". I try to shove them into a "Print to PDF" but that fails. So I try to copy-paste them into Google Keep, but that also fails, because Keep has a limit. So then I try to cram them into Google Docs. And it often takes about 15 sweeps with copy/paste and scroll scroll scroll, in order to meaningfully transfer all the content into Docs.
It may come in handy later; for example they will often include some contact information for their privacy or legal department, and sometimes there are opt-out instructions nestled near the end of the Terms of Service. They may also document the steps of a grievance process. If you, as a customer, do not follow their steps for filing a grievance and pursue it according to their policy, they have no obligation to help you. So, if you are a serious user of any service, or it means serious money to you, I encourage you to paste or print those legal Terms by any means necessary.
Of course, they will invariably change the Terms on a whim and with the slightest notice to you, and the game begins all over again. Strange game. Perhaps the smartest move is not to play?
I also attempted something like this, but only to format my resume[1], since many employers require it to be submitted as a PDF
I am with those disagreeing with the original proposal that websites should be printable. There are so many things that go into showing you a web page and so many things that go into preparing that page for print. Even something basic like this isn't consistent.
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.
For one, it often entirely heads off the requirement for "can we have it so the user can download a PDF of this?" (because users generally know how to print things!)
And for another, it broadens your options for implementing those PDFs if that requirement doesn't go away. You may not have to restrict your markup to that which some PDF generator library can work with, because printing any page in a headless browser is easier.
You often don't have to do much in a CSS stylesheet to get a modern site to render well, because we've moved away from so many layout hacks in general.
So you're primarily left with hiding content that shouldn't be printed (like navigation or menu buttons), defining page breaks, and some other quality of life changes for printing.
This comment suggests the answer is yes.
Happy paralegals are a finite resource.
But yeah. Someone, somewhere, is printing your web pages for their own reasons, and you may never know whether poor printability cost you.
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)
background: #eee;
print-color-adjust: exact;
-webkit-print-color-adjust: exact;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.
https://developer.mozilla.org/en-US/docs/Web/CSS/Guides/Page...
I also feel like there's no point in making a CV in HTML for my website, if I'm going to re-make it in PDF for all the old school application processes out there.
My solution was simply to keep the online CV as simple as possible, so it still looked good in PDF. But it's far from perfect.
I know what you're thinking: "Ok genxer", but hear me out. :)
The two stylesheets produce HTML and Typst code. And so I get the exact render that I want.
(It actually goes further, making a CV and a resume from the same xml source, rearranging sections and sorting appropriately.)
Xml and xsl are quite dated, but this really does seem to be a good use case for data/presentation separation.
But really my dream is for print css (or something) to finally be implemented.
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.
read books too.
if anyone thinks msdn, github, reddit, stackoverflow, and soon if not now (hosted) llm's don't export and mine their users queries for architectural goodies...
developers ALL have targets on their backs, it's just the way the world has evolved.
You still gotta keep it secure. ;)
and you can, without attacking the GP statement about their PERSONAL preference, or clumsily trying to tar them with some sort of pejorative NASCAR paintbrush.
* (Bitcoin, I'll agree, is an even more massively irrational and wasteful human endevour, but that doesn't mean all printing is awesome:)
* This is not to say that some webpages shouldn't be printable, I agree that they should - for a lot of the webpages focused on displaying information rather than interaction, making them print consumable is good. Just that parent's comment doesn't make them the buzz-kill party-pooper, necessarily :)
I mostly do this with order confirmation pages when I order off of random e-commerce sites, and with my bank when I use online bill pay. (And then if someone claims I didn't pay them, I go back through the pdfs and see if I made a mistake.)
More importantly, I "print to pdf" recipes that I want to save. Every year I print out the same turkey recipe, from a pdf, and then I don't need to worry about getting my phone or computer gross by interacting with it while I prep the turkey.
Or do you mean even exporting is a waste of resources?
Cuts well on procrastination.
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.
But website printing in general, I see less of a need.
You copy with a pen or pencil, like the monks did.
Yes to cut and paste with scissor and glues.
I do love an e-ink display, but I just like holding a sheet of paper, and not having to jump through menus to read something especially if I'm actively referring to it and revisiting it. Plus I can use my coloured fineliner on it, whereas the PDF viewer on my iPad crashes sometimes crashes if you look at it funny.
We had just completed yet another other redesign and our (React) pages printed completely mangled and users hated it. We regularly got feedback about it.
And yet it was so low priority that me (UX designer) and a developer had to team up and get off the record permission to spend a few days fixing it in CSS alone while our managers covered for us.
When people for whom $29,000 is an enormous expense are purchasing a car, you can bet they are printing stuff and very, very carefully considering their purchase. Primary demographic was not young, tech native people.
For a couple of applications I have built recently, an offline view of the data in print form has been part of the design requirement. It's still reasonably common in situations where people will meet in real life and a physical clipboard will be needed with a register or some physical signatures are needed, or in situations where paper goes home with people from meetings for them to read and sign. So, lots of school/community/disclaimer tasks where you can't presume people have devices (or a device wouldn't be usable/practical/useful, especially in outdoor contexts).
These days PDFs are also useful for marking up in some devices.
For my own work, making an app printable is a basic thing I always do — it's part of the normal process.
But that often means little more than disabling headers/footers/sidebars, rendering simple text where a logo was, putting in page break guidance at sensible points, perhaps overriding a few text colours, maybe a couple of media queries for items that need to only appear/not appear in print. Basic stuff. From there, most "print this" views are little more than a slightly simpler template.
The cool thing about is that printability often comes up late in the requirements, and it's a thing people try before they ask you about it — they try to print from the demo. So it's an easy positive surprise if the print view does more or less what the user would hope for, right from the beginning.
Making it so all of an interface is at least basically printable is actually easy if you plan for it, and it's a good way of keeping focussed on broader usability.
Generally speaking, if you are in any group situation where you meet in person and want to share something, paper is still king. Easiest to share and no distracting electronic devices.
Also for learning I often prefer physical books and printed out worksheets. It helps engage the spatial memory plus you can write on them with an actual pen which also helps recall compared to typing.
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.
It's not the end of the world.
But as it goes, not everyone has the motor control to _only_ scroll a phone view vertically; unexpected horizontal scroll can be frustrating, especially when one very wide element leaves the screen otherwise confusingly blank elsewhere on the page.
(I've actually witnessed this frustration from an older user in real life)
The way to handle elements wide enough to induce horizontal scrolling is to put them in a <div> (or make CSS for the tag in question) and make CSS with overflow-x: scroll; for just that element. An example from one of my webpages:
pre {max-width: 90vw; overflow-x: scroll;}For you :-) Now imagine you have to use a mobile device but have limited control over your hands, and it's difficult for you to do a vertical scrolling gesture without some horizontal drift.
I've seen this in real life. Why not make things easier for that person when you can? Accessibility is for everyone. (General accessibility rule I like — if it's a persistent minor annoyance for me, it's possibly a dealbreaker for someone with an accessibility requirement I've not thought of)
Your suggestion for constraining horizontal scroll to unavoidably overflowing elements is good, though — I do that too, and I've ended up figuring out how to add affordances so it's clear that scroll is possible (shadows that appear and disappear)
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.
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.
From this I think it becomes obvious that the best strategy is to make the site as a whole at least not a total train wreck when printed, and then to focus effort a little more on the specific screens.
People who print are quite tolerant of small issues, I find. They are used to much worse.
Obsidian Web Clipper: https://obsidian.md/clipper
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.
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.