- From: Martin Duerst <duerst@w3.org>
- Date: Thu, 15 May 2003 17:24:14 -0400
- To: plh@w3.org, www-dom@w3.org
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