W3C home > Mailing lists > Public > www-dom@w3.org > April to June 2010

Re: Key events feedback: Key values set

From: Doug Schepers <schepers@w3.org>
Date: Wed, 14 Apr 2010 02:59:14 -0400
Message-ID: <4BC567C2.2050203@w3.org>
To: Richard Ishida <ishida@w3.org>
CC: www-dom@w3.org, public-i18n-core@w3.org
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

-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
> 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).
> 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:18 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 10:46:16 UTC