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

Received on Monday, 17 April 2006 00:12:53 UTC