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/

Received on Sunday, 16 April 2006 16:19:52 UTC