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:

>=20
> I'll inject use cases, hopefully for clarity.
>=20
> If you intercept an F5 and you don''t want the browser to perform a =
refresh, you call preventDefault()
>=20
> 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()
>=20
> 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.
>=20
> On Fri, Aug 27, 2010 at 11:59 AM, <[email protected]> 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.
>=20
> Patrick
>=20
> -----Original Message-----
> From: Jack Jansen <[email protected]>
> Sender: [email protected]
> Date: Fri, 27 Aug 2010 09:43:24
> To: Brian Birtles<[email protected]>
> Cc: <[email protected]>; www-svg<[email protected]>
> Subject: Re: Should event and accessKey timing respect preventDefault?
>=20
>=20
> On 27 aug 2010, at 04:37, Brian Birtles wrote:
>=20
> > (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).
>=20
>=20
> 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.
>=20
> 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().
>=20
> If my understanding is correct then I think there is no issue. =
Otherwise, could you point me to some references?
> --
> Jack Jansen, <[email protected]>, http://www.cwi.nl/~jack
> If I can't dance I don't want to be part of your revolution -- Emma =
Goldman
>=20
>=20
>=20
>=20
>=20
>=20
>=20
> --=20
> Cheers!
> Rick

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