RE: beforeprint event

Dao Gottwald [mailto:dao@design-noir.de] wrote:
>Anne van Kesteren wrote:
>> How do you know all the potential use cases people might think of?
>
>I don't know them, but I just think the list of transformations for
>printing can't be too long. You change colors and fonts; hide, show,
>rearrange things. What else? More precisely: What else that can't be
>done with CSS?

One example - for an embedded video, you might want to seek the video to a particular spot before rendering to a print device.

>> I don't know, does it matter? Internet Explorer probably has to
>> support them forever so it makes sense to just reuse those. Developers
>> also requested these events on the WHATWG list.
>
>It matters because if current browsers are not compatible, that's not
>less a problem than IE not being capable of the CSS "content" property,
>for example.

Well, then I'd suggest adding them to the HTML spec.  They're commonly used in IE-specific content, developers have found them useful, and I don't think IE has any intention of removing them.  I'm not going to argue for them, though.  :)

>The script shouldn't mess around with the browsable view when it's the
>goal to get a print preview. Printing isn't necessarily a synchronous
>task; why shouldn't you be able to open a print preview and go back to
>the page?

Let me explain - when IE is asked to print a page, it persists (at that point in time) the current state of the page out to a file, then reloads that file as a separate document in "print mode" - which, among other things, does not run script or (most) ActiveX controls, and is not interactive (hence why you can't click on links in print preview).  The persist-for-printing step is also a little special - in terms of ActiveX controls, particularly, as it generally persists them out by asking them to render to a Windows metafile (series of GDI calls, essentially) and then just replays that metafile when it actually goes to the printer (or screen, in print preview).

The point, from a user perspective, is that when you hit print you want to print what the page looks like at that time (in terms of structure and visibility - of course, we will relayout for the printed page characteristics, etc.).  If you've done DOM manipulations to the page, you want those to have taken effect in what you print (otherwise, printing an Ajax page wouldn't work very well), so you can't just say "print the page that is at this remote URL."

The only reason you can't go back to the current page with a print preview open is a pure UI choice on our part (we made print preview modal, so as not to confuse users).  I can't remember, actually, if we fire the "onafterprint" event immediately after we persist the print file, or if we wait until the print call returns.  I think it's the former.

At any rate, I still think the events have merit, but I'm going to bow out of this discussion now.

-C

Received on Monday, 9 April 2007 16:09:11 UTC