Re: beforeprint event

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

As a user, I'd either expect that the video is removed or that the 
current frame is printed. If I want another one, I can go there.
However, from an author's POV, going to the first or last frame seems 
reasonable. That leads me to two (non-rhetorical) questions: Is 
scripting the best solution to achieve that? Is it enough to justify the 
beforeprint and afterprint event?

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

Adding them to the spec doesn't make already-released browsers 
compatible. At the same time, CSS content /is/ part of a spec, and I 
expect IE8 to support it.

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

Developers find lots of different things useful, like styling scroll 
bars or writing to the status bar. I also don't mind IE supporting it, 
as well as other browsers, but adding it to the spec means that we'll 
never get rid of it, even if it turns out to be useless. I'm thinking 
really long-term here. As we know from another discussion, deprecating 
things in later versions isn't really possible.

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

While this behaviour is perfectly sane, it's not required by any spec. 
You would have to standardize parts of your model, as you need the 
points where beforeprint and afterprint are dispatched. That could be a 
harmful limitation, which wouldn't buy us anything besides beforeprint 
and afterprint.

For example, I can think of a side-by-side view of the live page and the 
print preview. The print preview would update immediately as the page 
changes. Would that work with before/afterprint? Probably, but it 
potentially requires to implement the updating differently from how one 
would do it otherwise, and it could end up being a performance problem. 
Also, somebody wrote he once counted the print attempts with one of the 
said events, which clearly wouldn't work in that case.

--Dao

Received on Monday, 9 April 2007 20:02:04 UTC