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.
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.
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.
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.
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.
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.
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.
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.
It has a steep learning curve, but only because it's so powerful and extensible.
It is primarily a reference management suite, but it can do some of the things you require.
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.
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 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!
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.
It's so much easier to browse through pages on the desk, the fit on 30 pages or so that I stapled together.
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"?
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!
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.
http://www.dailymail.co.uk/news/article-2290444/Madness-How-...
http://www.theguardian.com/business/2012/feb/21/drax-scraps-...
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.
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.
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.
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 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.
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!
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?
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.
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.
- 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 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"
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.
a::after {
float: footnote;
content: attr(href) ' "' attr(title) '"';
}
title {
display: none;
string-set: title content();
}
@page { @top-left { content: string(title) }}
While this is information-lossy, the context of the link is nearly always clear from the text.
(its also interesting in that it is written in a functional logic programming language..., and that it is a small Australian startup)
ConTeXt looks interesting though, I haven't really been following whats been going on for a while, looks interesting.
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?
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.
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?
So making things easier to print probably helps the environment more than hurts it.
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)?
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).
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.
I didn't really start to get these things until doing some print work after years of being internet-only.
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.
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?
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)