Re: DOM3EV: Editorial comments
On Apr 20, 2006, at 01:57, Cameron McCormack wrote: If an implementation of the interface does not have the handleEvent method, then I don't think it's an implementation of that interface. If on* attributes and ES Function objects are mapped to EventListener objects behind the scenes (even just conceptually) then it would be OK just to refer to the EventListener interface here. It's the other way around in fact, the EventListener is mapped to Function (and currently, not give a handleEvent member, though I think it would be better to have one pointing back to the object itself, for compatibility with at least ASV and possibly other SVG UAs). -- Robin Berjon Senior Research Scientist Expway, http://expway.com/
Re: DOM3EV: Editorial comments
Robin Berjon: It's the other way around in fact, the EventListener is mapped to Function Surely mapping things to an EventListener interface, which is meant to be language independent construct, is more sensible than mapping everything to ES Function objects, something that is language specific. This also wouldn't scale to any interface that requires more than one method to be implemented on it. (and currently, not give a handleEvent member, though I think it would be better to have one pointing back to the object itself, for compatibility with at least ASV and possibly other SVG UAs). So that it actually implements EventListener? :) -- Cameron McCormack ICQ: 26955922 cam (at) mcc.id.au MSN: cam (at) mcc.id.au http://mcc.id.au/ JBR: heycam (at) jabber.org
Re: DOM3EV: Editorial comments
Hi Cam, thanks a lot for these comments. On Apr 16, 2006, at 15:19, Cameron McCormack wrote: In 1.5 it says All events defined in this specification are in no namespace. and in 1.5.2 All event types are in no namespace and this specification refers to them by their local name only. Is it the events or the event types that are in namespaces? The events, the types are the local names. Used to specify the time at which the event was created in milliseconds relative to 1970-01-01T00:00:00Z. Due to the fact that some systems may not provide this information the value of timeStamp may be not available for all events. Does 1970-01-01T00:00:00Z use a common enough time format to warrant not mentioning how it should be parsed (by readers)? Are leap seconds included in this offset? Z always has leap seconds, no? The DOMFocusIn and DOMFocusOut event types are listed as being within the XML Events namespace, but they should be in no namespace. Yes, that's been fixed in the internal draft already, thanks. Should the descriptions for clientX and clientY mention that they are coordinates relative to the visual display being presented by the view given in the view attribute? I think they should yes. [getModifierState] I think it would be helpful for the description of this method to list all of the modifier keys that are listed in Appendix A, and also that others may be used for other modifiers. Is that really better than referring to App A? Lists that are copied over tend to go out of sync. There should also be a way to get a list of all of the modifiers that are in effect, so that applications can make use of modifiers that aren't listed in Appendix A. Applications can already make use of any modifier not listed by the specification. I don't feel very strongly about this but I'm not sure what the value would be of having a way to list all modifiers that are in effect. All you could do with it is get a list of modifiers which you know about and therefore could also query, and of modifiers which you didn't know existed, and therefore can't do anything with. With initMouseEventNS, what happens if a key that is not a modifier is given in the modifiersList argument, such as Tab? What if it specifies a key that the implementation does not know about? I would think that a key that isn't a known modifier counts as an unknown modifier (I don't see it being interpreted as a key), and any random string that does not contain a space is currently considered to be a valid modifier. I would expect the resulting event to carry around that unknown modifier and expose it through getModifierState(). * 1.8.5 Mutation and mutation name event types Are the DOMElementNameChanged and DOMAttributeNameChanged events fired if the renameNode just fell back to removing the node and adding a new one? My take would be that in order for authors to be able to expect reasonably consistent implementations, not only should they be dispatched in this case but the mutation events corresponding to the underlying removal/addition should not. -- Robin Berjon Senior Research Scientist Expway, http://expway.com/
Re: DOM3EV: Editorial comments
Hi Robin.
Robin Berjon:
Does 1970-01-01T00:00:00Z use a common enough time format to warrant
not mentioning how it should be parsed (by readers)? Are leap seconds
included in this offset?
Z always has leap seconds, no?
I didn't know, hence the question. Include that explicitly in the text?
[getModifierState]
I think it would be helpful for the description of this method to list
all of the modifier keys that are listed in Appendix A, and also that
others may be used for other modifiers.
Is that really better than referring to App A? Lists that are copied
over tend to go out of sync.
Ok, then remove the partial list from the getModifierState descriptions.
There should also be a way to
get a list of all of the modifiers that are in effect, so that
applications can make use of modifiers that aren't listed in
Appendix A.
Applications can already make use of any modifier not listed by the
specification.
How?
I don't feel very strongly about this but I'm not sure
what the value would be of having a way to list all modifiers that
are in effect. All you could do with it is get a list of modifiers
which you know about and therefore could also query, and of modifiers
which you didn't know existed, and therefore can't do anything with.
You might be right, it mightn't be terribly useful. I was imagining
some kind of webapp where you need to configure key input for different
kinds of input devices, where a device may have modifiers that you could
(configurably) make use of if you knew what they were.
* 1.8.5 Mutation and mutation name event types
Are the DOMElementNameChanged and DOMAttributeNameChanged events fired
if the renameNode just fell back to removing the node and adding a new
one?
My take would be that in order for authors to be able to expect
reasonably consistent implementations, not only should they be
dispatched in this case but the mutation events corresponding to the
underlying removal/addition should not.
I just checked DOM 3 Core, and it says:
* when the implementation supports the feature MutationNameEvents,
each mutation operation involved in this method fires the
appropriate event, and in the end the event
{http://www.w3.org/2001/xml-events, DOMElementNameChanged} or
{http://www.w3.org/2001/xml-events, DOMAttributeNameChanged} is
fired.
So I guess both sets of events need to be fired. It's unfortunate that
DOM 3 Core lists those events with namespaces. I smell an erratum. :)
--
Cameron McCormack ICQ: 26955922
cam (at) mcc.id.au MSN: cam (at) mcc.id.au
http://mcc.id.au/ JBR: heycam (at) jabber.org
