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