Should event and accessKey timing respect preventDefault?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Should event and accessKey timing respect preventDefault?

Brian Birtles
(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).

Generally preventDefault cancels the default action associated with an event.[1]

Certainly, triggering an animation feels like a default action yet my
testing with Opera 10.61, Batik 1.7, Safari 5.0.1 (recent WebKit
nightlies fail to run for me but as of about one month ago, late June,
the result was the same) suggests preventDefault is ignored with
regard to triggering animations to begin or end.

Specifically with the following test case the animation plays when
either the circle is clicked or 'a' is pressed (except in WebKit
browsers which don't seem to support accessKey) despite the fact that
preventDefault is called:

<?xml version="1.0" encoding="UTF-8"?>
<svg xmlns="http://www.w3.org/2000/svg">
  <script type="application/ecmascript">
    function cancel(event) {
      if (typeof event.charCode == 'undefined'
          ? event.keyCode == 97 : event.charCode == 97) {
        event.preventDefault();
      }
    }
    document.addEventListener("keypress", cancel, true);
  </script>
  <circle id="circle" r="25" cx="50" cy="50" fill="brown"
    onclick="evt.preventDefault()">
    <animate begin="circle.click; accessKey(a)"
      attributeName="cx" from="50" to="150" dur="1s"/>
  </circle>
</svg>

I think it would be sensible to define the behaviour for SMIL
Animation so that cancelled events are ignored.

Best regards,

Brian Birtles

[1] http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-flow-cancelation-h3

Reply | Threaded
Open this post in threaded view
|

Re: Should event and accessKey timing respect preventDefault?

Jack Jansen

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, <[hidden email]>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma Goldman




Reply | Threaded
Open this post in threaded view
|

Re: Should event and accessKey timing respect preventDefault?

Patrick Schmitz
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 <[hidden email]>
Sender: [hidden email]
Date: Fri, 27 Aug 2010 09:43:24
To: Brian Birtles<[hidden email]>
Cc: <[hidden email]>; www-svg<[hidden email]>
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, <[hidden email]>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma Goldman




Reply | Threaded
Open this post in threaded view
|

Re: Should event and accessKey timing respect preventDefault?

Rick-2

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, <[hidden email]> 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 <[hidden email]>
Sender: [hidden email]
Date: Fri, 27 Aug 2010 09:43:24
To: Brian Birtles<[hidden email]>
Cc: <[hidden email]>; www-svg<[hidden email]>
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, <[hidden email]>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma Goldman







--
Cheers!
Rick
Reply | Threaded
Open this post in threaded view
|

Re: Should event and accessKey timing respect preventDefault?

Jack Jansen
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, <[hidden email]> 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 <[hidden email]>
> Sender: [hidden email]
> Date: Fri, 27 Aug 2010 09:43:24
> To: Brian Birtles<[hidden email]>
> Cc: <[hidden email]>; www-svg<[hidden email]>
> 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, <[hidden email]>, 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, <[hidden email]>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma Goldman




Reply | Threaded
Open this post in threaded view
|

Re: Should event and accessKey timing respect preventDefault?

Brian Birtles
On 30 August 2010 01:28, Jack Jansen <[hidden email]> wrote:
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.

Thanks Jack for looking into this. Sorry for me delay in following this up.

I think this behaviour needs to be specified.

There seems to be an understanding that clarifications in recent versions of SMIL should be back-ported to SMIL Animation / SVG so perhaps an erratum for SMIL 3 would do the trick. Otherwise, perhaps this could be defined as host-language dependent (again, in an erratum) and then specified in SVG. Personally I prefer the former since SMIL 3 already makes reference to closely-related behaviour such as event bubbling but you'll know best what's the right course.

Thanks again,

Brian Birtles