Re: I18N last call comments on DOM 3 Events

On Mon, 2003-08-11 at 12:20, Martin Duerst wrote:
> > > 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.
> >
> >We don't support right or left in the modifiers. If an application
> >wishes to distinguish right and left controls, it should listen to
> >Keyboard events and get the location when the keyIdentifier is
> >"Control".
> 
> Does the spec say so, or does the reader have to infer that?
> The spec should say so.

I added a note for that effect on the getModifierState methods so the
spec will say so.

> > > 1.7.2 there should be a prominent pointer from here to the examples in
> > > Appendix A.
> >
> >Fixed
> >[[
> >Refer to Key identifiers for keyboard events for examples on how text
> >events are used in combination with keyboard events.
> >]]
> 
> Can you change the text so that it explicitly mentions "Appendix A"
> (at least in the printed version).

done.

> > > 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?
> >
> >This constant has been removed.
> 
> Does this mean that there are no private key locations? If so, that's
> okay with us.

It does mean that the specification is not addressing private key
locations and such keys are outside the defined constants.

> > > A.1, third example: In the PDF version (probably also PS), replace
> > > љ by the actual character.
> >
> >Unfortunately, html2ps doesn't support the character and except stealing
> >the actual shape from a converter that is able to generate it,
> 
> Is it possible to add some kind of note here in the PDF/PS versions,
> so that readers don't get confused, and check the HTML? While we say
> that the normative version is HTML, I guess implementers often work
> from a printout.

done.

> > > A.1.2: Clearly say that textInput events should return data in NFC.
> >
> >Added:
> >[[
> >Characters should be normalized as defined by the Unicode normalization
> >form NFC, defined in [UTR #15].
> >]]
> 
> I didn't find this text. In
> http://www.w3.org/2003/06/WD-DOM-Level-3-Events-20030627/keyset.html
> I found:
> "The sequence of keystrokes "U+0302" (Combining Circumflex Accent key) and 
> "U+0045" (Latin Capital Letter E key) will likely produce (on a PC/AT 
> french keyboard using a french mapping and without any modifier activated) 
> the Unicode character e^ (Latin Small Letter E With Circumflex), as 
> preferred by the Unicode Normalization Form NFC:"
> 
> This is not as normative as the text you propose above
> (which should say who is responsible, i.e. that textInput
> events should give back their text in NFC).

The test was added on the data ttribute of the TextEvent interface:
http://www.w3.org/2003/06/WD-DOM-Level-3-Events-20030627/events.html#Events-UIEvent-data

Philippe

Received on Monday, 11 August 2003 17:03:33 UTC