- From: Steven Pemberton <steven.pemberton@cwi.nl>
- Date: Wed, 11 Mar 2009 16:15:42 +0100
- To: "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>
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