Re: Window Modes todo
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 for discussion. Note that this is how it works in IE at the moment. It may be possible to make a change here for DOM L3 events, but we should take care as this would be a substantial change. Do other implementers care to chime in with what they do, and if they'd find this change acceptable? It's certainly somewhat large, but the initFooEvent methods really seem unwieldy to me, and if there's a chance to fix them I think we should. -- Robin Berjon - http://berjon.com/ Feel like hiring me? Go to http://robineko.com/
Re: Window Modes todo
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 called multiple times, at any point when the event is not in the middle of being dispatched. 3) dispatchEvent may be called multiple times, at any point when the event is not in the middle of being dispatched. I believe #2 is a violation of the DOM 2 Events specification; I'm not quite sure why we allow that. I think there were some historical reasons, but they might not be relevant anymore. Olli might know more. The when the event is not in the middle of being dispatched for dispatchEvent is probably technically a violation of that specification too, though it's more likely that the issue was simply not considered during the authoring of the specification. -Boris P.S. I hope I understood the question correctly...
Re: Window Modes todo
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 also
compare this to IE's way of cloning an existing event if you pass one to
document.createEventObject.
However, this is very specific to the dynamic nature and object initializers
in JavaScript. So it's not suitable for this specification.
You could use multiple initializers - one for each section of functionality
or inheritance level.
To me, it doesn't make sense to add all the parameters from initEvent to
initUIEvent. A UIEvent inherits Event, so by definition it already has an
optional initializer (initEvent) that can take all those parameters.
DragEvent is pretty horrible:
initEvent(eventTypeArg, canBubbleArg, cancelableArg);
initUIEvent(typeArg, canBubbleArg, cancelableArg, viewArg, detailArg);
initMouseEvent(typeArg, canBubbleArg, cancelableArg, viewArg, detailArg,
screenXArg, screenYArg, clientXArg, clientYArg, ctrlKeyArg, altKeyArg,
shiftKeyArg, metaKeyArg, buttonArg, relatedTargetArg);
initDragEvent(typeArg, canBubbleArg, cancelableArg, viewArg, detailArg,
screenXArg, screenYArg, clientXArg, clientYArg, ctrlKeyArg, altKeyArg,
shiftKeyArg, metaKeyArg, buttonArg, relatedTargetArg, dataTransferArg);
Each step adds more stuff. It would be more flexible if each one in the
chain was called separately:
initEvent(eventTypeArg, canBubbleArg, cancelableArg);
initUIEvent(viewArg, detailArg);
initMouseEvent(screenXArg, screenYArg, clientXArg, clientYArg, ctrlKeyArg,
altKeyArg, shiftKeyArg, metaKeyArg, buttonArg, relatedTargetArg);
initDragEvent(dataTransferArg);
Implementations can already handle no init or a lower level init method
being called, in which case the higher level variables reverts to defaults.
But all of this is a very substantial change. One that I don't think is
necessary if there isn't a known need to change the lower level Event
interfaces. It might be that those properties need to allow setters anyway.
Sebastian Markbåge
On Mon, Jul 27, 2009 at 3:59 PM, Boris Zbarsky bzbar...@mit.edu wrote:
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 called multiple times, at any point when the
event is not in the middle of being dispatched.
3) dispatchEvent may be called multiple times, at any point when
the event is not in the middle of being dispatched.
I believe #2 is a violation of the DOM 2 Events specification; I'm not
quite sure why we allow that. I think there were some historical reasons,
but they might not be relevant anymore. Olli might know more. The when
the event is not in the middle of being dispatched for dispatchEvent is
probably technically a violation of that specification too, though it's more
likely that the issue was simply not considered during the authoring of the
specification.
-Boris
P.S. I hope I understood the question correctly...
RE: Window Modes todo
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 for discussion. Note that this is how it works in IE at the moment. It may be possible to make a change here for DOM L3 events, but we should take care as this would be a substantial change. -Original Message- From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On Behalf Of Cameron McCormack 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. 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 entirely clear to me that this is not cargo-culting as I can't seem to recall what motivation there is for all of that :) Yeah it doesn’t seem particularly scalable. And what happens when we want to add another attribute on to the Event interface that we want to allow initialisation of? We won’t be able to just insert an argument in the middle of initUIEvent(), initMouseEvent(), etc. 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 for discussion. -- Cameron McCormack ≝ http://mcc.id.au/
Re: Window Modes todo
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 canBubbleArg and cancelableArg be honoured when user script creates and dispatches an event? Even if events created by the implementation are always non-bubbling and non-cancellable. 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. 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 entirely clear to me that this is not cargo-culting as I can't seem to recall what motivation there is for all of that :) -- Robin Berjon - http://berjon.com/ Feel like hiring me? Go to http://robineko.com/
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 that we have all over are all copied and pasted from one another, and it's not entirely clear to me that this is not cargo-culting as I can't seem to recall what motivation there is for all of that :) Yeah it doesn’t seem particularly scalable. And what happens when we want to add another attribute on to the Event interface that we want to allow initialisation of? We won’t be able to just insert an argument in the middle of initUIEvent(), initMouseEvent(), etc. 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 for discussion. -- Cameron McCormack ≝ http://mcc.id.au/
Window Modes todo
Hi, I just went through the WM ED and here are the things to do that I gathered (the list may not be exhaustive). Input and help is welcome, feel free to flag what you'd like to volunteer for. - The Abstract needs to be rewritten, it's not entirely easy to understand what it describes. - The SotD need to be written (in preparation of FPWD). - The active editors need to agree on what they'll use to edit/ generate the spec — I'm guess Anolis/Bert Bos. That'll give us a ToC. - The Relevant Inputs section needs to go. - The Introduction is really only the first paragraph, and it needs to be expanded and have references. The rest are definitions which need their own subsection. - The table of window modes should be moved to the MQ section, and the descriptions merged. This places Conformance Requirements right after the Introduction (which is fine — it should be before anything normative). - A clarification of what is meant by feature would help. The widget mode is also referred to but lacks any description. - The scripting interfaces need some love to make them linked, and make sure they are proper WebIDL (notably they could use the implements keyword). They require a lot of documentation to be written. - I think that the MediaFeatureList could be a sequenceCSSStyleDeclaration nowadays. - 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? - Acknowledgements need to be written. - References need to be written. - Some examples would be nice (but that's not needed for FPWD). -- Robin Berjon - http://berjon.com/ Feel like hiring me? Go to http://robineko.com/
Re: Window Modes todo
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 script creates and dispatches an event? Even if events created by the implementation are always non-bubbling and non-cancellable. -- Cameron McCormack ≝ http://mcc.id.au/
