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

Re: beforeprint event

From: Andy Hume <andyhume@thedredge.org>
Date: Mon, 9 Apr 2007 23:46:58 +0100
Message-Id: <33ECF130-C91B-4A28-9E2A-3ABCD224D4FA@thedredge.org>
Cc: "Dao Gottwald" <dao@design-noir.de>, "Matthew Raymond" <mattraymond@earthlink.net>, "Chris Wilson" <Chris.Wilson@microsoft.com>, "public-html@w3.org" <public-html@w3.org>
To: Anne van Kesteren <annevk@opera.com>

On 9 Apr 2007, at 10:53, 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?

In my experience, UX designers tend to want to change the state of an  
application onprint, rather than simply it's presentation. Often this  
is to match what might be provided by a link to a 'print friendly'  
page. Whether this is a good idea or not is out of scope of this  
discussion, but often it simply can't be achieved by a change in CSS.  
I don't see the harm in providing generic 'mediachange' events.
>>> , 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.)

I disagree Anne, as I can also imagine use cases where you would want  
to script changes for other media types. The flexibility the generic  
event provides might be the solution in terms of simplicity and  
scalability. In my experience it would certainly empower developers  
to more easily solve some of the requirements of application designers.

Andy H.

>> 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 Tuesday, 10 April 2007 06:22:40 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:18 UTC