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

Markus Ernst derernst at gmx.ch
Mon Dec 28 05:31:32 PST 2009


Anne van Kesteren schrieb:
> On Mon, 28 Dec 2009 12:54:00 +0100, Olli Pettay 
> <Olli.Pettay at helsinki.fi> 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. 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)
> 
> Throwing an error does not seem very compatible either.

Printing should IMO be left up to the UAs. They provide print 
functionalities according to the browsing situations they are built for.

In-page print buttons typically appear in pages authored in a 
printer-unfriendly way, such as using frames or a table layout, lacking 
a printer stylesheet. Often the in-page print button just opens a 
printer-friendly version of the page, without even invoking the print() 
method.

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.


More information about the whatwg mailing list