Re: [1.2T-LC] evt and event (ISSUE-2055)

Hi Krzysztof.

Cameron McCormack:
> > If we are happy keeping the “treat it as if it’s a function” behaviour,
> > then I suggest wording like the following:

Krzysztof Maczyński:
> I really wish treating it otherwise were an option. But for ECMAScript
> handlers are fuctions (cf. also Web IDL WD). So implementations must
> deal with the arguments object and such stuff appropriately. Your
> wording reflects what I wrote because for functions the activation
> and variable objects are the same.

OK.

> Note also that simply wrapping the fragment in whatever has been
> proposed still would allow the author to close the angle bracket, do
> stuff outside the function and then open another one to match that
> appended at the end. It should be a requirement that the handler text
> matches the FunctionBody production.

Good catch, we should say that.  (I notice that HTML 5 says that, too.)

> There is still the problem of interacting with the global scope
> when the authors don't use the var keyword. For this I suggest the
> following:
> --
> function(event) {
>  argumets.callee.scopeLimiter = Function()
>  scopeLimiter.prototype = event.target.ownerDocument.defaultView
>  with (new scopeLimiter()) {
>   delete scopeLimiter
>   // contents of handler
> }}
> --

Nifty.  So yes it would be useful to include that instead of the plain

  function(evt) {
    // contents of handler
  }

thing (though perhaps with “function(){}” instead of “Function()”, to
avoid any (unlikely) problem of the window.Function property having been
overridden).

> > I’m open to leaving out the mention of DontDelete

> For evt and e. I'm for putting it in the code instead of (or in
> addition to) the prose, with no magic. With var as I wrote previously
> if you want DontDelete, with "this." in the body of scopeLimiter
> otherwise.

Yeah.  It looks like Opera makes both ‘evt’ and ‘event’ DontDelete.  (In
Batik they are deleteable, but it doesn’t try to follow the <handler>
rules properly yet so we can discount it.)  I don’t have one of the
mobile players here to test right now, but those that do could test with
this document:

  <svg xmlns='http://www.w3.org/2000/svg'
       xmlns:ev='http://www.w3.org/2001/xml-events'>
    <handler ev:event='load'>
      alert(delete event + '\n' + delete evt);
    </handler>
  </svg>

Interesting also is whether ‘evt’ or ‘event’ being defined on the window
object affects how that property is looked up inside the handler.
Again, just tested with Opera:

  <svg xmlns='http://www.w3.org/2000/svg'
       xmlns:ev='http://www.w3.org/2001/xml-events'
       width='400' height='300' version='1.2'>
    <script>
      var evt = 123;
    </script>
    <handler ev:event='load'>
      alert(evt + ' ' + event);
    </handler>
  </svg>

This alerts "[object Event] [object Event]".  If the variable
declaration is changed to “var event = 123”, then it alerts "123 123".
This behaviour is different from HTML event handler attributes, where
‘event’ (the only name for the event object) cannot be overridden by
properties on the window:

  <!DOCTYPE html>
  <body onload='alert(event)'>
  <script>
    var event = 123;
  </script>

My feeling (and Erik can correct me if I’m wrong) is that there’s not
likely to be a web compatibility problem with going against what Opera’s
doing and making both ‘evt’ and ‘event’ definitely resolve to the event
object rather than properties on the window object, consistent with
HTML.

So something trickier would need to be done than your function above to
avoid getting those properties on the window object.

> > I’d also be happy with leaving out the “Other interpreted languages
> > should behave in a similar manner” sentence.

> Certainly other bindings shouldn't be forced to do the functional
> stuff. But providing evt and e remains a requirement for them. And
> compiled languages as well.

I don’t think it is a requirement, really.  For example with a compiled
language like Java, the interface for EventTarget is just

  interface EventTarget {
    void handleEvent(in EventTarget evt);
  };

but to implement the interface, it isn’t necessary to use that exact
name for the argument.  The necessity of exposing both ‘evt’ and ‘event’
is only for compatibility with content, in my mind, and going forward
(to align with HTML) we should be using ‘event’.  Given that there isn’t
significant content that uses a non-ECMAScript scripting language where
the variable naming would be significant, I think it would be safe to
suggest that for these other languages, just a single variable named
‘event’ is exposed.

-- 
Cameron McCormack ≝ http://mcc.id.au/

Received on Thursday, 2 October 2008 06:08:42 UTC