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]
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.
I politely disagree. What does Tim Berners Lee’s opinion of anything have to do with anything? What use is Latex when I want a readable hardcopy of a web page?
Not a facetious question, but you don't build websites for a living, I think?
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.
I think that's an orthogonal issue. A webpage can be crazy with loads of JS stuff, but still print nicely or behave well defined when it comes to semantics, screen readers etc.
The original design of the WWW has morphed a dozen times between what he built and what we have today. And while I don’t love every innovation, there are plenty of things we take for granted today that wasn’t possibly with HTML1, such as banking apps.
So I don’t think there’s much merit arguing about what doesn’t exist any longer.
Banking apps are not “websites” by coincidence they happen to be apps using same technology to show the interface but there is huge difference between website and web app.
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.
Fun fact: In the early days, website projects were mostly allocated at the top level of an organisation. As top-level officers used to consume the Web in printouts, the print view was also the default customer view and thus of utter importance.
Also in my experience, the higher you go in an organisation, the greater the chance of finding an older person of great ability with tired eyes and well-masked dyslexia who just wants to print your thing and go through it with a highlighter and a sharpie, and whose PA just used to always do that for them without anyone finding out.
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.
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
Which browser do you use? Unsurprisingly supporting media print queries hasn't been top priority for some browsers. It makes total sense, but when you suddenly need it for something it does suck.
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>
</div>
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.
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.
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.
This is precisely why I do make things basically printable right from the start.
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.
And with light/dark mode support and CSS variables the colours in a print mode should be easy to define and support.
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.
Yeah. And out in the real world people are pretty tolerant of minor issues with printing (imperfect page breaks) because it's a miracle when any website prints at all!
I was recently surprised to notice a PDF download link on a blog post from Anthropic. My first thought was "would anybody want to read a blog post in PDF rather than HTML format?"
I think on corporate blog posts, they have regulatory impact, so that is perhaps additionally about legal teams — printouts of web pages end up in legal filings and discussed in meetings etc.?
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.
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.
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.
Printing also covers things like exporting to PDF, or rendering in an eBook format (EPUB, Kindle, etc.) for reading the content offline while travelling, etc.
When there is a website that I want to save indefinitely, I will print it to pdf. It means I can go back in a few years after the site is offline or has rearranged its urls (thus breaking bookmarks.)
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.
Considering trends in CVEs, printing is only growing importance. Printing has the unique advantage of giving you a record of data that's durable, unhackable, and possible to read without computers. If you print something, you can be confident that it's still going to be the same when you read it later.
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.
It is. But sometimes it is absolutely necessary for something to be printable, and PDFs are useful. Sensible OSes can generate PDFs from the print dialogue.
Must be horrifying for you to walk into a barnes and noble. Don’t go read up on how bitcoin works or hell nascar. Seems pretty unnecessary that we drive cars around in a circle for countless hours. I will take books and people making physical copies of whatever they want over many other things you would probably pile on your list of wasting resources.
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.
I agree that unnecessary printing is wasteful. But i would see this just as anecdotal: Having information structured consistently and a easily accessible format.
That makes a difference in the long run
You might be discounting the electricity and battery wear on devices down to zero, and inflating the cost of prints in your mind. Paper is EXTREMELY cheap and efficient.
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)
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)
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.
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.
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."
I don't really print. I do make quite a lot of archive PDFs of articles by simply printing to PDF. Sometimes a design both breaks reader mode (which often makes a better PDF) and frustrates printing from the ordinary view.
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.
Same. It rankles when I have to - usually because of some sort of antiquated approach to bureaucracy, like contracts or CDAs that demand a wet signature (despite then accepting an emailed poor quality scan of said wet signature).
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.
I do it for reading sometimes mostly papers, I just find it a bit easier to read through something without distraction and easier on the eyes. That and it sits on my desk until I actually read it.
With paper I can put two or three pages side by side. Imagine needing 2 or 3 synchronized e-readers like that. And I can immediately draw on them, not worrying about what mode I'm in, what brush is selected blablabla. I can flip back and forth with my fingers etc.
Downside is no search, no zoom no copy paste.
I've enjoyed ink displays, but my kindle has been dead for some time and it was always kind of a pain to load stuff on too, most papers would require some kind of zoom as well although I'm sure they're better these days.
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.
Just last night I noticed that one tiny thing LM Studio has over the otherwise absolutely glorious Unsloth Desktop is that transcripts print really nicely out of the app.
I used to work for a vehicle listing site, and over and over again when we talked to real users they would tell us how they would make spreadsheets and print out our vehicle pages (and from other sites too) so they could compare everything together on their kitchen table.
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.
Property search websites too. Boggles my mind that Rightmove can make it possible for you to add notes on a property page but still has a shit print view.
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.
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.
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.
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
> 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 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.
The screenshot does not scale to fit, so you get a horizontal scroll.
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)
Having horizontal scroll is annoying, yes, but I don’t think it makes a website unusable on a mobile device.
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:
> but I don’t think it makes a website unusable on a mobile device
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)
I'm building a side project that turns a batch of articles I bookmark online (e.g. here on HN) into a personal printed magazine that I can then read offline [0]. I definitely underestimated the amount of post-processing I have to do because many websites are not printable. Thankfully LLMs are helping with that.
I don't agree, because I just like websites that are full of moving animations... For websites that provide information, I agree, but honestly I think you have to give what matches the target audience of the website. I've always wanted to have a moving book like the magic books in Harry Potter. So I prefer homepages with as much motion as possible.
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.
Today, my only two devices consist of an Android 17 Pixel, and a Chromebook. The printer drivers in each of these OS are shockingly rudimentary. Like, there is no affordance to connect to the printer and configure its settings, or monitor its status, or run tests or anything. The only printout options are so basic: I can perhaps choose 2-sided, and perhaps what size paper, but there are, max, about 5 parameters on the Print dialog.
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!
Chromebook printing is just literal CUPS with an even worse interface. You can use manual configuration with a custom CUPS PPD, it’s just a pain. Also the driver definitions are restricted and can’t use executables, so PPDs that require an external filter don’t work.
fun fact: you can use mm/cm or freedom units in CSS [1]. YMMV outside of printing though, at least on low-DPI devices the rendering results might not make too much sense. If you're really adventurous, CSS offers even more dedicated printing functions such as pagination [2].
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
After all TeX is all about high quality printing on paper.
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.
I politely disagree, the problem is we have made websites a javascript hellscape with all that original intent broken by design.
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.
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.
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/
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>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.
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.
https://developer.mozilla.org/en-US/docs/Web/CSS/Guides/Page...
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.
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 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.
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.
Or do you mean even exporting is a waste of resources?
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.
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)
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.
>Octomode is a collective editing space for PDF making, using Etherpad, Paged.js and Flask.
[0] https://cc.vvvvvvaria.org/wiki/Octomode
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."
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.
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.
But website printing in general, I see less of a need.
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.
Is for anyone else, the text that follows, unreadable black on almost black background?
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.
Your everyday blog is not worth the cost or effort. Nor is a Wikipedia entry.
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 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.
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:
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)
[0] https://www.myunscroll.com
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.
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!
[1] https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/V...
[2] https://developer.mozilla.org/en-US/docs/Web/CSS/Guides/Frag...