I18N last call comments on DOM 3 Events

Dear DOM WG,

These are the last call comments from the I18N WG (core task force).
Both Francois Yergeau and me have had a look at the spec, and the
task force has discussed our comments, approved them, and actioned
me to tell you.

To save time and effort, I haven't written up my small editorial
comments; I will leave a marked-up copy of the spec on Philippe's
desk, and he can check back with me in case of questions. So the
list below contains:

- major comments from Francois
- minor comments from Francois
- major comments from me

(not necessarily in that order)


1.2.1 Phase, 1st para: "target ancestor" is misleading, it took me while to
understand that it was "ancestor of the target" (or "target's ancestor"),
not some ancestor that is qualified as a target.  Same comment for other
instances of "target ancestor" later on.

1.2.2.1, 1st para: this sentence is hard to understand at this point, as one
doesn't know yet what "type", "category" and "group" mean.  Looking at the
glossary didn't help.

1.2.2.6, 1st para: "The effect could be:"  Under what conditions?  Under
control of the API?  At implementer's choice?

1.4, 1st para: "The event type is composed of a local name and a namespace
URI as defined in [XML Namespaces]."  It would be far better to say
"namespace name" instead of "namespace URI" and to point normatively to
Namespaces 1.1 (http://www.w3.org/TR/xml-names11/), now in CR and therefore
referenceable from a WD or CR.  One reason is to allow IRIs, another is to
buy in all the behaviour defined in Namespaces, instead of paraphrasing it
in the Note below the 1st para.  This note, also, appears to contain
normative language that is made non-normative by being in a Note.  Only the
last two sentences need to survive, the rest should be farmed out to the
Namespaces spec.

1.4.2: There seems to be a contradiction between the listings for "resize"
and "scroll" in the table and the wording in 1.7.6 which place them in the
BasicEvents module, not UIEvent.

1.4.3, 1st line: typo, "Were" -> "were".

1.6, description of the "type" attribute of Event: the 1st sentence says
"must be an NCName", second sentence says "(colon) should not be used".
This is redundant, except for the "should" and "must" which are not
consistent.

1.6, description of the "initEvent" method of Event: there is a mention of
an "Event.localName" attribute which doesn't seem to appear anywhere else.

1.6, description of the "initEventNS" method of Event:  missing word
"before" between "multiple times" and "the event has been dispatched".

1.6, description of the "isCustom" method of Event: the description of the
return value is actually that of the isDefaultPrevented method.

1.6, description of the "stopPropagation" method of Event:  "differed" ->
"deferred".  There are a couple of other instances of this one.

1.6.1, 1st para in description of the DocumentEvent interface: "It is
expected that the DocumentEvent interface will be implemented on the same
object..."  It would seem that interoperability would require a MUST here.
Otherwise, how does one get to the DocumentEvent interface?

1.7.2, TextEvent interface: Yes!  And kudos for making the data attribute be
a DOMString, not a single character.

1.7.2, issue paste-1: decision seems wrong.  An app that wants to be alerted
on text input (e.g. to implement something like an incremental search) would
miss important input.  And what if some voice-to-text software uses the
clipboard?

1.7.2, initTextEvent: since this interface is new to Level 3, this method
appears to be superfluous.  One can just call initTextEventNS with a null
namespace.  Same comment for KeyboardEvent and MutationNameEvent.

1.7.2, description of initTextEvent: it gets really annoying to re-read in
each init*Event and each init*EventNS method that "This method may only be
called before the UIEvent has been dispatched via the
EventTarget.dispatchEvent method, though it may be called multiple times
during that phase if necessary. If called multiple times, the final
invocation takes precedence." Can't this this factored away somewhere?
Also, the ones in TextEvent say "This method has no effect if called after
the event has been dispatched.", but not the others, is there a reason?

1.7.3, MouseEvent interface: thanks for the addition of altGraphKey, but
this is still missing an important modifier, that for the right Ctrl key.
This is distinct from the left Ctrl key and is standardized by ISO 9995 as
the Group Select key.  It is a modifier just like Shift, Alt, etc.  It is
not the same as the Meta key, some keyboards (notably Macintosh) have both.

1.7.4, KeyboardEvent interface: same comment as above for the missing
attribute for the right Ctrl modifier key.

1.7.4, KeyboardEvent interface: it should be clarified in this section that
the pressing and releasing of modifiers keys are expected to generate
events, as the examples in Appendix A show.

1.7.4, description of "keyIdentifier", says "For a list of *possible*
values..." (emphasis mine).  This seems to be much too weak, there is no
conformance requirement at all and nothing for implementers of DOM
applications to rely on.  It is possible that a key will generate some
identifier as described in Appendix A, but it is also possible that it will
generate something else or whatever.  What is the poor programmer to do?
This needs to be tightened, so that one can have a reasonable expectation
that the "Enter" key will generate "Enter", and so on.

Appendix A: this needs a thorough spell- and grammar-check.

The index is mostly unusable in the printed (PDF) version, most entries have
no associated page numbers.


1.4 and other places: Use IRIs, not URIs (I think the DOM WG is already
     looking into this issue)

1.7.2 there should be a prominent pointer from here to the examples in
       Appendix A.

1.7.4 DOM_KEY_LOCATION_UNKNOWN: It seems to be a bad idea to have this
       at 0x04. Why not e.g. move it up to 0x80, so that there is space
       for potential future standardization?

App. A: U+HHHHHH notation: This should use the standard form: At least
      4 and at most 6 hex digits, leading digits only for 4-digit form.
      This means that all identifiers in the spec have to lose two
      leading zeroes.

A.1: For the first two examples, there should be an explanation why
      keydown of a capital letter produces a textInput of a lowercase
      letter. (the example as such is correct because the embossing on
      the key is usually upper case)

General: There should be an example that shows how event groups can be
      used. Otherwise, this looks like an unnecessary complication to
      many readers.

Key events: The CAPS LOCK key needs to be added as a modifier. This
      is used on some Hebrew, Czech, and Swiss German keyboards.

A.1, third example: In the PDF version (probably also PS), replace
      љ by the actual character.

A.1: Provide an example (or two contrasting ones) that shows that
      on different architectures, it may be possible to receive
      different key events even if the text event(s) are the same.

A.1.2: Clearly say that textInput events should return data in NFC.

A.1.3: Pressing the "Convert" key usually will change the Hiragana
        'shi' (which is already visible when the user types 'i')
        into a kanji (e.g. 市 or 氏 or 詩 or 師,...)


Regards,    Martin.

Received on Thursday, 15 May 2003 18:12:29 UTC