W3C home > Mailing lists > Public > public-webapi@w3.org > July 2006

Re: printing events and web applications

From: Matthew Raymond <mattraymond@earthlink.net>
Date: Mon, 17 Jul 2006 01:07:17 -0400
Message-ID: <44BB1B05.1000507@earthlink.net>
To: Lachlan Hunt <lachlan.hunt@lachy.id.au>, public-webapi@w3.org
CC: Dave Raggett <dsr@w3.org>

Lachlan Hunt wrote:
> Dave Raggett wrote:
>> Internet Explorer provides two events that are very useful
>> for web applications involving dynamic html when it comes to
>> printing. These are onbeforeprint and onafterprint.
>> As an example, consider HTML Slidy
>>     http://www.w3.org/Talks/Tools/Slidy
>> Slidy uses CSS for layout and a linked script to present div elements as 
>> slides, one slide at time. The other slides are
>> hidden by setting the div element's display property to none and 
>> visibility to hidden.
>> This looks great for presentation purposes, but if the user tries
>> to print the page then the browser will only print the currently
>> visible slide. Most of the time, that isn't what people expect.
>> Instead they want to have all of the slides printed.
> This use case is more easily handled using a print stylesheet.

   Agreed. For example, it's only poor implementation of print-related
properties that prevents authors from using CSS to print each slide on a
separate page, and even if it weren't possible with a fully
CSS-compliant user agent, it would make more sense to handle that
problem via a new CSS Print spec than a batch of new elements.

   So far, I've only heard three real use cases for onbeforeprint and

1) As a form of level-of-detail control. The idea is that perhaps you
have low res images for the screen media type and high res images for
the print media type. The problem with this is that I'm pretty sure that
the work by the www-style group on content replacement makes it possible
for CSS to do this.

2) As a primitive DRM mechanism. You would either use scripting as a way
to prevent the user from discovering the URL of image files by looking
at HTML or CSS source files, or you use the events to prevent printing
all together ("You must join our premium user club to print this page").
Not only is this incredibly hostile to the user, but it doesn't prevent
printing of the page via copy-paste to word processing software or
through a hacked user agent. Furthermore, the "printable version"
workaround is perfectly fine in most situations.

3) As a way of supporting user agents that don't support CSS. While, in
theory, this might seem like a reasonable use case, ask yourself this:
What kind of user agent allows printing, print-related events and
Javascript execution but doesn't support even the most basic CSS
properties and media types? I would submit that this is such a limited
use case that you normally wouldn't bother to print documents via such a
user agent in the first place.

   Another problem is that the user may sometimes wish to simply print a
small section of the document, such as a paragraph of highlighted text.
Why would you need to have code execute that modifies the DOM just to
print what probably amounts to a text node?!?

   In summary, onbeforeprint and onafterprint have no use cases that
truly justify their implementation and can be used for some very
user-hostile purposes which I'd personally categorize as "evil". They
were created primarily to give authors a way to work around a poor
implementation of CSS and to give them a higher degree of control over
clueless employees on a corporate intranet. I strongly advocate that
these events be rejected for inclusion in any future W3C standard.
Received on Monday, 17 July 2006 05:07:21 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:16:21 UTC