- From: Al Gilman <Alfred.S.Gilman@IEEE.org>
- Date: Sun, 29 Aug 2004 12:10:48 -0400
- To: Anne van Kesteren <fora@annevankesteren.nl>
- Cc: www-html@w3.org
At 12:13 PM +0200 8/28/04, Anne van Kesteren wrote: >>We might want to go so far as to define content markup (XHTML 2) >>along the lines of [workalike syntax, not literal syntax proposal...] >> >><event> >><label>Nex<key>t</key> message in Thread</label> ... >></event> >> >>This would give a clear indication of which instance of the letter >>'t' in the label content should (unless the stylesheet is overruled >>in the client processing) be the one styled in a distinguished way to >>convey the hotkey code to the visual user. > >Such a thing was suggested on the WHATWG mailing list as well. I >can't find the mail right now but it had i18n issues. Japanese or >Chinese characters are created by typing in multiple characters on >the keyboard iirc. Thank you, Anne. The overriding defense, here, is that the actual UI would not be hard-wired to the nomination in the content. That provision is required in order to enable downstream re-bindings necessary or convenient for multimodal and disability delivery contexts. This actually helps with the i18n issues. But the i18n issues are not, given this outer author-proposes, user-disposes protocol, a major problem in the end. All interaction nominations by the author are guessing some delivery context or another. There is no global keyboard, and Kanji are just the extreme case. The point is that if the author's initial version of the menu prompt was in Kanji, then they would have a keyboard in mind and either use Ruby to add a single-keystroke alternate that was the hotkey or accept the typing burden but mnemonic advantages of using the Kanji as the shortcut. Also a writer in a Kanji-using langauge, but understanding that they were dealing with a diversity of keyboards, might select the Kanji character as the level of 'key' nomination (in the database sense) and leave it to the User Agent to either allow multi-keystroke shortcuts (likely in this context) or to provide a mapping of yet-shorter-cuts to the Kanji 'keys' offered by the author. The author would provide what they thought was a labor-saving way of triggering this action, given some assumptions about the keyboard implementation of that language, and the User Agent (including the assistive technology, if loaded, if done right) would have the option of providing the user with an alternate. A precedent for this is available in the XForms Recommendation. Reference: find by string searching 'accesskey' in: http://www.w3.org/TR/xforms/index-all.html Not that making this nomination of "an index symbol mnemonically linked to the label" is absolutely required to happen in the format contributing the label text. The author could bind an input symbol in a stylesheet and designate the first, second, or whatever intstance of that text pattern in the label as what to highlight in the rendered content using XPath-based selectors. This could be viewed as more logically consistent, as the display differences in that view actually coaching the user on the views-layer shortcut binding, not the label itself. But one can't entirely separate these two because the user's ability to recall the hotkey will be improved by presenting the information about the hotkey inline in the label. On the other hand, one might be tempted to think that letting the author do this inline would be more readily understood by the authors and result in less broken style codes and less motivation to ignore the "right way" and do something else. We are left making judgement calls about how much separation between content and presentation is supportable in actual practice. For the moment I am inclined to say that having one label in one language and one key in one keyboard (that is used for that language) inline in the 'content' is not unreasonable, so long as the format specification make it clear that use of a translated label or a substitute UI-event (as required) is all part of the plan. Al >-- > Anne van Kesteren > <http://annevankesteren.nl/>
Received on Sunday, 29 August 2004 16:21:20 UTC