[whatwg] window.print() when printing is not supported

[Ian Hickson]

On Mon, 28 Dec 2009, Olli Pettay wrote:
> 
> currently 
> http://www.whatwg.org/specs/web-apps/current-work/multipage/timers.html#printing 
> says that window.print() should prompt user to print the page, but that 
> "For instance, a kiosk browser could silently ignore any invocations of 
> the print() method."
> 
> A print button in web pages is quite common, and if pressing that 
> doesn't give any feedback (and the web page can't even detect if it 
> should give some feedback of missing printing), the user experience 
> isn't quite optimal.
> 
> So I think it *might* make sense to throw some error if printing isn't 
> supported.

That is a conforming implementation of the first step of the printing 
steps ("The user agent may display a message to the user and/or may abort 
these steps").


> Or should browsers which don't support window.print() just not have 
> print() method in the window object? (problem is that I'd guess everyone 
> just expects .print() to be there)

All browsers are required to have the method.


On Mon, 28 Dec 2009, Markus Ernst wrote:
> 
> I'd rather suggest to mark the print() method as deprecated, encouraging 
> authors to use modern printer-friendly authoring techniques. Also, 
> browser vendors could be encouraged to offer a setting to disallow 
> scripts to hide the main menu, or the toolbar that contains the print 
> button.

On Mon, 28 Dec 2009, Tab Atkins Jr. wrote:
> 
> I've had design requirements to include a print button in pages. 
> Apparently many users *expect* such, and don't realize they can print 
> from the File->Print option (and/or don't realize that this can print a 
> printer-friendly version automatically).
> 
> I include print stylesheets, so all this button ever does is call 
> window.print() for them.

On Mon, 28 Dec 2009, Aryeh Gregor wrote:
> 
> Wikipedia is the same deal.  We've supported print stylesheets for ages, 
> so there's absolutely no difference (at least in theory) between 
> printing a page, and clicking "Printable version" on the sidebar and 
> then printing the page.  But some users apparently expect a "print" link 
> of some type on the web page itself.

I've left window.print() as conforming, based on the above feedback.



On Mon, 28 Dec 2009, Michael A. Puls II wrote:
>
> As for window.print(), what if it returns false if printing is not 
> supported? Then, authors that want to can use that and provide info *if* 
> the want to. Or, it could throw a not supported exception and one can 
> catch it and do something. Those sound better than just ignoring the 
> print() call.

What could a Web page do that a browser couldn't do better in the same 
situation? (The browser could offer a PDF, so having the site offer a PDF 
when there's no printer doesn't seem like a good solution.)


On Mon, 28 Dec 2009, Michael A. Puls II wrote:
> 
> Since making print() return something isn't going to help with older UAs 
> and returning true would feel backwards, instead of:
> 
> if (window.print()) {
>    alert("Printing is not supported");
> }
> 
> , we could do this:
> 
> if (typeof navigator.printingEnabled === "function" &&
> !navigator.printingEnabled()) {
>    alert("Printing is not supported");
> } else {
>    window.print();
> }
> 
> It's more verbose though and I'm not sure any will like it. But, tossing 
> it out there.

If all it's going to do is alert "Printing is not supported", then the 
current spec text (which allows the UA to alert such) seems better, since 
then it only has to be implemented once per UA rather than once per site.


On Tue, 29 Dec 2009, Olli Pettay wrote:
> 
> Yeah, navigator.isPrintingEnabled or some such could be also useful.

To do what?


On Mon, 28 Dec 2009, Kornel Lesinski wrote:
> 
> Why would page need to know if printing works? What (useful) thing could 
> it do if it detects failed print?
> 
> If all you want is to display error when printing fails, that's a UA 
> issue. Why burden all sites with handling of error they can't fix? UA 
> can signal the error, and can do it better, e.g. offer option to 
> configure a printer.

Indeed.


> I'm afraid that even letting pages know whether printing is available 
> might have negative consequences.
> 
> I can't print anything from computer I'm using at the moment, BUT if I 
> need to print something, I can save page/document and print it from 
> another computer. If pages could detect that my computer can't print, 
> they could wrongly assume I can't print anything at all, and hide 
> print-related options from me. I'd hate if ticket sites automatically 
> decided to snail-mail me tickets without offering option to print them 
> myself.

Also a good point.


I haven't made any changes to the spec in response to the above, because 
it's not clear what change would benefit users. The spec already allows 
UAs to basically do whatever they want in response to window.print().

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'