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.
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.
While everyone probably should learn something about their devices, the defaults you provide to users should be good ones.
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 had a professor who asked us to print source code for our projects for him to read. Looks like he's still at it. I'm sure he's being driven insane in these AI times.
Source code has a structure, and some parts are more important to the reader than others. Good syntax highlighting makes the important parts easier to see; bad highlighting gives all parts the same emphasis. Notionally you could use font weight to convey this in a black and white medium, but color makes this easier.
we only had a black and white printer, I don't think they would spring for color. Also, iirc he had a script he had us run to print it, so it' not like we were printing straight from the editor.
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 .
This is interesting. For a while I used to print out code and debug too - more due to resource constraints: didn't own a computer, and my high school's computers were available only for limited hours per day. I used to code my first iteration also on paper - so that in the limited computer use time, I could type in the code quickly and actually see it run. Wild times but I think it made me good at programming. My friend (who did have a computer at home, but lived far away) and I co-wrote a program called "graph generator" that could plot math functions, with me doing my share on paper and giving to him to type in :) This was in the Turbo C++ IDE and since GUI based programs were unusual (at least as a project in highschool - India, 1999) it temporarily made us popular. Well, wow, that was fun to reminisce!
You were right and your friend was wrong for not knowing how to increase font sizes on mobile. It’s actually an opportunity to teach them how to change page zoom levels in a browser. (I actually have the opposite problem: many sites make font sizes way too large and I often need to decrease zoom level.)
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.
Looks like in Chrome on mobile you can set it per site, but you need to dig into accessibility for that. I don't see a way to do that in FF, so you would have to set the default which would effect all sites.
> 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?
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
Most websites regardless of whether they change the browser default font size or not, do not have my preferred font size. It is my responsibility to change my own browser settings to make me have a good experience. Browser makers have made this so easy, it even remembers the setting across visits now.
> 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?
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...
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]
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.
It's ridiculous this is a problem, and has been for many ages.
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...
Yes, this is also what annoys me most at both Firefox and Chrome, their print commands produces almost always complete garbage, despite the fact that the same pages are rendered perfectly on screen.
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.
Terms of Service and other legalese are notorious for being deliberately difficult to print, copy/paste, or manipulate in any way.
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 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?
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.
The biggest problem is that we went to mobile-first design along with a horrible split between backend and frontend functionality. If you hit view source on a lot of sites these days a page will be just a stub for calling javascript that actually puts the html on the page. It's not so much a function of hiding what the site does as it is web developers are afraid to write html and instead punt that into their javascript framework-of-frameworks.
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.
While what you say is correct, the point is that the excessive use of JS is what makes nowadays the print command the only way to save most Web pages.
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.
>I politely disagree. The original intent Tim Berners Lee had [1] was to create a navigable way of finding documents and information. Not printable.
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.
This might be more of an edge case than people who complain about websites that require JS, which is itself a number that rounds to basically zero.
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.
Maybe it's a weird, unusual edge case but maybe not. Lots of people need to keep records of various things for various reasons. In my personal life, I also "print" lots of stuff from various web sites to PDF for record-keeping purposes. This is absolutely routine for me, I do it all the time.
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.)
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 used to. Apologies if it came on too strong, but it wasn't idealistic thinking. For print, I find that I can easily use AI to turn a web page into a nice clean LaTeX and offer that as a PDF for those that want to print or read offline.
It’s weird that you’re opposed to a few lines of CSS but happy to boil the ocean to implement the same thing via non-deterministic AI.
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.
The Web is meant to have links and interactive content and be navigated, sure.
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.
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
One of the lovely things about html/css as print medium, is that interpretation of page break seems to vary between browsers, and while you can use CSS to prevent a particular page break, you can't use CSS to force one inside an element like an img tag
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'm looking on Chrome for Windows and it looks just like the web view.
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.
Unfortunately I just tried Chrome for Mac, and it too insists on inserting a spurious page-break to keep the giant screenshot on the 2nd page. I couldn't find a CSS incantation to prevent this.
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.
In some countries, printable tickets and other things once delivered as elaborate PDFs, are increasingly replaced by a QR code that can be printed from a barebones webpage, or even delivered outside of the web like to one's WhatsApp.
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.
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)
The advantage of a COLR font over SVGs is that they are functionally identical for this use case (indeed, the font in question was converted from SVG vector files) and a good deal more compact to boot.
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 was dealing with something similar and ended up writing my resume in markdown and converting the markdown to html, pdf, and png (with tools like pandoc and tectoni) in CI with a custom GitHub action I wrote: https://github.com/alDuncanson/md-press
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 remember leveraging xml and xslt for doing the exact thing for my resume! This was quite some time ago, when xml was king. So, as a way to both unify my generation for my resume but more importantly learn more about xml, xslt, i created what sounds like a similar pipeline to yours. It felt really cool, and i learned about xslt - which to this day i'm impressed by. But, over the years as xml, xslt seem to have waned, plus i never got to use such skills at any of my jobs, and finally employers just wanted a Word doc, not a PDF...then i just stopped using my setup. Nowadays i simply keep a local copy of an .ODT file, and export to word or PDF, or whatever format an employer or recruiter asks for...and like 99.999% of the time its a Word doc. But, back then, it certainly as fun learning that stuff!
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.
You can even have footnotes with links to other pages which automatically include the target page number in the text. Print CSS is actually pretty powerful. Just browser support is bad. I use “Prince” to convert html to pdf. With good CSS you can have a really good quality output. I used it to export a pdf for a whole book that way.
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.
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.
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.
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.
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.
In the early 90s, I would print out usenet posts so I could read them on the commuter train. Seemed a good idea at the time and I probably read them with more attention than my current online practices.
* I don't feel that's a charitable interpretation of the OP's comment. I have seen people print emails just to read them, including a page of CCs they discard, or 37 version of the draft slide decks, etc. And that's on their own printer - the office printer pre-COVID was just always printing random pointless stuff (as witnessed by the volume of it that was never even picked up!:). I don't have particular urge to print randomly, so I probably fit into the "unless absolutely necessary" group, but goodness there's a lot, and I mean a LOT of paper waste that doesn't provide entertainment value of nascar or B&N.
* (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 :)
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.
Printable does not mean it will be printed, if a page is printable one can assume the creator hasn't fucked with the scroll wheel for example, or forced you to sit through unnecessary animations.
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.
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.
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.
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).
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.
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.
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.
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)
Inserting the page breaks is for the authors, its a button in the editor when creating a post. The download epub / create printable pdf are on the posts for readers.
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."
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.
Yeah Paged is my go-to for CSS PMM at the moment. When PMM does hit browsers - if it ever does - it'll probably be some sort of transpile of Paged. Plus the stuff you can't really do just from JS/TS.
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 love the irony of an article about being able to print properly doesn't even appear correctly in the browser. Perhaps we should start with the basics...
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.
Any kind of statement, confirmation, or receipt should be printable. Some places still require printed documentation of expenses for reimbursement (even if it's only to turn around and scan it; you can argue it's silly but that doesn't mean it doesn't happen). A paper print is also an easy, cheap, immutable and durable one-off backup for anything you're looking at on your screen.
Yes. Also any press release, privacy policy, terms, ideally your contact page and user account screens. Stuff that might come up in a dispute or might be necessary in PDF form in a handover document. And any documentation for a physical, offline device or appliance.
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.
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.
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.
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.
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
The most common avoidable annoyance is the forced huge margins, like it's assumed you always fullscreen the webpage. However, making things printable would fix that and all sorts of usability problems too.
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)
Author here, I don't personally use my phone to access websites often, so I forget to check on things like this. My bad! I'll take a look into it when I get a chance.
> 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.
Too many people are thinking that "printing" here necessarily involves paper. I almost never print on paper but I "print" a lot of stuff to PDF. A lot of that is just record-keeping but some is for other reasons.
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 hate paper, but it's probably still worth it for being able to easily convert to a PDF. It's not that hard to do if your website isn't a hacked together mess to begin with.
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].
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.
Absolutely, this is accessibility 101.
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.
While everyone probably should learn something about their devices, the defaults you provide to users should be good ones.
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 had a professor who asked us to print source code for our projects for him to read. Looks like he's still at it. I'm sure he's being driven insane in these AI times.
Wild, did he ask you to use a colored printer for syntax highlighting?
I program almost daily with only bold, italics and grey (for comments) in my vim rules for highlighting.
I can read my code just fine.
If your beard is long and gray enough you can do syntax highlighting on the fly
Why would you need color to read and understand code?
Source code has a structure, and some parts are more important to the reader than others. Good syntax highlighting makes the important parts easier to see; bad highlighting gives all parts the same emphasis. Notionally you could use font weight to convey this in a black and white medium, but color makes this easier.
we only had a black and white printer, I don't think they would spring for color. Also, iirc he had a script he had us run to print it, so it' not like we were printing straight from the editor.
RIP vim `:hardcopy` :( .
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 .
This is interesting. For a while I used to print out code and debug too - more due to resource constraints: didn't own a computer, and my high school's computers were available only for limited hours per day. I used to code my first iteration also on paper - so that in the limited computer use time, I could type in the code quickly and actually see it run. Wild times but I think it made me good at programming. My friend (who did have a computer at home, but lived far away) and I co-wrote a program called "graph generator" that could plot math functions, with me doing my share on paper and giving to him to type in :) This was in the Turbo C++ IDE and since GUI based programs were unusual (at least as a project in highschool - India, 1999) it temporarily made us popular. Well, wow, that was fun to reminisce!
You were right and your friend was wrong for not knowing how to increase font sizes on mobile. It’s actually an opportunity to teach them how to change page zoom levels in a browser. (I actually have the opposite problem: many sites make font sizes way too large and I often need to decrease zoom level.)
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.
Yeah lemme just fuck up my entire experience on the rest of the web and my phone in general to read my friend’s blog
Browsers remember your zoom settings on a per-site basis. Try using it before claiming it will fuck up the entire experience.
Looks like in Chrome on mobile you can set it per site, but you need to dig into accessibility for that. I don't see a way to do that in FF, so you would have to set the default which would effect all sites.
> 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?
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
Most websites regardless of whether they change the browser default font size or not, do not have my preferred font size. It is my responsibility to change my own browser settings to make me have a good experience. Browser makers have made this so easy, it even remembers the setting across visits now.
> 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?
Did you use
That would probably be enough to look good on mobile too.Yes, I did. :)
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...
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.
It's ridiculous this is a problem, and has been for many ages.
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...
Yes, this is also what annoys me most at both Firefox and Chrome, their print commands produces almost always complete garbage, despite the fact that the same pages are rendered perfectly on screen.
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.
Terms of Service and other legalese are notorious for being deliberately difficult to print, copy/paste, or manipulate in any way.
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 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
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?
What a good point! The web would be much nicer looking if browsers accepted pages written in LaTeX as well as pages written in HTML.
After all TeX is all about high quality printing on paper.
Browsers already accept PDF. TeX files aren't portable.
Not portable in what way?
In the unless-you-bring-the-development-machine-along-with-it kind of way.
And as if browsers don't have enough bugs already -- now we include TeX?
Don has had the longest-running bug bounty of them all!
Exactly. That's why they should handle device independent output.
MathML?
A TeX distribution on my computer (mactex) is like 4 gigabytes. Definitely not "bundle-with-a-web-browser" worthy.
Well, I want to retire and not have to work for another 30+ years, but I guess we do not always get what we want :(
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.
There is a big difference, one is spelt “website” and the other “web app”.
Beyond that, the distinction is purely arbitrary. Same tech stacks, same delivery methods, and the same client-side display tools.
The biggest problem is that we went to mobile-first design along with a horrible split between backend and frontend functionality. If you hit view source on a lot of sites these days a page will be just a stub for calling javascript that actually puts the html on the page. It's not so much a function of hiding what the site does as it is web developers are afraid to write html and instead punt that into their javascript framework-of-frameworks.
> The entire issue we have today is that we have blurred both the navigable and the printable concepts.
I politely disagree, the problem is we have made websites a javascript hellscape with all that original intent broken by design.
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.
While what you say is correct, the point is that the excessive use of JS is what makes nowadays the print command the only way to save most Web pages.
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.
>I politely disagree. The original intent Tim Berners Lee had [1] was to create a navigable way of finding documents and information. Not printable.
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.
This might be more of an edge case than people who complain about websites that require JS, which is itself a number that rounds to basically zero.
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.
Maybe it's a weird, unusual edge case but maybe not. Lots of people need to keep records of various things for various reasons. In my personal life, I also "print" lots of stuff from various web sites to PDF for record-keeping purposes. This is absolutely routine for me, I do it all the time.
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.)
The resolution of screenshots is typically unacceptable for most uses, especially when the bitmap were scaled, which would introduce blurring.
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 used to. Apologies if it came on too strong, but it wasn't idealistic thinking. For print, I find that I can easily use AI to turn a web page into a nice clean LaTeX and offer that as a PDF for those that want to print or read offline.
But that's impractical (not to mention non-deterministic and a bit of a privacy risk) for any kind of online printability of dynamic information.
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.
It’s weird that you’re opposed to a few lines of CSS but happy to boil the ocean to implement the same thing via non-deterministic AI.
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.
The Web is meant to have links and interactive content and be navigated, sure.
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.
TBL’s vision is the starting point, not a straitjacket.
And that's the crux!
The idea of printing out one of those documents does not conflict with this.
Don Quixote, is that you?
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.
Print is still an accessibility thing, I think.
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/
I see the same thing. It looks like the height of the "My accidental pnmp forkbomb" screenshot is causing it to jump to the second page
One of the lovely things about html/css as print medium, is that interpretation of page break seems to vary between browsers, and while you can use CSS to prevent a particular page break, you can't use CSS to force one inside an element like an img tag
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.
That was on Safari, but I just tried on Brave (Chromium-based), and the result is pretty similar
I'm looking on Chrome for Windows and it looks just like the web view.
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.
Unfortunately I just tried Chrome for Mac, and it too insists on inserting a spurious page-break to keep the giant screenshot on the 2nd page. I couldn't find a CSS incantation to prevent this.
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.
In some countries, printable tickets and other things once delivered as elaborate PDFs, are increasingly replaced by a QR code that can be printed from a barebones webpage, or even delivered outside of the web like to one's WhatsApp.
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?"
This comment suggests the answer is yes.
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.
Absolutely yes. It’s offline friendly, free of distractions, stays on page between reading sessions, and easy for marks and annotations.
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)
Sounds like SVGs would work well for this.
The advantage of a COLR font over SVGs is that they are functionally identical for this use case (indeed, the font in question was converted from SVG vector files) and a good deal more compact to boot.
But it's only by default. So the super easy workaround is to check the "Print backgrounds" box when printing.
You might be able to fix this with a few simple print CSS rules though.
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>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.
Have you looked into the CSS paged media directives?.
https://developer.mozilla.org/en-US/docs/Web/CSS/Guides/Page...
I was dealing with something similar and ended up writing my resume in markdown and converting the markdown to html, pdf, and png (with tools like pandoc and tectoni) in CI with a custom GitHub action I wrote: https://github.com/alDuncanson/md-press
Oh man, we are kindred spirits.
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 wrote two xsl stylesheets and then encoded my resume in xml.
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.
I remember leveraging xml and xslt for doing the exact thing for my resume! This was quite some time ago, when xml was king. So, as a way to both unify my generation for my resume but more importantly learn more about xml, xslt, i created what sounds like a similar pipeline to yours. It felt really cool, and i learned about xslt - which to this day i'm impressed by. But, over the years as xml, xslt seem to have waned, plus i never got to use such skills at any of my jobs, and finally employers just wanted a Word doc, not a PDF...then i just stopped using my setup. Nowadays i simply keep a local copy of an .ODT file, and export to word or PDF, or whatever format an employer or recruiter asks for...and like 99.999% of the time its a Word doc. But, back then, it certainly as fun learning that stuff!
I think you can generate html from latex, I use latex for my CV and render it as a pdf for circulation.
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.
You can even have footnotes with links to other pages which automatically include the target page number in the text. Print CSS is actually pretty powerful. Just browser support is bad. I use “Prince” to convert html to pdf. With good CSS you can have a really good quality output. I used it to export a pdf for a whole book that way.
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.
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.
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.
Assuming no one surreptitiously swaps out the pages!
You still gotta keep it secure. ;)
Or uses white-out and splices numbers into different places. It's happened before.
this.
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.
Bring back the auth.warn paper trail!
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.
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.
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.
In the early 90s, I would print out usenet posts so I could read them on the commuter train. Seemed a good idea at the time and I probably read them with more attention than my current online practices.
* I don't feel that's a charitable interpretation of the OP's comment. I have seen people print emails just to read them, including a page of CCs they discard, or 37 version of the draft slide decks, etc. And that's on their own printer - the office printer pre-COVID was just always printing random pointless stuff (as witnessed by the volume of it that was never even picked up!:). I don't have particular urge to print randomly, so I probably fit into the "unless absolutely necessary" group, but goodness there's a lot, and I mean a LOT of paper waste that doesn't provide entertainment value of nascar or B&N.
* (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 will take books...
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.
Printable does not mean it will be printed, if a page is printable one can assume the creator hasn't fucked with the scroll wheel for example, or forced you to sit through unnecessary animations.
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
Did they mean specifically printing to paper? Unfortunately the term is overloaded to include exporting to pdf, ePub, etc...
Or do you mean even exporting is a waste of resources?
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.
I personally think the things you enjoy that aren't absolutely necessary are a waste of resources too.
I often print things that I do not want but need to read, and go outside with it.
Cuts well on procrastination.
If a tree falls in the woods and there's not a hacker around to complain about it and demand government regulation against it, does it make a sound?
Sure.
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.
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.
I cannot recall last time I printed something.
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).
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.
Did you try e-ink / e-paper ? (Remarkable etc.)
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.
You can still copy paste and zoom.
Magnifying glass? Copy is hard, cut and paste, glue etc sure.
Yes to magnifying glass for zoom.
You copy with a pen or pencil, like the monks did.
Yes to cut and paste with scissor and glues.
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.
I do a lot of printing for TTRPG's.
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 started out printing complex claude plans to go through them in a different setting, make notes, think about it, modify, then tell it to execute.
But website printing in general, I see less of a need.
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've been trying to print a sewing pattern today, but apparently 2d printers are even less reliable than 3d printers, somehow
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.
I think we all know the real reason, which I knew at the time as well: if you print the page, you aren’t seeing new ads.
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.
this is for the authors/publishers of tuhat writing platform you mean?
Inserting the page breaks is for the authors, its a button in the editor when creating a post. The download epub / create printable pdf are on the posts for readers.
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."
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.
https://pagedjs.org is a pretty good polyfill for [1]
Yeah Paged is my go-to for CSS PMM at the moment. When PMM does hit browsers - if it ever does - it'll probably be some sort of transpile of Paged. Plus the stuff you can't really do just from JS/TS.
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.
[0] https://cc.vvvvvvaria.org/wiki/Octomode
> 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 love the irony of an article about being able to print properly doesn't even appear correctly in the browser. Perhaps we should start with the basics...
yes, if you highlight it you can see what it's meant to be
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.
Any kind of statement, confirmation, or receipt should be printable. Some places still require printed documentation of expenses for reimbursement (even if it's only to turn around and scan it; you can argue it's silly but that doesn't mean it doesn't happen). A paper print is also an easy, cheap, immutable and durable one-off backup for anything you're looking at on your screen.
Yes. Also any press release, privacy policy, terms, ideally your contact page and user account screens. Stuff that might come up in a dispute or might be necessary in PDF form in a handover document. And any documentation for a physical, offline device or appliance.
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.
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.
Let's add a AI powered beautification to Ctrl/Cmd + P in the browsers.
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.
I mean, with Jira it's not the nicest out-of-the-box template for PDF export, but it works. It does it's job if you are okay with ugliness.
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
The most common avoidable annoyance is the forced huge margins, like it's assumed you always fullscreen the webpage. However, making things printable would fix that and all sorts of usability problems too.
I did. It’s perfectly readable. What was the issue you experienced on your phone?
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)
Author here, I don't personally use my phone to access websites often, so I forget to check on things like this. My bad! I'll take a look into it when I get a chance.
If I have to zoom on mobile, I go straight to Reader mode. If that doesn't work, I close the page.
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?
Yes, with css media queries, but just as with all css, its very quircky.
printing webpages feels like trying to view the internet on a mobile browser in the old days.
Nope, let’s keep printers in 2004 where they belong.
Too many people are thinking that "printing" here necessarily involves paper. I almost never print on paper but I "print" a lot of stuff to PDF. A lot of that is just record-keeping but some is for other reasons.
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.
hell no. paper is such a waste of material. use eink if you hate lcd/oled that much.
There's black-on-black text for me for `onlyprint`.
I hate paper, but it's probably still worth it for being able to easily convert to a PDF. It's not that hard to do if your website isn't a hacked together mess to begin with.
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.
[0] https://www.myunscroll.com
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.
paper should be banned
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].
[1] https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/V...
[2] https://developer.mozilla.org/en-US/docs/Web/CSS/Guides/Frag...