[XHTMLAccess] i18n comment 2: Keycode or character

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

[XHTMLAccess] i18n comment 2: Keycode or character

r12a

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.)

 


Reply | Threaded
Open this post in threaded view
|

Re: [XHTMLAccess] i18n comment 2: Keycode or character

Steven Pemberton-3

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, <[hidden email]> 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.)
>
>
>



Reply | Threaded
Open this post in threaded view
|

Re: [XHTMLAccess] i18n comment 2: Keycode or character

Ori Idan-3
I don't understand the meaning of "characters from the document character set"

--
Ori Idan


On Wed, Nov 26, 2008 at 4:46 PM, Steven Pemberton <[hidden email]> wrote:

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, <[hidden email]> 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.)







Reply | Threaded
Open this post in threaded view
|

Re: [XHTMLAccess] i18n comment 2: Keycode or character

Steven Pemberton-3

On Wed, 26 Nov 2008 16:11:54 +0100, Ori Idan <[hidden email]> wrote:

> I don't understand the meaning of "characters from the document character
> set"
>

See http://www.w3.org/International/O-charset

Best wishes,

Steven Pemberton


Reply | Threaded
Open this post in threaded view
|

RE: [XHTMLAccess] i18n comment 2: Keycode or character

Phillips, Addison
In reply to this post by Steven Pemberton-3
(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: [hidden email] [mailto:public-i18n-core-
> [hidden email]] On Behalf Of Steven Pemberton
> Sent: Wednesday, November 26, 2008 6:46 AM
> To: [hidden email]; [hidden email]; [hidden email]
> 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, <[hidden email]> 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.)
> >
> >
> >
>
>

Reply | Threaded
Open this post in threaded view
|

RE: [XHTMLAccess] i18n comment 2: Keycode or character

Phillips, Addison
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: [hidden email] [mailto:public-i18n-core-
> [hidden email]] On Behalf Of Phillips, Addison
> Sent: Wednesday, November 26, 2008 7:28 AM
> To: Steven Pemberton; [hidden email]; [hidden email];
> [hidden email]
> 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: [hidden email] [mailto:public-i18n-core-
> > [hidden email]] On Behalf Of Steven Pemberton
> > Sent: Wednesday, November 26, 2008 6:46 AM
> > To: [hidden email]; [hidden email]; public-i18n-
> [hidden email]
> > 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, <[hidden email]> 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.)
> > >
> > >
> > >
> >
> >

Reply | Threaded
Open this post in threaded view
|

RE: [XHTMLAccess] i18n comment 2: Keycode or character

Phillips, Addison
One additional note that I forgot to include below: we'd like to work with HTML to resolve this, as we understand that you have schedule slippage waiting on our response. Would it be appropriate to schedule either representative(s) to attend one of our upcoming telecons [or vice-versa]?? Please let us know how best to help you.

Addison (for I18N Core WG)

Addison Phillips
Globalization Architect -- Lab126

Internationalization is not a feature.
It is an architecture.


> -----Original Message-----
> From: Phillips, Addison
> Sent: Wednesday, January 07, 2009 1:34 PM
> To: Phillips, Addison; Steven Pemberton; [hidden email]; www-html-
> [hidden email]; [hidden email]
> Subject: RE: [XHTMLAccess] i18n comment 2: Keycode or character
>
> 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: [hidden email] [mailto:public-i18n-core-
> > [hidden email]] On Behalf Of Phillips, Addison
> > Sent: Wednesday, November 26, 2008 7:28 AM
> > To: Steven Pemberton; [hidden email]; [hidden email];
> > [hidden email]
> > 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: [hidden email] [mailto:public-i18n-core-
> > > [hidden email]] On Behalf Of Steven Pemberton
> > > Sent: Wednesday, November 26, 2008 6:46 AM
> > > To: [hidden email]; [hidden email]; public-i18n-
> > [hidden email]
> > > 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, <[hidden email]> 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.)
> > > >
> > > >
> > > >
> > >
> > >

Reply | Threaded
Open this post in threaded view
|

Re: [XHTMLAccess] i18n comment 2: Keycode or character

Steven Pemberton-3
In reply to this post by Phillips, Addison

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 <[hidden email]>  
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: [hidden email] [mailto:public-i18n-core-
>> [hidden email]] On Behalf Of Phillips, Addison
>> Sent: Wednesday, November 26, 2008 7:28 AM
>> To: Steven Pemberton; [hidden email]; [hidden email];
>> [hidden email]
>> 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: [hidden email] [mailto:public-i18n-core-
>> > [hidden email]] On Behalf Of Steven Pemberton
>> > Sent: Wednesday, November 26, 2008 6:46 AM
>> > To: [hidden email]; [hidden email]; public-i18n-
>> [hidden email]
>> > 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, <[hidden email]> 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.)
>> > >
>> > >
>> > >
>> >
>> >
>



Reply | Threaded
Open this post in threaded view
|

RE: [XHTMLAccess] i18n comment 2: Keycode or character

Phillips, Addison
Hello Steven,

Thanks for the note.

(chair hat on)

I will add this to our agenda for our next teleconference.

(chair hat off; personal response)

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. This isn't necessarily wrong or bad. It just may not be very useful in certain input contexts (when IMEs are active; in languages that require combining marks; etc.). This is, I should add, a problem that keyboard mnemonics have had in desktop software localization for (essentially) forever.

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?

Best Regards,

Addison

Addison Phillips
Globalization Architect -- Lab126

Internationalization is not a feature.
It is an architecture.


> -----Original Message-----
> From: Steven Pemberton [mailto:[hidden email]]
> Sent: Thursday, February 05, 2009 11:00 AM
> To: Phillips, Addison; [hidden email]; [hidden email];
> [hidden email]
> 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
> <[hidden email]>
> 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: [hidden email] [mailto:public-i18n-core-
> >> [hidden email]] On Behalf Of Phillips, Addison
> >> Sent: Wednesday, November 26, 2008 7:28 AM
> >> To: Steven Pemberton; [hidden email]; [hidden email];
> >> [hidden email]
> >> 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: [hidden email] [mailto:public-i18n-
> core-
> >> > [hidden email]] On Behalf Of Steven Pemberton
> >> > Sent: Wednesday, November 26, 2008 6:46 AM
> >> > To: [hidden email]; [hidden email]; public-i18n-
> >> [hidden email]
> >> > 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, <[hidden email]> 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.)
> >> > >
> >> > >
> >> > >
> >> >
> >> >
> >
>

Reply | Threaded
Open this post in threaded view
|

Re: [XHTMLAccess] i18n comment 2: Keycode or character

Steven Pemberton-3

On Thu, 05 Feb 2009 20:26:32 +0100, Phillips, Addison <[hidden email]>  
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:[hidden email]]
>> Sent: Thursday, February 05, 2009 11:00 AM
>> To: Phillips, Addison; [hidden email]; [hidden email];
>> [hidden email]
>> 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
>> <[hidden email]>
>> 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: [hidden email] [mailto:public-i18n-core-
>> >> [hidden email]] On Behalf Of Phillips, Addison
>> >> Sent: Wednesday, November 26, 2008 7:28 AM
>> >> To: Steven Pemberton; [hidden email]; [hidden email];
>> >> [hidden email]
>> >> 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: [hidden email] [mailto:public-i18n-
>> core-
>> >> > [hidden email]] On Behalf Of Steven Pemberton
>> >> > Sent: Wednesday, November 26, 2008 6:46 AM
>> >> > To: [hidden email]; [hidden email]; public-i18n-
>> >> [hidden email]
>> >> > 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, <[hidden email]> 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.)
>> >> > >
>> >> > >
>> >> > >
>> >> >
>> >> >
>> >
>>
>



Reply | Threaded
Open this post in threaded view
|

RE: [XHTMLAccess] i18n comment 2: Keycode or character

Gregory J. Rosmaita
In reply to this post by Phillips, Addison

aloha, addison!

speaking on my own as a member of the XHTML2 and PF working groups,
would you (individually and collectively) be satisfied with a note
following the base definition of the key attribute to the following
effect (your words, tweaked into note form)

<q rev="gjr">
 Authors are cautioned that not all characters are appropriate as access  
 key values, since not all characters can be accessed directly from the
 keyboard.  Some characters can only be generated when combined with
 base characters. Examples include: combining vowels or tone marks,
 such as are 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 rendered
 independently and the user might not know which character is intended
 as the key mapping.  Finally, authors are cautioned that any key
 available in one keyboard might not be available in a different
 keyboard layout.
</q>

note that i replaced "displayed" with the more neutral "rendered", as a
visual rendering is only one means of conveying the character: other
options include synthesized speech and refreshable and/or embossed
braille...

also, i second your second suggestion:

> This should probably say: "The key mapping and its..." or
possibly "The  
> key attribute and its..."

and support changing the first sentence of the paragraph with "The key
attribute and its..." as the key is defined as a unicode point

hope this is helpful,
gregory.

------------------------------------------------------------------
Accessibility, Internationalization, and Interoperability are not
"features". They are core component of any program's architecture.
                        -- inspired by Addisson Phillips' tagline
------------------------------------------------------------------
               Gregory J. Rosmaita, [hidden email]
    Camera Obscura: http://www.hicom.net/~oedipus/index.html
------------------------------------------------------------------


---------- Original Message -----------
From: "Phillips, Addison" <[hidden email]>
To: Steven Pemberton <[hidden email]>, "[hidden email]"
<[hidden email]>, "[hidden email]" <www-html-
[hidden email]>, "[hidden email]" <[hidden email]>
Cc: XHTML WG <[hidden email]>
Sent: Thu, 5 Feb 2009 11:26:32 -0800
Subject: RE: [XHTMLAccess] i18n comment 2: Keycode or character

> Hello Steven,
>
> Thanks for the note.
>
> (chair hat on)
>
> I will add this to our agenda for our next teleconference.
>
> (chair hat off; personal response)
>
> 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. This isn't necessarily wrong or
> bad. It just may not be very useful in certain input contexts
> (when IMEs are active; in languages that require combining
> marks; etc.). This is, I should add, a problem that keyboard
> mnemonics have had in desktop software localization for
> (essentially) forever.
>
> 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?
>
> Best Regards,
>
> Addison
>
> Addison Phillips
> Globalization Architect -- Lab126
>
> Internationalization is not a feature.
> It is an architecture.
>
> > -----Original Message-----
> > From: Steven Pemberton [mailto:[hidden email]]
> > Sent: Thursday, February 05, 2009 11:00 AM
> > To: Phillips, Addison; [hidden email]; [hidden email];
> > [hidden email]
> > 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
> > <[hidden email]>
> > 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: [hidden email] [mailto:public-i18n-core-
> > >> [hidden email]] On Behalf Of Phillips, Addison
> > >> Sent: Wednesday, November 26, 2008 7:28 AM
> > >> To: Steven Pemberton; [hidden email]; [hidden email];
> > >> [hidden email]
> > >> 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: [hidden email] [mailto:public-i18n-
> > core-
> > >> > [hidden email]] On Behalf Of Steven Pemberton
> > >> > Sent: Wednesday, November 26, 2008 6:46 AM
> > >> > To: [hidden email]; [hidden email]; public-i18n-
> > >> [hidden email]
> > >> > 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, <[hidden email]> 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.)
> > >> > >
> > >> > >
> > >> > >
> > >> >
> > >> >
> > >
> >
------- End of Original Message -------


Reply | Threaded
Open this post in threaded view
|

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

Steven Pemberton-3
In reply to this post by Steven Pemberton-3
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  
<[hidden email]> wrote:

> On Thu, 05 Feb 2009 20:26:32 +0100, Phillips, Addison  
> <[hidden email]> 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:[hidden email]]
>>> Sent: Thursday, February 05, 2009 11:00 AM
>>> To: Phillips, Addison; [hidden email]; [hidden email];
>>> [hidden email]
>>> 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
>>> <[hidden email]>
>>> 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: [hidden email] [mailto:public-i18n-core-
>>> >> [hidden email]] On Behalf Of Phillips, Addison
>>> >> Sent: Wednesday, November 26, 2008 7:28 AM
>>> >> To: Steven Pemberton; [hidden email]; [hidden email];
>>> >> [hidden email]
>>> >> 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: [hidden email] [mailto:public-i18n-
>>> core-
>>> >> > [hidden email]] On Behalf Of Steven Pemberton
>>> >> > Sent: Wednesday, November 26, 2008 6:46 AM
>>> >> > To: [hidden email]; [hidden email]; public-i18n-
>>> >> [hidden email]
>>> >> > 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, <[hidden email]> 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.)
>>> >> > >
>>> >> > >
>>> >> > >
>>> >> >
>>> >> >
>>> >
>>>
>>
>



Reply | Threaded
Open this post in threaded view
|

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

Phillips, Addison
Hi Steven,

We're okay with this resolution.

Addison (for I18N)

Addison Phillips
Globalization Architect -- Lab126

Internationalization is not a feature.
It is an architecture.


> -----Original Message-----
> From: Steven Pemberton [mailto:[hidden email]]
> Sent: Wednesday, March 11, 2009 7:40 AM
> To: Steven Pemberton; Phillips, Addison; [hidden email]; www-html-
> [hidden email]; [hidden email]
> Cc: XHTML WG
> Subject: [ACTION-47] Re: [XHTMLAccess] i18n comment 2: Keycode or
> character
>
> 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
> <[hidden email]> wrote:
>
> > On Thu, 05 Feb 2009 20:26:32 +0100, Phillips, Addison
> > <[hidden email]> 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:[hidden email]]
> >>> Sent: Thursday, February 05, 2009 11:00 AM
> >>> To: Phillips, Addison; [hidden email]; [hidden email];
> >>> [hidden email]
> >>> 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
> >>> <[hidden email]>
> >>> 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: [hidden email] [mailto:public-i18n-
> core-
> >>> >> [hidden email]] On Behalf Of Phillips, Addison
> >>> >> Sent: Wednesday, November 26, 2008 7:28 AM
> >>> >> To: Steven Pemberton; [hidden email]; [hidden email];
> >>> >> [hidden email]
> >>> >> 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: [hidden email] [mailto:public-i18n-
> >>> core-
> >>> >> > [hidden email]] On Behalf Of Steven Pemberton
> >>> >> > Sent: Wednesday, November 26, 2008 6:46 AM
> >>> >> > To: [hidden email]; [hidden email]; public-i18n-
> >>> >> [hidden email]
> >>> >> > 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, <[hidden email]> 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.)
> >>> >> > >
> >>> >> > >
> >>> >> > >
> >>> >> >
> >>> >> >
> >>> >
> >>>
> >>
> >
>

Reply | Threaded
Open this post in threaded view
|

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

Steven Pemberton-3
That's great! Many thanks.

Steven

On Wed, 11 Mar 2009 15:44:30 +0100, Phillips, Addison <[hidden email]>  
wrote:

> Hi Steven,
>
> We're okay with this resolution.
>
> Addison (for I18N)
>
> Addison Phillips
> Globalization Architect -- Lab126
>
> Internationalization is not a feature.
> It is an architecture.
>
>
>> -----Original Message-----
>> From: Steven Pemberton [mailto:[hidden email]]
>> Sent: Wednesday, March 11, 2009 7:40 AM
>> To: Steven Pemberton; Phillips, Addison; [hidden email]; www-html-
>> [hidden email]; [hidden email]
>> Cc: XHTML WG
>> Subject: [ACTION-47] Re: [XHTMLAccess] i18n comment 2: Keycode or
>> character
>>
>> 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
>> <[hidden email]> wrote:
>>
>> > On Thu, 05 Feb 2009 20:26:32 +0100, Phillips, Addison
>> > <[hidden email]> 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:[hidden email]]
>> >>> Sent: Thursday, February 05, 2009 11:00 AM
>> >>> To: Phillips, Addison; [hidden email]; [hidden email];
>> >>> [hidden email]
>> >>> 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
>> >>> <[hidden email]>
>> >>> 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: [hidden email] [mailto:public-i18n-
>> core-
>> >>> >> [hidden email]] On Behalf Of Phillips, Addison
>> >>> >> Sent: Wednesday, November 26, 2008 7:28 AM
>> >>> >> To: Steven Pemberton; [hidden email]; [hidden email];
>> >>> >> [hidden email]
>> >>> >> 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: [hidden email] [mailto:public-i18n-
>> >>> core-
>> >>> >> > [hidden email]] On Behalf Of Steven Pemberton
>> >>> >> > Sent: Wednesday, November 26, 2008 6:46 AM
>> >>> >> > To: [hidden email]; [hidden email]; public-i18n-
>> >>> >> [hidden email]
>> >>> >> > 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, <[hidden email]> 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.)
>> >>> >> > >
>> >>> >> > >
>> >>> >> > >
>> >>> >> >
>> >>> >> >
>> >>> >
>> >>>
>> >>
>> >
>>
>