- From: Matthew Raymond <mattraymond@earthlink.net>
- Date: Mon, 17 Jul 2006 01:07:17 -0400
- 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 onafterprint: 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