W3C home > Mailing lists > Public > www-svg@w3.org > September 2008

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

From: Cameron McCormack <cam@mcc.id.au>
Date: Wed, 24 Sep 2008 11:41:20 +1000
To: Doug Schepers <schepers@w3.org>
Cc: Krzysztof Maczyński <1981km@gmail.com>, www-svg@w3.org
Message-ID: <20080924014120.GA1608@arc.mcc.id.au>

Hi Doug and Krzysztof.

(This is somewhat related to ACTION-2174, too.)

Doug Schepers:
> Thanks for your comment.  This is something I'd like to see resolved,
> too, as it may cause problems for authors who are mixing SVG with HTML.
> 
> Note that there is quite a lot of SVG content that uses 'evt', so we do
> need to find a solution that fits legacy content, too.

Yes, we need to keep both 'evt' and 'event' working.  Batik doesn’t do
the “treat the contents of the <handler> as if it were a function”
thing.  It just evaluates the contents of the <handler> at the top
level, which results in variable declarations causing properties to be
added to the window object (which probably isn’t a good thing).  It also
just binds 'evt' and 'event' on the global object, clobbering any
property that was there.  For example with the following document:

  <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>
    <rect width='100' height='100'>
      <handler ev:event='click'>
        alert(evt);
        setTimeout(function() { alert(window.evt) }, 1);
      </handler>
    </rect>
  </svg>

Both alerts show that evt is bound to the Event object.

As Erik pointed out in a telcon recently, Opera doesn’t strictly treat
the contents of a <handler> as a function either, but there is some
scoping going on such that variables don’t get put on the window object.

Note also that HTML 5 says that the contents of an event handler
attribute (@onclick, etc.) are treated as the body of an anonymous
function with a single parameter named 'event'.

> The parameter 'e' as an alias for 'event' is also used quite a lot in
> script content on the Web, so maybe that might be relevant as well.

But is that the browser binding 'e' to the Event object, or just authors
tending to use 'e' as the name of the parameter when passing a function
to addEventListener()?  If it is the latter, then we needn’t worry about
it.

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

  In the ECMAScript language binding, the event listener that is
  registered due to a <handler> element is an anonymous function whose
  body is the text content of the <handler> element (as if retrieved
  using the textContent attribute on the Element).  The function must
  have a single parameter named "event", which will be bound to the
  Event object when the event listener is fired.  For example, in the
  following document:

    <svg xmlns="http://www.w3.org/2000/svg"
         xmlns:ev="http://www.w3.org/2001/xml-events"
         version="1.2" baseProfile="tiny">
      <rect width="100" height="100">
        <handler ev:event="click">
          // contents of handler
        </handler>
      </rect>
    </svg>

  the anonymous function acting as the event listener is as follows:

    function(event) {
      // contents of handler
    }

  When the function is invoked, the this value must be the target of the
  event.

  In addition, for compatibility with existing user agents and content,
  the Event object must also be bound to the name "evt" within this
  anonymous function.  This can be achieved by creating a property with
  the name "evt" and property attributes { DontDelete } on the
  function's variable object ([ECMA-262], section 10) just before
  control is passed to the function.

I’m open to leaving out the mention of DontDelete ({ DontDelete } being
the attributes of the 'event' property created because it’s the function
argument).

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

-- 
Cameron McCormack ≝ http://mcc.id.au/
Received on Wednesday, 24 September 2008 01:42:07 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:40 GMT