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
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
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
, 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.
What concerns me is that all the initFooEvent/NS
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
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
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 user
