Hi Robin, All,
I have addressed the below issues in the latest version of the draft.
I did cargo-culting wrt the events to adhere to DOM3Events. I assume the
decisions about dropping initializations, modifications etc. should be taken
jointly with the parties interested in that specification (sp
For the JS framework MooTools, I'm currently implementing a model where you
can pass an object to an event constructor: new Event({ foo: 'bar', foo2:
'bar' });
Any uninitialized properties would fall back to defaults. This would be
comparable to named parameters found in many languages. You could a
Robin Berjon wrote:
Do other implementers care to chime in with what they do, and if they'd
find this change acceptable?
As I recall Gecko's behavior, it works more or less like this:
1) Properties listed as readonly in the DOM 2 Events IDL are in
fact readonly.
2) init*Event may be call
On Jul 27, 2009, at 05:37 , Travis Leithead wrote:
Adding WWW-DOM to widen the audience a bit.
Having the attributes not be read only and allowing their
modification before the Event is dispatched seems better to me.
But changing this for DOM Events in general seems like a larger
issue fo
ack
Sent: Thursday, July 16, 2009 7:03 PM
To: Robin Berjon
Cc: public-webapps@w3.org
Subject: Re: Window Modes todo
Robin Berjon:
> To be honest, I'm not entirely certain of the value in enabling user
> script creation of these events — but I guess that's another matter.
Sure.
Robin Berjon:
> To be honest, I'm not entirely certain of the value in enabling user
> script creation of these events — but I guess that's another matter.
Sure.
> What concerns me is that all the initFooEvent/NS that we have all over
> are all copied and pasted from one another, and it's not
On Jul 16, 2009, at 04:46 , Cameron McCormack wrote:
Robin Berjon:
- I forget the original reasoning: is it useful that the event
initialisers have canBubbleArg and cancelableArg since presumably no
matter what parameter is passed they won't bubble and won't be
cancellable?
Shouldn’t canBubbl
Robin Berjon:
> - I forget the original reasoning: is it useful that the event
> initialisers have canBubbleArg and cancelableArg since presumably no
> matter what parameter is passed they won't bubble and won't be
> cancellable?
Shouldn’t canBubbleArg and cancelableArg be honoured when us
