[whatwg] [html5] onbeforeprint/onafterprint (was window.print() undefined)

[Matthew Raymond]

Jim Ley wrote:
> On 7/19/05, Dean Edwards <dean at edwards.name> wrote:
> 
>>Matthew Raymond wrote:
>>>For instance, such events could be combined with AJAX to force people
>>>into a pay-to-print scenario.
>>
>>What's wrong with paying to print a high quality version of an image? If
>>you ask me this is a great example of why we should allow these events.
> 
> This is another of the use cases I've used "enhanced" printing for - I
> actually generally used ScriptX http://www.meadroid.com/scriptx/
> rather than simply the IE methods, but the events are all that's
> needed.  Not paying for printing images, but swapping out images with
> higher quality images suitable for print.

   Once again, I don't understand why you can't simply provide the user
with a button on the web page that either calls up a printable version
or clones the document so that the clone can be used for printing.
(Granted, there probably isn't support for the latter, but it makes more
sense to standardize that than to add onbeforeprint and onafterprint,
especially when you consider the fact that a clone of the document can
be held in memory for repeated printing or dumped.)

> Someone will probably suggest CSS background-images as a suitable for
> this aswell, yet again ignoring the fact that CSS is _optional_, and
> content-images must not be in background images as they simply won't
> be seen without CSS or if background images are disabled.

   I don't think anyone is still making an argument for a CSS solution
at this point in the discussion. At best, the current argument would be
that you rarely need anything more than CSS, and when you do, a separate
"printable version" page is sufficient.

> I can appreciate the viewpoint that onbeforeprint/onafterprint aren't
> archetecturally brilliant, but then most of web-applications spec
> isn't brilliant from an architectural perspective - it's shoe-horning
> web-application functionality into a document mark-up language,

   As far as I can tell, no part of WF2 or WA1 encourages malicious
behavior on the part of the webmaster against the users. In fact, part
of the problem I had with <dataentry> was that it could, in theory, be
use in a hostile way towards legacy user agents. Therefore, I doubt this
will ever make it into a WHATWG spec, especially when it can interfere
with simple things like printing selected text, et cetera.

> however I don't see what's especially bad about
> onbeforeprint/onafterprint, and they're very commonly used in intranet
> applications - 

   ActiveX is commonly used in intranet applications.

> if Opera and Mozilla are going to make any headway
> there we need the kind of high quality print control that is
> obtainable with IE.

   Now you've completely lost me, use-case-wise. On an intranet, why is
a printable version of the document not an acceptable workaround?

   It really doesn't matter though, because manipulating and printing a
copy of the document is more effective anyways without disabling or
changing part of the browser functionality.

   Here's a question for you to chew on: What happens if you want to
print and the webmaster screwed up something in the onbeforeprint or
onafterprint event? Will it effectively disable printing? Will the
document be restored once printing is finished? What if it's an AJAX
application and the UI of the app is hidden for printing but never
restored? I don't really think we have a use case that justifies the
possible harm.