Re: Should event and accessKey timing respect preventDefault?

Thanks to Rick's clarification I now retract my original analysis: I think Brian's original analysis is correct.

The situation is indeed an event listener calling event.preventDefault() to stop normal processing.

With this new understanding, it would seem most logical that a call to preventDefault() would indeed forestall the event starting the element.

On 28 aug 2010, at 00:27, Rick wrote:

> 
> I'll inject use cases, hopefully for clarity.
> 
> If you intercept an F5 and you don''t want the browser to perform a refresh, you call preventDefault()
> 
> If you intercept a right click and you don't want the browser to pop up a menu, perhaps you want to do it yourself, you call preventDefault()
> 
> I haven't worked with SMIL since I was on the group, I hope to change that soon.  That experience is too foggy for me to give a useful comment.  I hope the use cases help.
> 
> On Fri, Aug 27, 2010 at 11:59 AM, <cogit@ludicrum.org> wrote:
> I think I agree with Jack. IIRC, the behavior Brian describes might be appropriate after a cancelPropagate() call, but not after preventDefault(). Apologies if I have the method names wrong - am citing from memory.
> 
> Patrick
> 
> -----Original Message-----
> From: Jack Jansen <Jack.Jansen@cwi.nl>
> Sender: www-smil-request@w3.org
> Date: Fri, 27 Aug 2010 09:43:24
> To: Brian Birtles<birtles@gmail.com>
> Cc: <www-smil@w3.org>; www-svg<www-svg@w3.org>
> Subject: Re: Should event and accessKey timing respect preventDefault?
> 
> 
> On 27 aug 2010, at 04:37, Brian Birtles wrote:
> 
> > (Cross-posting to www-smil and www-svg since although this is a SMIL
> > issue it is probably recently of more concern to SVG implementers and
> > authors.)
> >
> > Dear all,
> >
> > SMIL as incorporated in SVG allows for animations to be keyed off
> > various DOM events such as mouse clicks (event timing) as well as
> > keyboard inputs (accessKey timing).
> >
> > One area that would benefit from clarification is whether animations
> > should be triggered when preventDefault is called on the event in
> > question (and presuming that event is cancelable).
> 
> 
> I haven't looked closely at preventDefault (up until 2 minutes ago:-), but my impression is that it it should the opposite from what you suggest.
> You seem to suggest
>    someone calls event->preventDefault(), therefore the default action for the event on its target node doesn't happen.
> 
> My understanding is
>  if the event comes in, and the target node decides not to take the default action for some reason, then it should also call event->preventDefault().
> 
> If my understanding is correct then I think there is no issue. Otherwise, could you point me to some references?
> --
> Jack Jansen, <Jack.Jansen@cwi.nl>, http://www.cwi.nl/~jack
> If I can't dance I don't want to be part of your revolution -- Emma Goldman
> 
> 
> 
> 
> 
> 
> 
> -- 
> Cheers!
> Rick

--
Jack Jansen, <Jack.Jansen@cwi.nl>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma Goldman

Received on Sunday, 29 August 2010 16:29:40 UTC