W3C home > Mailing lists > Public > public-xhtml2@w3.org > March 2009

[ACTION-47] Re: [XHTMLAccess] i18n comment 2: Keycode or character

From: Steven Pemberton <steven.pemberton@cwi.nl>
Date: Wed, 11 Mar 2009 15:40:17 +0100
To: "Steven Pemberton" <steven.pemberton@cwi.nl>, "Phillips, Addison" <addison@amazon.com>, "ishida@w3.org" <ishida@w3.org>, "www-html-editor@w3.org" <www-html-editor@w3.org>, "public-i18n-core@w3.org" <public-i18n-core@w3.org>
Cc: "XHTML WG" <public-xhtml2@w3.org>
Message-ID: <op.uqmtpfzasmjzpq@acer3010.flex.surfnet.nl>
Hi Addison,

We would really like to move forward on this.

So are you OK with the reasoning on the choice of the attribute name, and  
the wording suggested by Gregory?
http://lists.w3.org/Archives/Public/www-html-editor/2009JanMar/0009

Best wishes,

Steven

So are you
On Thu, 05 Feb 2009 21:07:52 +0100, Steven Pemberton  
<steven.pemberton@cwi.nl> wrote:

> On Thu, 05 Feb 2009 20:26:32 +0100, Phillips, Addison  
> <addison@amazon.com> wrote:
>
>> I'm not sure I buy the reasoning given here. I agree that the name  
>> 'key' might be too suggestive... except that the whole idea of the  
>> <access> element is to provide accessibility via a keyboard-key  
>> sequence mapping.
>
> That is not the idea at all.  The idea is to identify the access points.  
> You'll note that the key attribute is  optional. There may not even be a  
> keyboard.
>
>> I'm not sure that obscuring this by renaming the attribute is that  
>> useful and personally I'm more concerned about what we say around the  
>> element than with just the attribute name. Does XHTML-WG have a problem  
>> with our suggested text?
>
> Well, since it was predicated on keyboard keys producing characters,  
> yes! We don't mind including text that gives hints about mapping  
> keyboard-produced keys to access mappings, but we don't want people  
> reading it thinking that we are talking principally about keyboards. The  
> text starts with explicit text that says that, but apparently that's not  
> enough.
> Best wishes,
>
> Steven
>
>>
>> Best Regards,
>>
>> Addison
>>
>> Addison Phillips
>> Globalization Architect -- Lab126
>>
>> Internationalization is not a feature.
>> It is an architecture.
>>
>>
>>> -----Original Message-----
>>> From: Steven Pemberton [mailto:steven.pemberton@cwi.nl]
>>> Sent: Thursday, February 05, 2009 11:00 AM
>>> To: Phillips, Addison; ishida@w3.org; www-html-editor@w3.org;
>>> public-i18n-core@w3.org
>>> Cc: XHTML WG
>>> Subject: Re: [XHTMLAccess] i18n comment 2: Keycode or character
>>>
>>> Hello Addison,
>>>
>>> We discussed this at a recent call, and came to the conclusion was
>>> that
>>> the mismatch here was caused by the choice of the attribute "key".
>>> We only
>>> chose this name because it was close to the current HTML attribute
>>> name,
>>> but we decided it was a poor choice because it suggests something
>>> different to what was intended.
>>>
>>> Namely, there is no requirement that the thing contained in the
>>> attribute
>>> called "key" have anything to do with a keyboard. It is more meant
>>> to be
>>> like the key to a table mapping. How the key to that mapping is
>>> generated
>>> is implementation dependent.
>>>
>>> So we think that the best thing would be to rename this attribute
>>> to
>>> remove the ambiguity.
>>>
>>> We thought of such names as:
>>>
>>> 	<access map="c" targetid="contents" />
>>> 	<access code="c" targetid="contents" />
>>> 	<access shortcut="c" targetid="contents" />
>>> 	<access use="c" targetid="contents" />
>>>
>>> Maybe you can think of something better, or choose a preferred one
>>> from
>>> this list.
>>>
>>> Best wishes,
>>>
>>> Steven Pemberton
>>> For the XHTML2 WG
>>>
>>>
>>> On Wed, 07 Jan 2009 22:34:00 +0100, Phillips, Addison
>>> <addison@amazon.com>
>>> wrote:
>>>
>>> > Hi Steven and HTML WG,
>>> >
>>> > This note is on behalf of the Internationalization Core WG.
>>> >
>>> > We recently received your responses to our comments on the XHTML
>>> Access
>>> > Module and we reviewed them at a recent teleconference [1]. While
>>> some
>>> > progress has been made, we're still not entirely satisfied with
>>> the
>>> > results. Our focus is on Section 3.1.2 [2].
>>> >
>>> > We recognize that this is a difficult problem in part because it
>>> hasn't
>>> > been solved in a consistently recognized "best practices" manner:
>>> > different platforms and operating environments have taken
>>> different
>>> > approaches whose details vary when dealing with keyboard events
>>> and
>>> > such. Notably, we've been engaged with the folks working on DOM
>>> Events
>>> > as they struggle with similar issues. (Which is why one sees the
>>> text
>>> > one does in [3]!!)
>>> >
>>> > One of the main problems here is that there is often a difference
>>> > between the "key codes" produced by key events (key up, key down,
>>> etc.)
>>> > and the "char codes" that result from various key presses (i.e.
>>> "key
>>> > typed" events). Try out [4] with different keyboard layouts, for
>>> example.
>>> >
>>> > Comments on the current text follow:
>>> >
>>> > <q>
>>> > This attribute assigns a key mapping to an access shortcut. An
>>> access
>>> > key is a single character from the document character set.
>>> > </q>
>>> >
>>> > This might not be the way to express this. Some visual characters
>>> are
>>> > composed of more than one code point. Some physical keys on
>>> keyboards
>>> > produce multiple characters (or no visual characters at all). And
>>> so
>>> > forth. Linking the characters to the document's character set is
>>> > probably not a good idea either (unless by "document character
>>> set" you
>>> > mean X(HT)ML's character set, which is Unicode). It might be
>>> better to
>>> > say something like:
>>> >
>>> > <q>
>>> > This attribute assigns a key mapping to an access shortcut. The
>>> key
>>> > mapping consists of a single Unicode code point (character).
>>> Typically
>>> > the key mapping is expected to be accessible to the user via a
>>> single
>>> > keystroke, although activating it might involve pressing or
>>> holding down
>>> > multiple keys. The invocation of access keys depends on the
>>> > implementation. For instance, on some systems one may have to
>>> press an
>>> > "alt" or "cmd" key in addition to the access key.
>>> >
>>> > Authors are cautioned that not all characters are appropriate as
>>> access
>>> > key values, since they cannot be accessed directly from the
>>> keyboard.
>>> > Other characters only appear when combined with base characters.
>>> > Examples of these might include combining vowels or tone marks,
>>> such as
>>> > used in Arabic, Southeast Asian, or Indic scripts. These are more
>>> > difficult to communicate to users because, while they can often
>>> be typed
>>> > independently, they are not typically displayed independently and
>>> the
>>> > user might not know which character is intended as the key
>>> mapping.
>>> > Finally, any key available on one keyboard might not be available
>>> on a
>>> > different keyboard layout.
>>> > </q>
>>> >
>>> > Later the text says:
>>> >
>>> > <q>The character assigned to a key, and its relationship to a
>>> role or id
>>> > attribute SHOULD be treated as an author suggestion. </q>
>>> >
>>> > This should probably say: "The key mapping and its..." or
>>> possibly "The
>>> > key attribute and its..."
>>> >
>>> > In the remainder of this section, the phrases "key assignment",
>>> "key",
>>> > "assignment", "key binding", etc. are used to mean the key
>>> attribute
>>> > value, which, in turn, means a character (because the attribute
>>> value is
>>> > defined to be a Unicode code point).
>>> >
>>> > Ultimately, we think you're on the right track here. The
>>> > Internationalization working group would be happy to review text
>>> or work
>>> > with your WG in some other way to help resolve these issues.
>>> >
>>> > Kind regards,
>>> >
>>> > Addison (for I18N Core)
>>> >
>>> > [1] http://www.w3.org/2008/11/26-core-minutes.html#item06
>>> > [2] http://www.w3.org/MarkUp/2008/WD-xhtml-access-
>>> 20080526/#sec_3.1.2.
>>> >     [a] http://www.w3.org/MarkUp/2008/ED-xhtml-access-
>>> 20081023/#A_key
>>> > [3]
>>> > http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-
>>> eventgroupings-keyevents
>>> > [4] http://rishida.net/utils/keyevents/index.html
>>> >
>>> > Addison Phillips
>>> > Globalization Architect -- Lab126
>>> >
>>> > Internationalization is not a feature.
>>> > It is an architecture.
>>> >
>>> >
>>> >> -----Original Message-----
>>> >> From: public-i18n-core-request@w3.org [mailto:public-i18n-core-
>>> >> request@w3.org] On Behalf Of Phillips, Addison
>>> >> Sent: Wednesday, November 26, 2008 7:28 AM
>>> >> To: Steven Pemberton; ishida@w3.org; www-html-editor@w3.org;
>>> >> public-i18n-core@w3.org
>>> >> Subject: RE: [XHTMLAccess] i18n comment 2: Keycode or character
>>> >>
>>> >> (personal response)
>>> >>
>>> >> I think this text moves in the right direction, but think that
>>> >> there may still be problems with it. Mainly, I think it is now
>>> >> unclear how the 'key' attribute is supposed to work, given that
>>> the
>>> >> word key is both disclaimed and also used to mean (or at least
>>> >> imply) actual keypresses.
>>> >>
>>> >> It should be noted that there is not a well-defined solution to
>>> >> this problem. WebAPI has been struggling with this also. In
>>> >> practice, how physical key events and character input are
>>> related
>>> >> is normally handled at a fairly low level in the system. Higher
>>> >> level software that attempts to listen and respond to key press
>>> >> events often ends up damaging or disabling more complex input
>>> >> systems, such as the IMEs (input method editors) used to compose
>>> >> e.g. East Asian text.
>>> >>
>>> >> (chair hat ON)
>>> >>
>>> >> Thanks for the response. The I18N WG will review your response
>>> and
>>> >> text in detail. Our next teleconference is today.
>>> >>
>>> >> Addison
>>> >>
>>> >> Addison Phillips
>>> >> Globalization Architect -- Lab126
>>> >> Chair -- W3C Internationalization Core WG
>>> >>
>>> >> Internationalization is not a feature.
>>> >> It is an architecture.
>>> >>
>>> >>
>>> >> > -----Original Message-----
>>> >> > From: public-i18n-core-request@w3.org [mailto:public-i18n-
>>> core-
>>> >> > request@w3.org] On Behalf Of Steven Pemberton
>>> >> > Sent: Wednesday, November 26, 2008 6:46 AM
>>> >> > To: ishida@w3.org; www-html-editor@w3.org; public-i18n-
>>> >> core@w3.org
>>> >> > Subject: Re: [XHTMLAccess] i18n comment 2: Keycode or
>>> character
>>> >> >
>>> >> >
>>> >> > Thanks.
>>> >> >
>>> >> > We have tried to address this by making certain that people
>>> >> > understand
>>> >> > that "key" is
>>> >> >    an abstraction and does not correlate to a "key code".
>>> >> >
>>> >> > Please see the latest editor's draft for full details.
>>> >> > http://www.w3.org/MarkUp/2008/ED-xhtml-access-20081023/
>>> >> >
>>> >> > Best wishes,
>>> >> >
>>> >> > Steven Pemberton
>>> >> >
>>> >> >
>>> >> > On Wed, 06 Aug 2008 09:12:28 +0200, <ishida@w3.org> wrote:
>>> >> >
>>> >> > >
>>> >> > > Comment from the i18n review of:
>>> >> > > http://www.w3.org/MarkUp/2008/WD-xhtml-access-20080526/
>>> >> > >
>>> >> > > Comment 2
>>> >> > > At
>>> >> > > http://www.w3.org/International/reviews/0806-xhtml-
>>> >> > access/Overview.html
>>> >> > > Editorial/substantive: S
>>> >> > > Tracked by: RI
>>> >> > >
>>> >> > > Location in reviewed document:
>>> >> > > 3.1.2
>>> >> > > [http://www.w3.org/MarkUp/2008/WD-xhtml-access-
>>> >> > 20080526/#sec_3.1.2.]
>>> >> > >
>>> >> > > Comment:
>>> >> > > It isn't clear that this section has taken into account the
>>> >> > potential
>>> >> > > difference between key codes and the characters that may
>>> result
>>> >> > from a
>>> >> > > key press on a given keyboard. It seems to assume that the
>>> >> > character on
>>> >> > > a key cap == the key code identifier == the character
>>> produced
>>> >> by
>>> >> > > pressing that key == the character that is the value of the
>>> key
>>> >> > > attribute.
>>> >> > >
>>> >> > > This is not always the case when you take into account a
>>> >> variety
>>> >> > of
>>> >> > > keyboards serving various different locales.
>>> >> > >
>>> >> > > Please provide some precision as to how a key attribute
>>> value
>>> >> is
>>> >> > > associated with keyboard events. (Note that this has proved
>>> to
>>> >> be
>>> >> > a
>>> >> > > difficult topic for the specification of DOM3 keyboard
>>> events.)
>>> >> > >
>>> >> > >
>>> >> > >
>>> >> >
>>> >> >
>>> >
>>>
>>
>
Received on Wednesday, 11 March 2009 14:40:36 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 23 February 2010 18:12:53 GMT