- 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>
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 >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? 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. -C
Received on Monday, 9 April 2007 20:23:51 UTC