Re: SVGT 1.2: XML events vs. handler attributes

Hello www-svg,

Maciej Stachowiak <mjs@apple.com>  wrote:

> SVG Tiny 1.2 uses XML Events syntax, and does not support the event  
> handler attributes as in SVG 1.1.

That is correct. This is a deliberate decision since onFoo events have a
number of drawbacks which XMl Events solves:

  1) The main reason is that it is extensible. In the onclick style, the
  event names are hardwired into the language. If you add a new event,
  you have to reissue the markup language.

  2) It adds a layer of platform independence: the onclick style can
  only support one scripting language, since you can only have onclick
  attribute. XML Events allows you to support any number of languages.

  3) The onclick style irrevocably intertwines markup and event
  handling. XML Events allows you (though doesn't force you) to separate
  the two out (like the difference between the style attribute and the
  style element).


> Here's an example from the spec:
> 
> <rect x="10" y="20" width="10" height="20" fill="red">
>      <handler type="application/ecmascript" ev:event="ev:click">
>        var myRect = evt.target;
>        var width = myRect.getFloatTrait("width"));
>        myRect.setFloatTrait("width", (width+10));
>      </handler>
> </rect>
> 
> With an onclick handler, and taking advantage of the fact that inline  
> event handlers have the DOM object for the current element in scope,  
> this could be written as:
> 
> <rect x="10" y="20" width="10" height="20" fill="red"
>      onclick="var width = getFloatTrait('width'); setFloatTrait 
> ('width', (width+10));" />
> 
> This is easier to author, more concise, and likely to be more compact  
> in memory at runtime (it saves one element, and one attribute, makes  
> the JS code simpler, and removes the need to store the text contents  
> of the handler for full DOM implementations).

Yes. Its shorter and probably smaller. It also gives a bunch of
problems as we move to a Compound Documents by Inclusion (CDI) model.

How is an SVG widget going to catch an xforms-invalid event in a mixed
SVG+XForms environment? It would have to anticipate all the events that
ever might come along.

>  It seems that for a  
> Tiny spec that is concerned ebough about footprint to leave out text  
> nodes and non-trait attributes on SVG elements, this is needless bloat.

So far the implementor feedback is that this is not very much boat; and
its going to help a lot down the line. Having to rev n specifications
every time one of them adds a new event is a royal pain.

> XML Events do make it easier to do obscure things.

CDI is not that obscure. As a CDI implementor yourself, I find it odd
that you consider it obscure.

>  Like connect Java event handlers,

Right. There are a lot of devices with Java, particularly in the mobile
space. Ineed, JSR 226 and the follow-on JSRs from that rely on this sort
of functionality.

A single handler element pointing to a jar file is a pretty simple way
to build a Java event handler. That just isn't going to happen with a
hardwired, single-language, ECMAScript-only onFoo attribute.

> or connect an event handler to an element far from  
> the element in the document. But these things are already possible  
> using the DOM API.
> 
> What is the reason, therefore, for dropping inline event handler  
> attributes and replacing them with XML Events?

Extensibility, decoupling from changes in other specifications, platform
independence, compound documents, and separation of markup and event
handling if desired.

> I recommend bringing back the inline event handler attributes.

That is not a scalable option, even for standalone SVG, and a non-starter
for CDI.

> I also recommend removing the altered subset of XML Events, since the  
> novel functionality they provide is obscure and could just as well be  
> done through script.

We did. Although, hopefully the functionality will be back in the next
rev of XML Events.

-- 
 Chris Lilley                    mailto:chris@w3.org
 Interaction Domain Leader
 Chair, W3C SVG Working Group
 W3C Graphics Activity Lead
 Co-Chair, W3C Hypertext CG

Received on Tuesday, 25 April 2006 20:08:09 UTC