Hi Addison,

We would really like to move forward on this.

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

Best wishes,

Steven

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

On Thu, 05 Feb 2009 20:26:32 +0100, Phillips, Addison <addi...@amazon.com> wrote:

I'm not sure I buy the reasoning given here. I agree that the name 'key' might be too suggestive... except that the whole idea of the <access> element is to provide accessibility via a keyboard-key sequence mapping.

That is not the idea at all. The idea is to identify the access points. You'll note that the key attribute is optional. There may not even be a keyboard.

I'm not sure that obscuring this by renaming the attribute is that useful and personally I'm more concerned about what we say around the element than with just the attribute name. Does XHTML-WG have a problem with our suggested text?

Well, since it was predicated on keyboard keys producing characters, yes! We don't mind including text that gives hints about mapping keyboard-produced keys to access mappings, but we don't want people reading it thinking that we are talking principally about keyboards. The text starts with explicit text that says that, but apparently that's not enough.
Best wishes,

Steven


Best Regards,

Addison

Addison Phillips
Globalization Architect -- Lab126

Internationalization is not a feature.
It is an architecture.


-----Original Message-----
From: Steven Pemberton [mailto:steven.pember...@cwi.nl]
Sent: Thursday, February 05, 2009 11:00 AM
To: Phillips, Addison; ish...@w3.org; www-html-editor@w3.org;
public-i18n-c...@w3.org
Cc: XHTML WG
Subject: Re: [XHTMLAccess] i18n comment 2: Keycode or character

Hello Addison,

We discussed this at a recent call, and came to the conclusion was
that
the mismatch here was caused by the choice of the attribute "key".
We only
chose this name because it was close to the current HTML attribute
name,
but we decided it was a poor choice because it suggests something
different to what was intended.

Namely, there is no requirement that the thing contained in the
attribute
called "key" have anything to do with a keyboard. It is more meant
to be
like the key to a table mapping. How the key to that mapping is
generated
is implementation dependent.

So we think that the best thing would be to rename this attribute
to
remove the ambiguity.

We thought of such names as:

        <access map="c" targetid="contents" />
        <access code="c" targetid="contents" />
        <access shortcut="c" targetid="contents" />
        <access use="c" targetid="contents" />

Maybe you can think of something better, or choose a preferred one
from
this list.

Best wishes,

Steven Pemberton
For the XHTML2 WG


On Wed, 07 Jan 2009 22:34:00 +0100, Phillips, Addison
<addi...@amazon.com>
wrote:

> Hi Steven and HTML WG,
>
> This note is on behalf of the Internationalization Core WG.
>
> We recently received your responses to our comments on the XHTML
Access
> Module and we reviewed them at a recent teleconference [1]. While
some
> progress has been made, we're still not entirely satisfied with
the
> results. Our focus is on Section 3.1.2 [2].
>
> We recognize that this is a difficult problem in part because it
hasn't
> been solved in a consistently recognized "best practices" manner:
> different platforms and operating environments have taken
different
> approaches whose details vary when dealing with keyboard events
and
> such. Notably, we've been engaged with the folks working on DOM
Events
> as they struggle with similar issues. (Which is why one sees the
text
> one does in [3]!!)
>
> One of the main problems here is that there is often a difference
> between the "key codes" produced by key events (key up, key down,
etc.)
> and the "char codes" that result from various key presses (i.e.
"key
> typed" events). Try out [4] with different keyboard layouts, for
example.
>
> Comments on the current text follow:
>
> <q>
> This attribute assigns a key mapping to an access shortcut. An
access
> key is a single character from the document character set.
> </q>
>
> This might not be the way to express this. Some visual characters
are
> composed of more than one code point. Some physical keys on
keyboards
> produce multiple characters (or no visual characters at all). And
so
> forth. Linking the characters to the document's character set is
> probably not a good idea either (unless by "document character
set" you
> mean X(HT)ML's character set, which is Unicode). It might be
better to
> say something like:
>
> <q>
> This attribute assigns a key mapping to an access shortcut. The
key
> mapping consists of a single Unicode code point (character).
Typically
> the key mapping is expected to be accessible to the user via a
single
> keystroke, although activating it might involve pressing or
holding down
> multiple keys. The invocation of access keys depends on the
> implementation. For instance, on some systems one may have to
press an
> "alt" or "cmd" key in addition to the access key.
>
> Authors are cautioned that not all characters are appropriate as
access
> key values, since they cannot be accessed directly from the
keyboard.
> Other characters only appear when combined with base characters.
> Examples of these might include combining vowels or tone marks,
such as
> used in Arabic, Southeast Asian, or Indic scripts. These are more
> difficult to communicate to users because, while they can often
be typed
> independently, they are not typically displayed independently and
the
> user might not know which character is intended as the key
mapping.
> Finally, any key available on one keyboard might not be available
on a
> different keyboard layout.
> </q>
>
> Later the text says:
>
> <q>The character assigned to a key, and its relationship to a
role or id
> attribute SHOULD be treated as an author suggestion. </q>
>
> This should probably say: "The key mapping and its..." or
possibly "The
> key attribute and its..."
>
> In the remainder of this section, the phrases "key assignment",
"key",
> "assignment", "key binding", etc. are used to mean the key
attribute
> value, which, in turn, means a character (because the attribute
value is
> defined to be a Unicode code point).
>
> Ultimately, we think you're on the right track here. The
> Internationalization working group would be happy to review text
or work
> with your WG in some other way to help resolve these issues.
>
> Kind regards,
>
> Addison (for I18N Core)
>
> [1] http://www.w3.org/2008/11/26-core-minutes.html#item06
> [2] http://www.w3.org/MarkUp/2008/WD-xhtml-access-
20080526/#sec_3.1.2.
>     [a] http://www.w3.org/MarkUp/2008/ED-xhtml-access-
20081023/#A_key
> [3]
> http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-
eventgroupings-keyevents
> [4] http://rishida.net/utils/keyevents/index.html
>
> Addison Phillips
> Globalization Architect -- Lab126
>
> Internationalization is not a feature.
> It is an architecture.
>
>
>> -----Original Message-----
>> From: public-i18n-core-requ...@w3.org [mailto:public-i18n-core-
>> requ...@w3.org] On Behalf Of Phillips, Addison
>> Sent: Wednesday, November 26, 2008 7:28 AM
>> To: Steven Pemberton; ish...@w3.org; www-html-editor@w3.org;
>> public-i18n-c...@w3.org
>> Subject: RE: [XHTMLAccess] i18n comment 2: Keycode or character
>>
>> (personal response)
>>
>> I think this text moves in the right direction, but think that
>> there may still be problems with it. Mainly, I think it is now
>> unclear how the 'key' attribute is supposed to work, given that
the
>> word key is both disclaimed and also used to mean (or at least
>> imply) actual keypresses.
>>
>> It should be noted that there is not a well-defined solution to
>> this problem. WebAPI has been struggling with this also. In
>> practice, how physical key events and character input are
related
>> is normally handled at a fairly low level in the system. Higher
>> level software that attempts to listen and respond to key press
>> events often ends up damaging or disabling more complex input
>> systems, such as the IMEs (input method editors) used to compose
>> e.g. East Asian text.
>>
>> (chair hat ON)
>>
>> Thanks for the response. The I18N WG will review your response
and
>> text in detail. Our next teleconference is today.
>>
>> Addison
>>
>> Addison Phillips
>> Globalization Architect -- Lab126
>> Chair -- W3C Internationalization Core WG
>>
>> Internationalization is not a feature.
>> It is an architecture.
>>
>>
>> > -----Original Message-----
>> > From: public-i18n-core-requ...@w3.org [mailto:public-i18n-
core-
>> > requ...@w3.org] On Behalf Of Steven Pemberton
>> > Sent: Wednesday, November 26, 2008 6:46 AM
>> > To: ish...@w3.org; www-html-editor@w3.org; public-i18n-
>> c...@w3.org
>> > Subject: Re: [XHTMLAccess] i18n comment 2: Keycode or
character
>> >
>> >
>> > Thanks.
>> >
>> > We have tried to address this by making certain that people
>> > understand
>> > that "key" is
>> >    an abstraction and does not correlate to a "key code".
>> >
>> > Please see the latest editor's draft for full details.
>> > http://www.w3.org/MarkUp/2008/ED-xhtml-access-20081023/
>> >
>> > Best wishes,
>> >
>> > Steven Pemberton
>> >
>> >
>> > On Wed, 06 Aug 2008 09:12:28 +0200, <ish...@w3.org> wrote:
>> >
>> > >
>> > > Comment from the i18n review of:
>> > > http://www.w3.org/MarkUp/2008/WD-xhtml-access-20080526/
>> > >
>> > > Comment 2
>> > > At
>> > > http://www.w3.org/International/reviews/0806-xhtml-
>> > access/Overview.html
>> > > Editorial/substantive: S
>> > > Tracked by: RI
>> > >
>> > > Location in reviewed document:
>> > > 3.1.2
>> > > [http://www.w3.org/MarkUp/2008/WD-xhtml-access-
>> > 20080526/#sec_3.1.2.]
>> > >
>> > > Comment:
>> > > It isn't clear that this section has taken into account the
>> > potential
>> > > difference between key codes and the characters that may
result
>> > from a
>> > > key press on a given keyboard. It seems to assume that the
>> > character on
>> > > a key cap == the key code identifier == the character
produced
>> by
>> > > pressing that key == the character that is the value of the
key
>> > > attribute.
>> > >
>> > > This is not always the case when you take into account a
>> variety
>> > of
>> > > keyboards serving various different locales.
>> > >
>> > > Please provide some precision as to how a key attribute
value
>> is
>> > > associated with keyboard events. (Note that this has proved
to
>> be
>> > a
>> > > difficult topic for the specification of DOM3 keyboard
events.)
>> > >
>> > >
>> > >
>> >
>> >
>






Reply via email to