Re: beforeprint event

Anne van Kesteren wrote:
>
> 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?

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?

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

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.

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

The xml-stylesheet declaration has a media attribute at least. But I've 
never used XSLT, so I don't know.

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

Dedicated events are also less flexible, which isn't particularly 
useful. The whole Event stuff also belongs to the DOM spec, actually, 
and event properties are not considered harmful there.

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

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?

--Dao

Received on Monday, 9 April 2007 10:41:50 UTC