Whither print.css? A Rallying Cry for a Web That’s Fit to Print (2013)
modrenman.comThe premise is questionable. A webpage lives in its own medium, or it is its own medium. It is normally meant to be read with an electronic device, to be interactive and linked, though those devices can be quite different of course.
But by printing a webarticle, you are transforming it into another medium, onto paper. Therefore it is actually a very strong assumption - and one I don't follow - to "expect them to support the habits of people who prefer to read longer articles in print".
And that even before talking about protecting the nature from wasteful habits like this.
But sure, if you enjoy it, build a small print.css, removing everything unnecessary and making it readable in black&white. Just be aware of the medium change, and that a good design in the one medium won't necessary work in the other.
> The premise is questionable. A webpage lives in its own medium, or it is its own medium.
You have to bear in mind that this view is diametrically opposed to the principle of separating presentation and content on which CSS, the HTML content-markup elements and so on were based.
I think I know what you are targeting at, but I really don't think so.
You can have a separation of presentation and content while still targeting a specific medium, the separation doesn't automatically mean that the content is fitting for every medium.
And the elements used here show that pretty clearly. When just regarding HTML and ignoring CSS, you can see its elements that are made for other mediums than paper. It is Hyper Text after all, not Text.
And when just regarding CSS, you have all those elements that are of no use on paper, like position: fixed.
Or just think of the issue in responsive design of wanting to have another, shorter text for mobile devices. There, even the content alone is not fitting for the medium, regardless of the presentation.
> The premise is questionable. A webpage lives in its own medium, or it is its own medium. It is normally meant to be read with an electronic device, to be interactive and linked, though those devices can be quite different of course.
The corruption of the www is something that still makes me sad and angry even though I know I lost the argument years ago.
You should not know, nor care, how the reader is usin the information. Maybe they have screen readers or braille devices or extra huge high contrast text. Maybe they want to print it out.
Most www tex does not need to be forced into an app (which is usually a really bad browser) or to be forced into specific layouts and columns with widgets and gadgets.
I really wish newspapers would learn this lesson.
I want the text. Put all the banners and gizmos and adverts at the top and bottom of the page. Then give me nicely formatted properly styled text and get out of my way.
I am happy to pay for this. Real money, not just leaving an ad-blocker turned off.
Now I feel misunderstood.
I'm perfectly fine with using different devices and different presentations. But changing mediums is stronger than just changing the device or the presentation. The web has an underlying vision that can't be transported to every medium:
> He [Tim Berners-Lee] kicked off by explaining what he means by the two words "semantic" and "web." Underlying the Web was the philosophy of a navigable space, with a mapping from URI to resources. He stressed that a URI was an identifier for a resource, and not a recipe for its retrieval.
Sure, maybe you can argue that you can build something like this with paper, but it is not practical. And you can't do that anymore when going to the semantic web.
Therefore, I don't think you can expect webpages to support mediums like paper that are intrinsically not web-able.
That's all I'm saying. Nothing about ads, nothing about apps, nothing about app-browsers.
PS: Why the downvotes? Did I formulate an attack I didn't realize?
I don't understand. Paper can't navigate but you don't need navigation. Why can't the underlying vision of everything except navigation work just as well?
The web is more than a place to read an article like on paper. It is a place where articles (ressources) have their own URL and are linkable, sometimes even in both directions (think of trackbacks and pingbacks, following the vision that was way more prominent in the beginning, or xanadu). You need navigation for that, it is essential for what the web provides.
> The corruption of the www is something that still makes me sad and angry even though I know I lost the argument years ago.
You and me both. It is kinda funny (for the lack of better word) how Wikipedia is kinda what I imagine hypertext/web was initially envisioned to be (except for its centralized nature). But it lives another layer above the web, being a web-app for handling hypertext with it's own UI (nested inside browser UI which in turn is nested inside system UI), its own markup format (because HTML evolved away from being pure hypertext format), and its own update mechanism (instead of HTTP methods, because REST is hard, lets go shopping)
I agree to this a lot. The printing medium is an entirely different target to optimize; say, the figures need to be consolidated to individual pages or made small enough to fit the aside, all the convenient hyperlinked references need to be at least reconsidered as they will constantly stop the reading when rendered, even the document structures need to be reconsidered (we have a table of contents for a reason). Heck, even that website itself does not optimize for the figures either---lots of irrelevant images take up their own pages, one per page. It is hard, and takes real work to get that good enough.
>> And that even before talking about protecting the nature from wasteful habits like this.
Unfortunately, reading on paper is an order-of-magnitude better than reading on the screen. I have consistently noted that:
1. I absorb the material better when reading in printed form, not sure why. 2. My eyes strain less. 3. I find three times more typos (when proof-reading my own stuff), not sure why. 4. Annotating and highlighting is doable (possible on screen, but does not even compare to the same on paper). 5. Moving back and forth within the material is a lot better.
Not that I like hurting nature, but technology doesn't yet offer a suitable replacement here. E-Ink helps but fails on #4 till better products (like Sony's recently announced E-reader) show up and are less costly (Sony's priced at $1000+). Also, moving content to the new device needs to be at least as convenient as printing (and while staying within the firewall).
>> It is normally meant to be read with an electronic device
This is exactly what OP is questioning, and I fully agree. Why is this normal?!
>> to be interactive and linked, though those devices can be quite different of course.
I am web newbie. But I wonder about mankind spending so much effort on making web pages "responsive" based on the screen sizes of the various devices, and yet, not applying the same techniques to printing.
Part of this is because most web media is awful for reading.
Column widths are standardized in print, magazine, and books for a reason: to minimize eye movement required. The larger that web screens get, the broader the column lengths often are, which forces more eye movement, which causes eye strain, which requires vision interruption, which impedes reading comprehension.
Smart phones are great for short articles because the screens are roughly the width of a newspaper column. It forces the text into an appropriate width, rather than expanding to fit the available monitor space like many websites do.
Screens also tend to cause eye strain.
Even if you do make pages responsive, chances are that the user will not realize that they should be using a skinny window or that they should shrink the text. Further, commercial web publications tend to optimize for maximized windows to display ads.
In print, we have hundreds of years of professional readability and layout experience. On the web we have some cobbled together standards. Most people who are responsible for handling web design aren't layout/typography/etc. specialists. So really basic mistakes get made all the time and few people notice them because our knowledge base has effectively eroded because there are so many other priorities to worry about on the web.
This was insightful. Thanks.
Readability with paper is better even without columns though. Also, since I do majority of my work on big desktop screens, positioning with respect to the body also could be impacting. Using bigger fonts on-screen helps, though does not work out on many websites designed with small fonts.
You're welcome. Yes wrt paper being better even without professional layout.
I didn't really start to get these things until doing some print work after years of being internet-only.
The writer is talking about articles, as he notes in his first sentence. The problem he points out is part of a larger problem: that web content clearly intended to be read, is often presented a context that makes reading inconvenient or difficult.
If someone posts an article on the web, I don't think it's too much to ask that the article be presented in a way that enables it to be read conveniently. Good print formatting is part of that.
While I do think that doing throw-away prints of webpages is bit questionable, there is still some value in making webpage print out nicely. I think "printing" PDFs is one of the easiest robust ways of archiving web pages. It creates nice static self-contained local copy of the content, which is readable basically on any platform.
Another example would be e-readers (eg Kindle) which in ways are closer to print than web as a medium. They are not currently really equipped to handle web-pages well; Send to Kindle extension seems to do some sort of readability-like heuristic when formatting web-pages to be sent for Kindle. It would be kinda nice if print css would be good enough to work as-is on Kindle (etc).
Of course there is the question of the overall quality of current web-design. Many pages are just ridiculously busy to begin with, something that somehow becomes accentuated when printed out. Maybe designers should spend a moment after building a print layout reflecting if all that stuff that needed chopping away for print was actually necessary to have in the first place.
I personally don't care that much about most articles being printable, but if you're making any kind of material that is supposed to be studied, please, please make sure it's properly printable. Doing research / studying a topic is something that is still infinitely easier to do on paper IMHO.
Having said that, does anybody know a decent web-based app for researching stuff? What I definitively need is:
* Ability to have a collection of related articles in one place
* Simple list of bookmarks that link to a specific part of the text.
* Highlighting in different colors
* Adding comments to a page that are _easy_ to view. Preferably in a sidebar next to the page or something.
* Adding links to external sources interactively to the document
* The ability to write a summary of the article
I've searched before a few times, but I've never been able to find something that had all the above and, more importantly, properly integrated those features.
I've been using Scrivener to organize materials for research projects: http://literatureandlatte.com/scrivener.php
It has a steep learning curve, but only because it's so powerful and extensible.
Check out Zotero.
It is primarily a reference management suite, but it can do some of the things you require.
Unfortunately, printed media support in CSS still sucks.
I have a web app that needs to generate printable official documents, and it's really not possible to do a good job with CSS. I resort to generating PDF in Javascript, which is laborious and duplicates a lot of effort.
My biggest gripe is the inability to control the header and footer and the inability to sanely specify where page breaks are allowed.
"page-break-inside: avoid" and "page-break-after" seem to work fairly reliably, as long as you aren't doing too much weird stuff with positioning, floats, etc.
Three major problems I've had with printing from HTML is 1) It seems that the different browsers have different default margins, and the outside margins aren't controllable from CSS 2) The javascript print dialog doesn't give any sort of feedback...it just blocks JS execution. There's no way to no if the user cancelled the print, etc. 3) Different browsers don't reliably resize things to fit on the page. Using percentages for anything (while maybe not recommended anyway) just doesn't work for printed CSS
I fought with those and eventually gave up, because their implementations were either broken or missing in the browsers I was supporting. But that probably 18 months ago now. Maybe they have improved.
> the inability to sanely specify where page breaks are allowed.
I can usually explain away the issues of printing from a web page, except for this point. My customers always have difficulty accepting that I can't set page breaks. Cruel first-world problems!
I've used <table style="page-break-inside:avoid;"> to prevent unsightly page breaks. (specifically for rendering web pages that are then captured and served as PDFs)
The idea of printing a web page (particularly an article) does seem, in many ways, pointless. As others mentioned, it's a fundamentally different medium that strips out all of the things that make a web page compelling (linking, dynamicism, etc.)
On the other hand, there's clear value in stripping out the ephemera and detritus around a work in order to concentrate more centrally on the work itself. While the idea of "printable" becomes less and less tenable, the core idea of focusing on the work itself is still important. In some ways it seems a loss that these ideas have become conflated.
I printed out the HTML 5 spec from W3C. http://www.w3.org/TR/html5/single-page.html
It's so much easier to browse through pages on the desk, the fit on 30 pages or so that I stapled together.
Printable is less valuable to most people, but it still has value.
Plain text is not accessible but a well crafted printable version can double up as both printable and more accessible for some users.
I wonder what the equivalen of "printable" will be? "Text on your ereader that you can annotate"?
Sometimes you remove the dynamicism on purpose.
Based on what I'd assume the user base for this kind of thing is, I'd support IE6 before I worried about printing.
So recently I re-built the theme for Read the Docs which some of you more pythonic devs might be using. Despite having designed sites for nearly two-decades it was the first time I'd ever gotten a request to make sure there was some print rules in there. Makes sense with docs.
The funny bit of course is I didn't even know there was a specific print rule I could use. Took me about 10 minutes to fix.
Actually, looking at the design now I just noticed a bug. Off to my text editor!
I've heard of people printing whole articles and reading them in paper format before.
Personally, I would rather have a print.css that hides everything but a message that says "save the trees, don't print an article only to discard it after".
We do have some clients that ask for their website to be printable, but it's mostly clients that are in the legal or medical business. It doesn't come in regular contracts, the client has to ask for it.
Depends what happens to the paper thereafter of course . Somehow, printing out articles from the web seems pretty small beer compared to felling trees in the forests of North Carolina for conversion to wood chips and transporting them 3,000 miles to Drax Power Station in the UK. Not a one-off! There is a purpose-built dock at Chesapeake Port, just across the state line in Virginia.
http://www.dailymail.co.uk/news/article-2290444/Madness-How-...
http://www.theguardian.com/business/2012/feb/21/drax-scraps-...
Funny you bring up the aspect of saving the trees, because I followed up the post with a suggestion for how Google can reduce the waste by taking more control of the print experience in Chrome: http://www.modrenman.com/2013/05/01/save-the-rainforest-goog....
More than anything else, I just wanted to bring attention to something I think many people don’t know about, because I think it’s mostly a case of people not minding printed web pages rather than them not caring.
See my comment here:
https://news.ycombinator.com/item?id=7609711
I would find this message rather rude. I am interested in saving trees, but do not think technology offers me a solution yet. I print out of necessity.
Of course, this was a joke more than anything. Printing the web is fine when it is needed.
I'm talking people going to a news website, printing the article, reading it and discarding the resulting paper afterward. Unless you need to annotate or use the printed articles in some of the ways you listed, you shouldn't be printing all the articles you see.
That matches my understanding too.
It still makes me suffer a lot though because optimizing for printing us clearly not the norm.
Also, I frequently cache articles by printing to PDFs not knowing a better way of capturing a static snapshot of a web page into a single file. I do not print these, but the resulting PDFs suffer from the same layout issues. Also, links do not get converted. (Several PDF software makers supply plugins for Microsoft Office, but almost none for web browsers.) I am happy to hear if someone has a better solution for this (other than using Internet archiving for such cashing).
The only thing that I usually bother to ensure really works when printed is receipt pages. I haven't even owned a printer in years, but printing receipts to PDF is something I do daily.
I'd suggest OP buy a Kindle, but on the other hand you probably need to go through quite a few reams of paper before you make up the environmental cost of even just the lithium-ion battery...
I feel like browser print support is like CSS support at the end of the last millennium: fragmented and not guaranteed to be decently supported if at all.
I wanted to make a print style for my CV and it just was a terrible pain to get things like per page header and footers.
Internet Explorer has by far the best print preview and printing engine. It hasn't changed since v4, nevertheless it is still better than any other browser.
One can zoom the page content, print only selected content, disable background pictures and color, print only main content (no menu bar), etc.
Interestingly enough, I tried out NCSA/Spyglass Mosaic v3 32-bit on Win7 and it already had almost the same print-preview features that are still available in IE (IE 1 emerged from Mosaic code base, IE up to v6 had "Mosaic" it in the copyright text in the about dialog).
Please browser vendors improve your print preview engine!
The poor letter-spacing, or more accurately kerning, is that either the fonts in use don't have kerning pairs or they're being ignored, as web browsers seem to do. Printing from another typeface would solve the former, but in my experience (and not thoughtful research), kerning pairs are ignored in every browser. Firefox does give an effort, though, with automatic optical kerning, but it often crashes letters together while leaving too much space between others. It would be interesting to know if that feature translated to print.
I always go with firefox for printing a page, chromium always fucks up the kerning so much more.
I did notice that it was a lot worse on small font size, as the article did too, and it's really annoying: font are supposed to be scalable, why isn't there the same kerning errors on bigger sizes?
Unless printing the page is a useful and usable byproduct (which may be the case in certain SaaS scenarios), I wouldn't give a print stylesheet more than 15 minutes of my time.
We have a little tool that can produce a multi-column print view (based on paper size and orientation) from most web-based articles. Chrome doesn't support multi-column CSS in its print view yet, so it doesn't work there. If anyone's curious, there's a video here: http://blog.fivefilters.org/post/75603097111/pdf-newspaper-2...
Chrome had support for multi-column CSS for several months (2 years or so). But Google forked off Webkit (Blink) and removed advanced CSS code known as CSS Region that has been contributed by Adobe to the Webkit project.
It's quit sad that Google favors broken CSS support in Chrome v32+ with their new "mobile 2014" strategy.
As a direct reaction too Google action, Apple remove ShadowDOM from Webkit.
Even if we all agreed to make sites printable you would never be happy with it. Right now certain CSS rules such as "float" can not be applied to print. This means you can not do any advanced layouts without totally redoing your HTML.
It is far more important to have a site mobile compatible than print compatible which again will probably cause some HTML refactoring. So more websites are going to worry about being mobile compatible and not waste their time on print.
The percentage of people who print a site is so negotiable, that like mcmillion said you would be better served supporting IE6. This combined with the fact that print versions can not match the screen version means you'll probably never see a site embrace your rallying cry.
Your best bet is to stop killing trees and get a Kindle Paper White or other e-reader with a web browser.
I would love to see an E-ink-based product:
- That makes annotating and highlighting nearly as easy as with pen and paper
- Which also is not too expensive (Kindle DX pricing is fine, newly announced Sony's e-reader at $1000+ is not), and,
- Which supports easy transfer of content/URL to the device from within the firewall. (E.g. Virtual print driver that sends to the device and opens it there.)
Will be very happy to hear if there is a solution that I am not currently aware of!
I couldn't disagree more with the author about appended URLs being a problem. A print stylesheet is exactly when you want URLs to be displayed in the text of the page, because there's no other way to find out where that underlined text is supposed to be pointing.
URLs should be displayed for sure, but inline is far too disruptive to smooth reading. I think it would be better done "reference style" if possible. Something similar to how it is done in markdown would be nice:
I get 10 times more traffic from [Google][1] than from [Yahoo][2] or [MSN][3].
[1]: http://google.com/ "Google"
[2]: http://search.yahoo.com/ "Yahoo Search"
[3]: http://search.msn.com/ "MSN Search"
CSS3 has support for footnotes in the page module.
http://www.w3.org/TR/2011/WD-css3-gcpm-20111129/#footnotes
It adds a float: footnote; property. From reading that page, I believe this might work, once browser support catches up.
There are some other interesting additions:a::after { float: footnote; content: attr(href) ' "' attr(title) '"'; }
This will put the page title in the top left corner of the page margins.title { display: none; string-set: title content(); } @page { @top-left { content: string(title) }}It can also be simplified to "I get 10 times more traffic from Google[1] than from Yahoo[2] or MSN[3]." Note that I removed the square brackets from the URL text.
While this is information-lossy, the context of the link is nearly always clear from the text.
Footnotes work great for this, just like the olden days (or exactly like Wikipedia).
fwiw, we launched a new design for the NYT in Jan with a proper print.css stylesheet.
I don't find this post that useful. It goes through some sites, criticizing what they do wrong (what the hell does "anti-print" mean?), but offers no explicit examples of sites that get it all (or all-1) right. Kottke.org has colored links and sidebar (on a print out? those are useless). I'm not a designer, but I still like to create nice looking things. No points are given on what makes a nice printout, even though some of the examples given look completely fine to me.
There is a CSS/HTML rendering engine for print, PrinceXML http://www.princexml.com/ - it is extremely good quality. It is not open source, but does fill a niche gap. If you need to produce quality pdf output from a single source it could be worth looking at.
(its also interesting in that it is written in a functional logic programming language..., and that it is a small Australian startup)
ConTeXt also provides an XML interface. Unlike PrinceXML, ConTeXt is open source. The community is quite friendly. I've been using it for a couple of years now to produce PDFs from a single source. In my case, I first transform the XML into ConTeX code using XSLT, a step that simpler systems might not require.
Based on quick look, ConTeXt requires you to handle an unholy mixture of XML, XSLT and TeX (and maybe even Lua?), whereas PrinceXML last I checked was just (x)HTML+CSS.
PrinceXML is actually a CSS engine for print, so there is more reuse.
ConTeXt looks interesting though, I haven't really been following whats been going on for a while, looks interesting.
I've used WeasyPrint combined with custom templates in some web apps to get the job done. Worth looking into if this is a key part of what you are building.
Have you figured out how to have headers and footers with HTML in it? I am currently trying to figure out a solution to this.
The point about “text is too big” is really, really strange—using 12pt in print is okay, but you should never use it for a screen—everyone's reading from the screen from a much bigger distance, and resolutions are getting higher and higher.
I frequently see texts in prints though, especially headings, that start overlapping with other things around. This seems way more common than what I would like. Once in a while, believe it or not, all the characters print on the top of each other for headings. All this is such a mess.
print.css = "Hi, I need you to continue to support this increasingly smaller edge case, to make this rapidly dwindling user base happy about something that should not, under any circumstances, be happening in 2014."
Supporting the printing of pages is inefficient and wasteful. It's the IE6 argument all over again. There are more meaningful ways of both storing and distributing information digitally.
Even for atacrawl's scenario - we should be building systems that make these types of documents easier to fill out digitally than on paper. I don't know about you guys, but when I have to fill out a paper form, I get frustrated because of the near-universal poor design.
Printing should be dead. Why are we keeping it on life support?
Also, I say this as a designer.
This article criticizes a derivative work's typography? We're really looking at a site's print.css and kicking up a fuss because it's not up to snuff?
"Here, let me print out this Daring Fireball article and mail it to my buddy in New Mexico" ?
Get the actual fuck out of here.
I do not understand the need to print out any webpage. The occasional form for a bank still requires faxing but that is usually a pdf anyways.
Also, what about the environmental cost? If we make it easier to print, will more people print? Whether we make it easier to print or not I suspect that as children are exposed to technology at a very young age there will be less of a need/want to print. When you have a tablet that you can take with you anywhere, what's the point?
If something is hard to print in a legible/useful manner, somebody is likely to print it once, realize things didn't turn out right, and then try to print it a few more times with different settings until they get something that works (or they give up).
So making things easier to print probably helps the environment more than hurts it.
Forms that still require papers copies to be kept on file?
HR dept that require paper resumes?
Perhaps I just want to format my resume as a PDF using the browser print to file (my main use case)?