W3C home > Mailing lists > Public > public-html@w3.org > April 2007

RE: beforeprint event

From: Chris Wilson <Chris.Wilson@microsoft.com>
Date: Mon, 9 Apr 2007 13:23:39 -0700
To: Dao Gottwald <dao@design-noir.de>
CC: Anne van Kesteren <annevk@opera.com>, Matthew Raymond <mattraymond@earthlink.net>, "public-html@w3.org" <public-html@w3.org>
Message-ID: <5C276AFCCD083E4F94BD5C2DA883F05A27D6D61C11@tk5-exmlt-w600.wingroup.windeploy.ntdev.microsoft.com>
Dao Gottwald [mailto:dao@design-noir.de] wrote:
>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

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

In short, yes, because it may not be video - it may be some other control.

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

I never said it did, nor did I mean to imply that I think this replace media-specific stylesheets.  However, I'd point out that IE has supported media-specific stylesheets since IE4, and yet I see far fewer of them than I see onbeforeprint in the wild.  You can claim that's because of IE's limited CSS support, but I don't think that's the case.

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

Umm, okay.

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

I don't think that's such a big problem, but again, I'm not fighting for these particularly.  We think they're a useful tool, and don't hit the same scenarios as CSS media (which we also believe in).

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

I'm not sure what the behavior of that would be.  There are a lot of problems with live content in print preview - like how you return offsets and widths/heights in a paginated mode.


Received on Monday, 9 April 2007 20:23:51 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:44:08 UTC