[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.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
RE: [ACTION-47] Re: [XHTMLAccess] i18n comment 2: Keycode or character
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.pember...@cwi.nl] Sent: Wednesday, March 11, 2009 7:40 AM To: Steven Pemberton; Phillips, Addison; ish...@w3.org; www-html- edi...@w3.org; public-i18n-c...@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.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
