- From: Andy Hume <andyhume@thedredge.org>
- Date: Mon, 9 Apr 2007 23:46:58 +0100
- To: Anne van Kesteren <annevk@opera.com>
- 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>
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