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

[Jim Ley]

On 7/20/05, Matthew Raymond <mattraymond at earthlink.net> wrote:
> Jim Ley wrote:
> > 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.

The  main reason is that my users have always said they want to use
their regularly printing mechanisms, not some link that opens a new
page, and then lets them do it, it's simply much too slow for any of
the users.

There's also signficant problems - the server implementation for your
above is extremely complicated and slow - any user modifications need
to be serialised into a suitable format for supplying to the server,
then it needs to develop the equivalent view in the static format
suitable for printing, then it needs to return it - increasing server
load, implementation complexity and bandwidth usage.

As you note the DOM clone is not a method that exists - because of
that, lets forget it, web-applications need to work in IE, we can't
implement that in IE.

> a separate "printable version" page is sufficient.

Such a solution has been regularly rejected in various projects, I
don't think it's likely to happen in the future either, much more
likely that IE only will continue to be required for the applications,
or at least the high-quality printing components of them.

>   ActiveX is commonly used in intranet applications.

Not at all, there's lots over the public web, not to a general public
audience of course, and web technology is very important in the
non-web world, it's also the area that IE still utterly dominates.

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

In a nutshell - Because you can't print it by pressing ctrl-p, and all
the reasons above.

>   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.

What ways?

>   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?

Of course not, you'd just disable script and print...

> What if it's an AJAX
> application and the UI of the app is hidden for printing but never
> restored?

Just the same as happens with things like gmail when the UI disappears
ot locks up or whatever, the user presses refresh and starts again. 
Of course in the real world we also have QA procedures with testers
making sure this sort of stuff doesn't happen, javascript breaks sites
in millions of ways every day, more events don't make it more likely -
they often make it less, as viewer hacks are needed to hit the
required functionality.

In any case, protecting stupid developers is not a good approach to
spec authoring, all you do is harm your intelligent developers, and
your users who lose functionality they want.

Jim.