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

Re: XML Events

From: Sigurd Lerstad <sigler@bredband.no>
Date: Fri, 7 Feb 2003 16:50:20 +0100
Message-ID: <030e01c2cec0$9e3ebe70$591273d5@mmstudio>
To: "Jim Ley" <jim@jibbering.com>, <www-svg@w3.org>

>
> "Sigurd Lerstad" <sigler@bredband.no>=>
> >A Declarative syntax to the 'addEventListener' DOM method is preferred
for
> >the same reason that declarative animation is preferred over doing all
your
> >animation with scripting.
>
> I don't agree with that statement, declaritive animation is sensible,
since
> everything can be defined in the XML, with xml-events, all you're doing is
> xml-ifying a tiny fraction of the script event handling, which to my mind,
> gives us nothing, and increases the content/script confusion.  In the non
> xml-events method I can go
>
> <script xlink:href="script.js"/>
>
> as the sole way of attaching events, and the associated script, with
> xml-events I don't have that option, and content is less seperated.

Okay, you have a point. But:

The way I see it: Scripting is composed of two things. The actual code that
does the real work, and the listeners that connect elements to the code
through events. And I think we have much to gain by having the second part
in xml syntax. Consider An authoring tool that allows you to attach event
listeners to elements, and it does that by generating JavaScript code. Now
open this document in another authoring tool, the authoring tool (and the
user) have no idea about listeners and events. The user needs to go into the
JavaScript code and look. And lets also say that the user wants to change an
event 'mousedown' to 'click', he'll need to go into the JavaScript and
change, instead of having a lot more appealing/understandable user-interface
to do it in.

I definitely think that declarative syntax for this is preferred.

> >> My point was that it's unproven both in user acceptance, and in
> >> implementation, and as there is already a well established alternative,
> >> staying with that has a great many attractions.
> >
> >You have to take the step sometime. And now seems like the perfect time,
> >since XHTML2 will probably support XML Events exclusively.
>
> If you know that SVG 1.2 will not contain the normal event syntax, then
you
> know more than me, and perhaps you shouldn't be discussing it in public,
but
> I don't believe that to be the case, I think at most there will be the
> choice of methods.

I don't know anything. It just seems that XHTML2 will only contain XML
Events. And since they don't claim to be backwards compatible they can do
that. And why do they do it? certainly because they think the old event
system should be replaced by something better.

And it would only lead to confusion if different xml applications use
different event systems. That's why I hope SVG1.2 also will support XML
Events. If it also supports the old way, that's okay. I wouldn't implement
the old way though, because that would eventually disappear (old ways always
do)

--
Sigurd Lerstad
Received on Thursday, 6 February 2003 09:47:50 GMT

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