W3C home > Mailing lists > Public > www-svg@w3.org > February 2003

Re: XML Events

From: Jim Ley <jim@jibbering.com>
Date: Thu, 6 Feb 2003 12:33:59 -0000
To: www-svg@w3.org
Message-ID: <b1tkjt$ofl$1@main.gmane.org>


"Dean Jackson" <dean@w3.org> wrote in message
news:20030206120206.GG22050@grorg.org...

> > In this example from the XML Events spec:
> > <script type="application/x-javascript"
> >         ev:event="submit" ev:observer="form1">
> >    return docheck(event);
> > </script>
> >
> > where is the event variable inside docheck coming from, is this a global
> > object fetched from the global 'window' object, or is an object named
> > 'event' always passed in?
>
> Welcome to the big mess that is scripting.

Hey, stop firing back...  :-)

> So, in this case the above example doesn't really make
> sense (since there is no enclosing function, and no way
> to enter the code at that point). (Again, it's likely that
> I'm wrong here).

Ah, my interpretation of the above, is that when the script language is
javascript there is a function, the function being an anonymous one defined
by the script element.

so whereas in SVG 1.0 we have

<svg onload="return docheck()" >

with xml events we can have

<svg id="chicken">
<!-- 3000 lines of SVG markup -->
<script type="application/x-javascript" ev:event="load"
   ev:observer="chicken">
return docheck()
</script>

Which is obviously a lot clearer, simpler and more flexible...

They both have the result that an anonymous function is called on the load
event of the svg element, the XML one does have the advantage that you can
attach more than one event easily, but then this is trivial in script, and
is hardly difficult in the first syntax, even when generating code.

Despite Internet Explorer has allowed a similar syntax for even handling in
HTML for many versions:

<script type="text/javascript" for="chicken" event="onload">
return check()
</script>

I've seen virtually no-one have the need to use it, other than where binding
to ActiveX Object events are concerned where it's the only defined method.

> Anyone have any ideas?

Stick with the current, widely implemented, well understood methods until
the new technology has proved itself superior.

Jim.
Received on Thursday, 6 February 2003 07:34:02 GMT

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