Re: [1.2T-LC] evt and event (ISSUE-2055, ACTION-2303)

Hi, Doug & WG!

>> Could you please review the changes
>> we've made as a result of your comment, and respond to the email,
>> letting us know whether or not you are satisfied?
In general, I'm not satisfied because little has been addressed by those changes and a few problems pointed out by me and others remain. Let me make my statement in points.

1. If evt is just for compatibility with existing content and only for ECMAScript, whereas for other bindinds the only recommended name is event, the Java binding handleEvent's argument list should reflect that. Although "to implement the interface, it isn’t necessary to use that exact
name for the argument" (as Cameron wrote), it sometimes matters, e.g. when reflection is used or handleEvent's body is generated.

2. If evt is just for compatibility with existing content, could it be called obsolete (an informal term) in 1.2 and possibly deprecated formally in 2.0?

3. What about e? Got out of radar somehow. Did you determine that it's just a name often used by authors in places they can choose it (declared parameter, regular variable, or whatever), not provided as predefined by user agents?

4. I think talking about window should be avoided. Window Object 1.0, despite being crucially important, is frozen in an early WD. The HTML WG may assume it will have been finished before their CR so they feel free to mention it (actually, they keep it in their monstrual spec at the moment). It's not the case with SVG. In ECMAScript there is the global object which occurs to me as the preferable term.

5.
> though perhaps with “function(){}” instead of “Function()”, to
> avoid any (unlikely) problem of the window.Function property having been
> overridden
Good catch indeed! The ECMAScript spec itself is known to have issues like this. ;) You'll find a corrected version below.

6. It's been mentioned in some messages that variables created (even without var) from a handler element's script should not pollute the global scope. (Why? Is it current implemetations' behaviour? Are there any other arguments in favour of it?) I assume that you nevertheless do want instant (i.e. not using this) access to its preexisting properties. Then the following solution comes to my mind:
function(event) {
 var evt = event
 arguments.scopeLimiter = function() {}
 arguments.scopeLimiter.prototype = event.target.ownerDocument.defaultView
 with (new arguments.scopeLimiter()) {
  delete arguments.scopeLimiter
  // contents of handler
}}
It features three changes from my previous proposal, the other two being the inclusion of evt and using arguments instead of arguments.callee as a hook throughout (this was actually my mistake - there seems to be no way to create a local variable without DontDelete). If the author does foo = bar (and no foo on the global object at the moment), it'll be about to perish with the ephemerical by design object constructed with scopeLimiter.

7. I don't really understand why the this keyword was mentioned at all. It's always the global object in our scenario.

8. The requirement that the script matches the FunctionBody production still isn't there.

9. If Batik and Opera don't treat the script as function body, what do they actually do and is it actually specifiable without too much magic described in prose? I know implementing the behaviour for arguments (especially arguments.callee) may be troublesome (if this is really a problem, arguments = undefined (much easier to support) could be inserted in the above instead of delete arguments.scopeLimiter) but what's the alternative of having a function (as HTML5 is going to have)? You could replace "function(event)" with "with ({})". This would have two disadvantages. Firstly, functions are the only callable native objects, so nothing else can be said to have the event value supplied without describing it in prose (note that my proposal involves no magic and only very straightforward prose). Secondly, per ECMAScript spec, it would be tantamount to calling Object which might have been redefined. (This could be alleviated with "with ((function() {return arguments.constructor()})())".) Note also that calling arguments.callee is possible with the current editor's draft.

10. I'd like the sentence "Likewise, bindings to other languages SHOULD provide access to the event object under the name "event" (excluding evt), mapping the behaviour prescribed for ECMAScript in a manner appropriate for them." to be kept for uniformity.

11. Cameron, I can't figure out what you mean in the following. event and evt having the event object as their value are to be accessible from within handlers only, and the possibility of the global object having properties with the same names seems completely independent to me (they'll be shadowed when a handler is called).
> My feeling (and Erik can correct me if I’m wrong) is that there’s not
> likely to be a web compatibility problem with going against what Opera’s
> doing and making both ‘evt’ and ‘event’ definitely resolve to the event
> object rather than properties on the window object, consistent with
> HTML.
>
> So something trickier would need to be done than your function above to
> avoid getting those properties on the window object.

12. Erik, do I correctly understand your mention of "separate scope" that  handlers run independently of the browsing context, in one-time ECMAScript execution contexts created at each invocation, but just happen to hook into the same DOM tree via event? This would disable access to document-wide helper functions, XMLHttpRequest (when it's a Rec) and much other stuff. Besides, I think the DOM event model assumes one execution context. handler elements should not deviate from it because that would be an obstacle in SVG 2.0 where approaches tried so far are going to be reconcilled as much as possible. Unless I'm wrong.
I've found this specified explicitly:
> Event listeners attached through event attributes and 'handler' elements are also evaluated using the global scope of the document in which they are defined. 

13. I don't take a position on whether anything else should be added to the scope chain (like the document) at this moment. However, I'm for coordinating on this with the HTML WG. What are their reasons for this? By the way, isn't there going to be a W3C spec on scripts, handlers, etc., applicable to any browsable XML document type (and HTML5 with adapting prose in its spec)?

14. (You may advise me in private.) Would it be prudent to post a link to this message to www-html@w3.org and public-xhtml2@w3.org?

15. I see you're going to add parts of Window Object 1.0 to SVG 1.2. Since it'd be the first Rec to have these features, this is the right time to ask: have you considered (per provision in 15.1 of ECMA-262) putting the AbstractView interface on the global object's prototype instead?

16. Script execution and modification of the document while it's still being parsed looks like a pandora's box and in the early days of XHTML this idea was considered so terrible that it was rejected as a rule of thumb for the XML world. I suspect the current HTML WG of successful lobbying for it. May be even useful (especially for some unruly existing content), but I'm not going to leave it without questions. What DOM does the script operate on? (I suppose it's the last node in the document, as if its closing tag were followed by closing tags of its ancestors, but please state it explicitly in the spec.) What happens when parsing has to resume in a very different document (the script may have appended something after itself, deleted itself or its ancestor (the document element being the worst case), done both)?

17.
> The SVG uDOM only allows navigation of the element nodes in the DOM tree.
Not true. The document node is also navigable.

I can provide more wordings (prose, not only code ;-)) if you wish, even edit the chapter.

Received on Sunday, 2 November 2008 00:30:55 UTC