|
osdir.com mailing list archive |
|
Subject: Re: XML Events - msg#00018List: web.svgHi Sigurd, On Sun, 02 Feb 2003, Sigurd Lerstad wrote: > In my SVG editor/viewer. I'm trying to add XML Events support (skipping > completely how events have been previously done :) Great! > The New draft of SVG1.2 may have more on how this should work in SVG, but > until then I thought I'd check out how it's done in XHTML 2. And there's a > short section about it, but it doesn't say anything that's not already in > the XML Events spec. I think I understand the XML Events spec, but am having > trouble how to relate. Ok. Let me preface this response with a big I MIGHT BE WRONG! (in fact it's more likely that not). If I am, then hopefully a discussion will start. > 1. > > <listener ev:handler="#somehandler" > > how is a XHTML/SVG document supposed to deal with that, what if e.g > > <p id="somehandler"> > > What should happen when listener gets an event, what should it do to the p > element? I believe that is left up to the host language. In this case, the <p> element (I assume it is an HTML <p>) has no way of handling the event so the event just disappears. > 2. > > Is javascript allowed inside the ev:handler attribute? No. Only a URI reference. > 3. > > 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. In SVG, most implementations just load all the code in the script element into a single shared namespace (I'm not sure if that is specified, but that is how it is done). 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). As for the magic "event" variable, it seems that most scripting implementations define a variable called "event" or "evt" to be used in a handler attribute (e.g. onmousedown="docheck(evt)"). To me it is unclear what's supposed to happen here. Anyone have any ideas? Dean Thread at a glance:
Previous Message by Date: click to view message previewRe: 17.2.2 SVG fragment identifiers - continuedOn Mon, 03 Feb 2003, Steve Schafer wrote: > > One other thing: The spec doesn't seem to address duplicate attribute > specifications in an SVG fragment identifier. For example: > > > #svgView(preserveAspectRatio(none);viewBox(0,0,200,200);preserveAspectRatio(xMidYMid)) > > Should this be rejected outright by the user agent? If not, which of the > two preserveAspectRatio specifications should be used? Two good questions Steve. We'll get back to you. Dean Next Message by Date: click to view message previewRe: XML Events"Dean Jackson" <dean@xxxxxx> wrote in message news:20030206120206.GG22050@xxxxxxxxxxxx > > 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. Previous Message by Thread: click to view message previewRe: XML Events> 2. > > Is javascript allowed inside the ev:handler attribute? Disregard this one: I just read... handler = This attribute specifies the ID of a handler element that defines the action that should be performed if the event reaches the observer. -- Sigurd Lerstad Next Message by Thread: click to view message previewRe: XML Events"Dean Jackson" <dean@xxxxxx> wrote in message news:20030206120206.GG22050@xxxxxxxxxxxx > > 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. Loading Comments...
|
|
