W3C home > Mailing lists > Public > www-svg@w3.org > November 2004

SVG 1.2 Comment: Events and Scripting

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Thu, 25 Nov 2004 00:16:44 -0600
Message-ID: <41A578CC.7020701@mit.edu>
To: www-svg@w3.org

16.1:

I'm not quite sure what "Event listeners attached through event attributes and 
handler elements are also evaluated using the global scope of the document in 
which such a listener is defined" means here.  Does that mean that "this" in the 
event listener will be the global object, not the object the listener is 
attached to?

"Removing, inserting or altering script elements once the document has been 
loaded has no effect." -- Why?  This doesn't allow construction of SVG documents 
that include scripts via DOM manipulation, looks like...

As far as I know, the correct MIME type for ECMAScript is 
application/ecmascript, not text/ecmascript.

The requirement that Transfer-Encoding be supported makes it somewhat more 
difficult to use existing off-the-shelf libraries for HTTP support 
(Transfer-Encoding support is very spotty in both servers and clients, last I 
checked, to the point that servers abuse Content-Encoding when they mean 
Transfer-Encoding).

What happens when a script element has both an xlink:href and text content? 
This needs to be specified.

What happens when a script element has no xlink:href and has non-text content 
(eg child elements)?

16.2:

The error handling for the case when some random external document is referred 
to needs to be defined.

Is there a reason "evt" is being used as the event arg name here?  In other 
contexts where I've encountered event listeners getting a magical arg list, the 
arg is named "event".

Again, it looks like this will set up a scope chain for the event listener that 
does not have the node the listener is attached to as "this".

16.3:

The prose for this section needs to be written.  At the moment, it's not clear 
to me what these interfaces do and when one would or could use them.  I would 
like to request that this section of the specification actually be written and 
submitted for public review.  I don't consider it possible to make Last Call 
comments on this section at this time, since the content that should be here 
simply doesn't exist....

16.4:

I'm not sure why this is placing restrictions on what the UA should do with 
events once dispatch to the content has been completed and the event's default 
action has not been prevented.  Surely it should be up to the UA to decide what 
that default action is, whether it's triggering a link or extending the 
selection?  For example, the UA may want to allow extending selections into 
links via a click with a modifier.  I don't see how that can be done in the 
proposed model.

-Boris
Received on Thursday, 25 November 2004 06:28:59 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 07:14:53 UTC