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/
