Anne van Kesteren schrieb:
On Mon, 28 Dec 2009 12:54:00 +0100, Olli Pettay
<olli.pet...@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.
