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

That's great! Many thanks.

Steven

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

Received on Wednesday, 11 March 2009 15:15:57 UTC