Re: [DOMCore] fire and dispatch
2. Run getters and define in which order they are retrieved This can get pretty hard to specify (esp. because it involves describing what happens if those getters reenter the API you're defining). Why is that particularly hard? Calling fireEvent (or whatever it will be called) twice on a given event has to be specified. This suppress getters goal seems like a mistake to me, and ES5 itself does not worry about it, even as it both standardizes getters and adds objects-as-keyword-parameter-sets to standard library APIs. See http://www.w3.org/Bugs/Public/show_bug.cgi?id=12248#c2 /be
Re: [DOMCore] fire and dispatch
On Tue, Mar 1, 2011 at 5:06 AM, Anne van Kesteren ann...@opera.com wrote: On Tue, 01 Mar 2011 09:59:59 +0100, Jonas Sicking jo...@sicking.cc wrote: We're also using it in IndexedDB, though I don't think this has gotten into the spec drafts yet. But it is in the firefox implementation and I *think* in the chrome implementation. The issue raised with it last time (by Boris Zbarsky) was the potential for the existence of getters. Maybe we can deal with that via JSON or some such? Though even then I think I would prefer var e = document.createEvent(MouseEvent) e.offsetX = 10 over using an object of some sorts. I'm not quite sure what you mean by via JSON given that JSON is a serialization format. There's several ways of solving the getter problem: 1. Don't allow getters, i.e. if the object contains any getters, throw an exception 2. Run getters and define in which order they are retrieved 3. Treat getters as undefined Any of these solutions work for me. Ideally WebIDL should provide the needed hooks so that things can be defined once and reused in multiple specs. / Jonas
Re: [DOMCore] fire and dispatch
On Wed, 02 Mar 2011 11:52:01 +0100, Jonas Sicking jo...@sicking.cc wrote: I'm not quite sure what you mean by via JSON given that JSON is a serialization format. I thought that maybe there was some kind of concept that tells you whether a given object is JSON-compatible. But yeah, if we decide to introduce objects as first-class API citizens we should have Web IDL define how they work. -- Anne van Kesteren http://annevankesteren.nl/
Re: [DOMCore] fire and dispatch
On 3/2/11 5:52 AM, Jonas Sicking wrote: I'm not quite sure what you mean by via JSON given that JSON is a serialization format. The idea would be to take the input object, sanitize it by doing obj = JSON.parse(JSON.serialize(obj)); (which will get rid of crud like getters), and then work with it. 1. Don't allow getters, i.e. if the object contains any getters, throw an exception This seems like the simplest solution. 2. Run getters and define in which order they are retrieved This can get pretty hard to specify (esp. because it involves describing what happens if those getters reenter the API you're defining). 3. Treat getters as undefined That doesn't seem like a good idea to me, honestly. -Boris
Re: [DOMCore] fire and dispatch
On Thu, Mar 3, 2011 at 1:46 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 3/2/11 5:52 AM, Jonas Sicking wrote: I'm not quite sure what you mean by via JSON given that JSON is a serialization format. The idea would be to take the input object, sanitize it by doing obj = JSON.parse(JSON.serialize(obj)); (which will get rid of crud like getters), and then work with it. 1. Don't allow getters, i.e. if the object contains any getters, throw an exception This seems like the simplest solution. Unless anyone has significant use-cases for getters, we could start with this. I don't expect code to start depending on throwing an exception here, so we change it down the road if we need to. Ojan
Re: [DOMCore] fire and dispatch
On 2/28/11, Anne van Kesteren ann...@opera.com wrote:
On Fri, 25 Feb 2011 18:47:54 +0100, Garrett Smith dhtmlkitc...@gmail.com
wrote:
Your example is simple. But some common cases of synth events are
complicated. UI Events aren't so bad but MouseEvents and especially
TouchEvents are a lot of work to synthesize.
Most cases for synth events are for testing -- feature test or unit test.
EventTarget.fireEvent(type[, options]);
So how is this simpler? Maybe you could illustrate by example instead?
It is simpler than the W3C existing model because it doesn't require
any memorization. This is because each property of `options` is
optional. The entire `options` object is optional. If options is not
an object, then a default options object is created internally.
Some examples where that approach is used are in YUI, which they use
for YUI Test. Another is in TestRunner (I made). Both of these are
unit testing frameworks that can be used to test javascript code
running in a web browser.
YUI is pretty easy to find. The interface of what I made is quite
similar. The idea is that instead of the heavywork of
createEvent(MouseEvent) and then initMouseEvent with 16 args, you
can just:
Mouse.click(document.body, {clientX : 10});
https://github.com/GarrettS/ape-javascript-library/blob/master/src/eventsynth/Mouse.js
No long parameter lists to memorize. And it is extensible in that
future versionso of mouse events can have more options which can be
easily featre tested.
Compare that to:
var mouseEvent = doc.createEvent(MouseEvent);
mouseEvent.initMouseEvent(click, true, true,
doc.defaultView, 1, 0, 0,
10, 0, false, false,
false, false, 1,
null);
document.body.dispatchEvent(mouseEvent);
For me, the first one is memorable but the second way (the standard
way) requires me to memorize too much and is easy to make a mistake
with order of arguments.
The adapter also does some workarounds for browser bugs and for IE's
different model. But regardless, even without the differing model, or
bug workarounds, the default API is unnecessarily complicated. At
least for web scripting. For java, too, I suppose.
Nothing ingenious on my part. Makes perfect sense, really.
--
Garrett
Re: [DOMCore] fire and dispatch
On Tue, 01 Mar 2011 09:00:27 +0100, Garrett Smith dhtmlkitc...@gmail.com
wrote:
Mouse.click(document.body, {clientX : 10});
Yeah, that would be simpler. However, we do not really have this pattern
anywhere in browser APIs and I believe last time we played with objects
(for namespace support querySelector or some such) it was deemed
problematic.
An alternative would be I guess what Simon Pieters proposed some time ago.
That we make event IDL attributes mutable before the event is dispatched.
And that they would get readonly semantics on setting during dispatch
(i.e. based on the dispatch flag).
--
Anne van Kesteren
http://annevankesteren.nl/
Re: [DOMCore] fire and dispatch
On Tue, Mar 1, 2011 at 7:23 PM, Anne van Kesteren ann...@opera.com wrote:
On Tue, 01 Mar 2011 09:00:27 +0100, Garrett Smith dhtmlkitc...@gmail.com
wrote:
Mouse.click(document.body, {clientX : 10});
Yeah, that would be simpler. However, we do not really have this pattern
anywhere in browser APIs and I believe last time we played with objects (for
namespace support querySelector or some such) it was deemed problematic.
The Chromium extension APIs use this pattern and I think it's gone over well
in that space. For example, see chrome.contextMenus.create at
http://code.google.com/chrome/extensions/contextMenus.html. I don't see a
problem with beginning to introduce this into web APIs, but it would be a
departure from existing APIs.
An alternative would be I guess what Simon Pieters proposed some time ago.
That we make event IDL attributes mutable before the event is dispatched.
And that they would get readonly semantics on setting during dispatch (i.e.
based on the dispatch flag).
This seems fine to me too.
Ojan
Re: [DOMCore] fire and dispatch
On Tue, Mar 1, 2011 at 12:48 AM, Ojan Vafai o...@chromium.org wrote:
On Tue, Mar 1, 2011 at 7:23 PM, Anne van Kesteren ann...@opera.com wrote:
On Tue, 01 Mar 2011 09:00:27 +0100, Garrett Smith dhtmlkitc...@gmail.com
wrote:
Mouse.click(document.body, {clientX : 10});
Yeah, that would be simpler. However, we do not really have this pattern
anywhere in browser APIs and I believe last time we played with objects (for
namespace support querySelector or some such) it was deemed problematic.
The Chromium extension APIs use this pattern and I think it's gone over well
in that space. For example,
see chrome.contextMenus.create at http://code.google.com/chrome/extensions/contextMenus.html.
I don't see a problem with beginning to introduce this into web APIs, but it
would be a departure from existing APIs.
We're also using it in IndexedDB, though I don't think this has gotten
into the spec drafts yet. But it is in the firefox implementation and
I *think* in the chrome implementation.
/ Jonas
Re: [DOMCore] fire and dispatch
On Tue, 01 Mar 2011 09:59:59 +0100, Jonas Sicking jo...@sicking.cc wrote: We're also using it in IndexedDB, though I don't think this has gotten into the spec drafts yet. But it is in the firefox implementation and I *think* in the chrome implementation. The issue raised with it last time (by Boris Zbarsky) was the potential for the existence of getters. Maybe we can deal with that via JSON or some such? Though even then I think I would prefer var e = document.createEvent(MouseEvent) e.offsetX = 10 over using an object of some sorts. -- Anne van Kesteren http://annevankesteren.nl/
Re: [DOMCore] fire and dispatch
On 3/1/11 3:48 AM, Ojan Vafai wrote:
Mouse.click(document.body, {clientX : 10});
...
The Chromium extension APIs use this pattern and I think it's gone over
well in that space. For example, see chrome.contextMenus.create at
http://code.google.com/chrome/extensions/contextMenus.html. I don't see
a problem with beginning to introduce this into web APIs, but it would
be a departure from existing APIs.
The big worry here is that you have to be _very_ careful to define
behavior properly. It's not an issue for extension APIs, where you can
assume that the caller will do sane (and probably non-malicious) things.
But for a web API like this you would need to define exactly when and
how many times the UA is supposed to get the clientX property of the
second argument, for example. That's a minimal requirement; there are
probably other ratholes here that would need worrying about. :(
Alternately, we could require that all the properties be plain data
properties or something, to avoid some of those pitfalls.
-Boris
Re: [DOMCore] fire and dispatch
On Tue, Mar 1, 2011 at 8:51 AM, Boris Zbarsky bzbar...@mit.edu wrote: The big worry here is that you have to be _very_ careful to define behavior properly. It's not an issue for extension APIs, where you can assume that the caller will do sane (and probably non-malicious) things. But for a web API like this you would need to define exactly when and how many times the UA is supposed to get the clientX property of the second argument, for example. That's a minimal requirement; there are probably other ratholes here that would need worrying about. :( Alternately, we could require that all the properties be plain data properties or something, to avoid some of those pitfalls. I think the latter sounds like the right way to go. I can't imagine any use-case where you'd need to set anything other than regular old properties on the object (and I say that as someone who uses this pattern a lot in my own code).
Re: [DOMCore] fire and dispatch
On Tue, 1 Mar 2011, Aryeh Gregor wrote: On Tue, Mar 1, 2011 at 8:51 AM, Boris Zbarsky bzbar...@mit.edu wrote: The big worry here is that you have to be _very_ careful to define behavior properly. It's not an issue for extension APIs, where you can assume that the caller will do sane (and probably non-malicious) things. But for a web API like this you would need to define exactly when and how many times the UA is supposed to get the clientX property of the second argument, for example. That's a minimal requirement; there are probably other ratholes here that would need worrying about. :( Alternately, we could require that all the properties be plain data properties or something, to avoid some of those pitfalls. I think the latter sounds like the right way to go. I can't imagine any use-case where you'd need to set anything other than regular old properties on the object (and I say that as someone who uses this pattern a lot in my own code). This is an issue with any of the APIs that use the structured clone algorithm also. Currently it can cause an infinite loop (if there's a getter). If anyone has any advice on how we should fix this problem, please comment on this bug: http://www.w3.org/Bugs/Public/show_bug.cgi?id=12101 My current thinking is to just skip over any properties that have getters. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [DOMCore] fire and dispatch
On Fri, 25 Feb 2011 18:47:54 +0100, Garrett Smith dhtmlkitc...@gmail.com wrote: Your example is simple. But some common cases of synth events are complicated. UI Events aren't so bad but MouseEvents and especially TouchEvents are a lot of work to synthesize. Most cases for synth events are for testing -- feature test or unit test. EventTarget.fireEvent(type[, options]); So how is this simpler? Maybe you could illustrate by example instead? -- Anne van Kesteren http://annevankesteren.nl/
Re: [DOMCore] fire and dispatch
On Fri, 25 Feb 2011 04:05:44 +0100, Garrett Smith dhtmlkitc...@gmail.com wrote: OK. Why not expose a generic version of `fire` to the scripting environment? I do not know of any research (or have done any myself) as to how often such a feature might be useful for authors. While firing an event is currently a series of steps (using proposed optional arguments): var e = document.createEvent(Event) e.initEvent(test) dispatchEvent(e) ... it is not hugely complicated. (We could even make the argument to createEvent optional too and default it to Event.) I could imagine having something like EventTarget.fireEvent(name) but if you want to get a little beyond the basics you will remain stuck with creating the event yourself. -- Anne van Kesteren http://annevankesteren.nl/
Re: [DOMCore] fire and dispatch
On 2/25/11, Anne van Kesteren ann...@opera.com wrote: On Fri, 25 Feb 2011 04:05:44 +0100, Garrett Smith dhtmlkitc...@gmail.com wrote: OK. Why not expose a generic version of `fire` to the scripting environment? I do not know of any research (or have done any myself) as to how often such a feature might be useful for authors. While firing an event is currently a series of steps (using proposed optional arguments): var e = document.createEvent(Event) e.initEvent(test) dispatchEvent(e) ... it is not hugely complicated. (We could even make the argument to createEvent optional too and default it to Event.) I could imagine having something like EventTarget.fireEvent(name) but if you want to get a little beyond the basics you will remain stuck with creating the event yourself. Your example is simple. But some common cases of synth events are complicated. UI Events aren't so bad but MouseEvents and especially TouchEvents are a lot of work to synthesize. Most cases for synth events are for testing -- feature test or unit test. EventTarget.fireEvent(type[, options]); -- Garrett
Re: [DOMCore] fire and dispatch
On , Garrett Smith dhtmlkitc...@gmail.com wrote: On 2/25/11, Anne van Kesteren ann...@opera.com wrote: On Fri, 25 Feb 2011 04:05:44 +0100, Garrett Smith dhtmlkitc...@gmail.com wrote: OK. Why not expose a generic version of `fire` to the scripting environment? I do not know of any research (or have done any myself) as to how often such a feature might be useful for authors. While firing an event is currently a series of steps (using proposed optional arguments): var e = document.createEvent(Event) e.initEvent(test) dispatchEvent(e) ... it is not hugely complicated. (We could even make the argument to createEvent optional too and default it to Event.) I could imagine having something like EventTarget.fireEvent(name) but if you want to get a little beyond the basics you will remain stuck with creating the event yourself. Your example is simple. But some common cases of synth events are complicated. UI Events aren't so bad but MouseEvents and especially TouchEvents are a lot of work to synthesize. Most cases for synth events are for testing -- feature test or unit test. EventTarget.fireEvent(type[, options]); That's going into the Internet Explorer API.
Re: [DOMCore] fire and dispatch
On 2/25/11, João Eiras joao.ei...@gmail.com wrote: On , Garrett Smith dhtmlkitc...@gmail.com wrote: On 2/25/11, Anne van Kesteren ann...@opera.com wrote: On Fri, 25 Feb 2011 04:05:44 +0100, Garrett Smith dhtmlkitc...@gmail.com wrote: [...] Most cases for synth events are for testing -- feature test or unit test. EventTarget.fireEvent(type[, options]); That's going into the Internet Explorer API. Right. Name `fireEvent` would not be feasible. But the idea works. -- Garrett
[DOMCore] fire and dispatch
For DOM Core Ms2ger and I (and some others on IRC) decided to introduce a subtle distinction between fire and dispatch. Dispatching is actually going through the list of event targets with an initialized event whereas firing is initializing the event and then dispatching it. E.g. a specification can say fire an event named x and DOM Core defines that to mean that you create an event of type Event, that all its flags are unset (unless specified otherwise), apart from its trusted flag which is true (when a specification says to dispatch an event it is trusted), that its name is x, etc. and that after you have initialized it in that way it is then dispatched. We chose fire because HTML (and some other specifications, now including XMLHttpRequest and Progress Events) already use it in that way and because the more proper initialize and dispatch was thought to be too long for frequent use. http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html -- Anne van Kesteren http://annevankesteren.nl/
Re: [DOMCore] fire and dispatch
On 2/24/11, Anne van Kesteren ann...@opera.com wrote: For DOM Core Ms2ger and I (and some others on IRC) decided to introduce a subtle distinction between fire and dispatch. Dispatching is actually going through the list of event targets with an initialized event whereas firing is initializing the event and then dispatching it. E.g. a specification can say fire an event named x and DOM Core defines that to mean that you create an event of type Event, that all its flags are unset (unless specified otherwise), apart from its trusted flag which is true (when a specification says to dispatch an event it is trusted), that its name is x, etc. and that after you have initialized it in that way it is then dispatched. OK. Why not expose a generic version of `fire` to the scripting environment? -- Garrett
