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 19:18:59 +0100
Message-ID: <033a01c2ced5$626c0f00$591273d5@mmstudio>
To: "Jim Ley" <jim@jibbering.com>, <www-svg@w3.org>

Hello Jim,

So we disagree. But is it so that you don't want support for XML Events at
all?

Are you with the WG?

The SVG 1.2 second draft seems to be around the corner. And the initial
release of my software is also around the corner. I was hoping to have
initial support for XML Events. My point is, there's no point in us
discussing this without the WG taking part. (I don't mean to be impolite :)

--
Sigurd Lerstad

> >>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.
>
> but if that means that the listeners are the simple "return
callfunction()"
> of your original example, then you get a huge amount of verbosity for
little
> gain, and verbosity has repeatedly lost out, authors don't appear to like
> it.
>
> > 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 think the idea that some user which doesn't understand javascript is
going
> to be making those changes in an authoring tool different to the one that
> created it is all a bit pie in the sky, and the marginal benefit of an
> easier to read syntax doesn't help much, given that the implementation is
> more complicated.  (what happens if the DOM changes mid event bubble etc,
> does a mutation event on the DOM fire if the mutation event is removed
etc.)
> XML-events to be seem messy, I don't follow them closely though as I think
> it's a non-problem, and if XHTML 2.0 has a use case that's good, it
doesn't
> mean it's right elsewhere. (XHTML 2.0 is another technology in search of a
> problem AFAICT)
>
> > And it would only lead to confusion if different xml applications use
> > different event systems.
>
> XHTML 2.0 hasn't plumped for a linking mechanism that's the same as other
> "xml applications", so I hardly think following XHTML 2.0 on the grounds
of
> interopability is a good thing.
Received on Thursday, 6 February 2003 12:16:35 GMT

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