Re: beforeprint event

On Mon, 09 Apr 2007 11:39:41 +0200, Dao Gottwald <dao@design-noir.de>  
wrote:
>> Implementing events like that should be pretty trivial and allows  
>> authors to innovate themselves without having to wait for browser  
>> vendors to implement everything they might ever want in CSS.
>
> Yeah, but it are only edge cases where you would need more complex CSS  
> than we have today. And those cases will fade away; it's not like  
> "everything they might ever want in CSS" is an infinite list.

How do you know all the potential use cases people might think of?


> Besides, are beforeprint and afterprint even supported by browsers  
> besides IE?

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.


>> The use cases might be catered for by something like XBL
>
> And XSLT.

XSLT can not be applied based on a media type if I remember correctly.


>> , but I don't seen anything inherently harmful in supporting events  
>> that indicate the transition between presentation media.
>
> Maybe a "mediachange" event, but "beforeprint" and "afterprint" sound  
> like a hack.

Having dedicated events rather than a generic event is far more useful  
when writing scripts. Otherwise you have to check some silly attribute  
name you can't remember every time the event is invoked. (Also, lots of  
things that just work sound like a hack. XMLHttpRequest for instance.)


> It's not even clear to me how they work. Is there a copy of the document  
> or would scripted transformations affect the real page as well as the  
> print preview? The former seems unlikely (otherwise, why do we need  
> "afterprint"?) and latter would be a design flaw.

Why would it be a design flaw? These are events, not presentation  
properties.


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>

Received on Monday, 9 April 2007 09:53:51 UTC