- From: Sigurd Lerstad <sigler@bredband.no>
- Date: Fri, 7 Feb 2003 16:50:20 +0100
- 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 UTC