- From: Krzysztof Maczyński <1981km@gmail.com>
- Date: Wed, 24 Sep 2008 14:21:02 +0200
- To: "Cameron McCormack" <cam@mcc.id.au>
- Cc: <www-svg@w3.org>
> But is that the browser binding 'e' to the Event object I don't know, I'll assume what Doug wrote. If not, it should be dropped from considerations. > If we are happy keeping the “treat it as if it’s a function” behaviour, > then I suggest wording like the following: I really wish treating it otherwise were an option. But for ECMAScript handlers are fuctions (cf. also Web IDL WD). So implementations must deal with the arguments object and such stuff appropriately. Your wording reflects what I wrote because for functions the activation and variable objects are the same. Note also that simply wrapping the fragment in whatever has been proposed still would allow the author to close the angle bracket, do stuff outside the function and then open another one to match that appended at the end. It should be a requirement that the handler text matches the FunctionBody production. There is still the problem of interacting with the global scope when the authors don't use the var keyword. For this I suggest the following: -- function(event) { argumets.callee.scopeLimiter = Function() scopeLimiter.prototype = event.target.ownerDocument.defaultView with (new scopeLimiter()) { delete scopeLimiter // contents of handler }} -- > I’m open to leaving out the mention of DontDelete For evt and e. I'm for putting it in the code instead of (or in addition to) the prose, with no magic. With var as I wrote previously if you want DontDelete, with "this." in the body of scopeLimiter otherwise. > I’d also be happy with leaving out the “Other interpreted languages > should behave in a similar manner” sentence. Certainly other bindings shouldn't be forced to do the functional stuff. But providing evt and e remains a requirement for them. And compiled languages as well. How about: -- Bindings to other languages SHOULD also provide access to the event object through all three of event, evt and e, mapping the behaviour prescribed for ECMAScript in a manner appropriate for them.
Received on Wednesday, 24 September 2008 12:21:49 UTC