Re: Key events feedback: Key values set

Hi, Richard-

Thanks for your helpful and detailed comments, and sorry for the delayed 
response.  I believe I have addressed all these comments in the latest 
editor's draft of the spec [1], using your suggested wording (thanks 
especially for that).  Please let me know if I've messed something up.

I look forward to any further improvements you or the other i18n folks 
have for the spec.

[1] http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html

Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs


Richard Ishida wrote (on 2/17/10 7:13 AM):
> 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+005C  REVERSE SOLIDUS U+0075  LATIN SMALL LETTER U U+0030  DIGIT
> ZERO U+0030  DIGIT ZERO U+0035  DIGIT FIVE U+0042  LATIN CAPITAL
> LETTER B
>
> I expect it to return a single character
>
> U+007A  LATIN SMALL LETTER Z
>
> 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).
>
> RI
>
>
> ============ Richard Ishida Internationalization Lead W3C (World Wide
> Web Consortium)
>
> http://www.w3.org/International/ http://rishida.net/
>

Received on Wednesday, 14 April 2010 06:59:16 UTC