Key events feedback: Key values set

These are personal comments, until such time as the i18n WG decides that they wish to endorse them.

[1] 6.2.7 colour conventions

I assume (since it is not mentioned afaict) that text with a green background in 6.2.7 is a character value, and that with a blue background is a key name.  I think that should be made clear in the text, but that there should also be some accessible way of indicating which is which in the list.  

The text on orange background appears to be a way of showing what the character looks like when it is a graphical character, but the colouring appears to give it an official meaning, which I don't think is justified. (I assume the text 'The Latin Small Letter Z key: z.' is just descriptive, and therefore using colour like this mixes conventions for identifying types of content with visual highlighters.)  This may be moot, however, in light of the comment 2 below.

[2] 6.2.7 character values in the list

The character values are always described using javascript escapes. While this may be useful to refer to some non-graphic characters, I don't think it is worthwhile to give the character value of characters like 'z' as '\u005B'.  The character value should just be listed as 'z', since that is actually the same thing, and is what is returned as the key value by the program, and what the developer is most likely to use in their code (for simplicity and readability).  This is also what I understood to be the expectation of the group we talked with at TPAC. 

To put this another way... I don't expect pressing the Z key on a US Querty keyboard to return a key value that is 6 characters in length and consists of 

  U+0030  DIGIT ZERO
  U+0030  DIGIT ZERO
  U+0035  DIGIT FIVE

I expect it to return a single character


Therefore, I think the introductory text before the list should say something like: 

"Character values for graphic characters are shown as the character itself in the list that follows.  Where a character value doesn't have a graphic form, it is listed here using, for convenience, an equivalent character escape. We have adopted the JavaScript notation for escapes in this list."

This is not likely to produce complications related to supplementary characters, since this list doesn't contain any.

This also removes complications wrt supplementary character formats for selecting and defining key values that are not on the list, since we are just talking about the character itself being the character value.

[3] 6.2.7 character value definition

The definition says: "In the context of key values, a character value is a string representing a single Unicode character, such as a letter or symbol, as a UTF-16 character escape (e.g. '\u0041' for the Latin Capital Letter A key, A.)."

I think this is based on a misunderstanding of the relationship between escapes and characters, since in JavaScript '\u0041' is exactly equivalent to 'A', and is converted to the latter before processing, and so I believe the definition should be changed as follows:

"In the context of key values, a character value is a string representing a single Unicode character, such as a letter or symbol.  Note, in source code, some key values, such as non-graphic characters, may be represented using the character escape syntax of the programming language in use. "

[4] 6.2.6 key value names

Given the above, step 1.1.2 in this section becomes much simpler, and would probably just read something like this:

"If there is no appropriate key value in the key values set, and there exists an appropriate Unicode code point, then the key value is a string consisting of just that Unicode character as a character value."

I have plenty of other comments, but they are dependent upon agreement with the above, so I will hold on them for now and will wait for a reply to these points (though I may send a few editorial points in the meantime).  So please get back to me soon with a response on these points so that we can continue to move this forward (or not).


Richard Ishida
Internationalization Lead
W3C (World Wide Web Consortium)

Received on Wednesday, 17 February 2010 12:14:08 UTC