-
Notifications
You must be signed in to change notification settings - Fork 23
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove the use of printable character from accessKey attribute. #158
Comments
I suspect that what they mean is a character that has a visible shape when printed, ie. not a space or other invisible character. |
If specified, the value must be a single grapheme: a string that contains a sequence of graphical Unicode code points. Typically, this sequence will contain a single Unicode code point, but there may be cases where multiple code points are needed to generate the single grapheme. |
Here is my suggested updated text and example: If specified, the value must be a single grapheme: a string that contains a sequence of Unicode code points. Typically, this sequence will contain a single Unicode code point, but there may be cases where multiple code points are needed to generate the single grapheme. For example, on the Hindi INSCRIPT keyboard layout on Windows the TRA key (on number 6) when pressed generates the following Unicode code point sequence: U+0924 (TA) + U+094D (Virama) + U+0930 (RA). |
Steve, i've been pondering. I suppose the first question in my mind is why do they want to restrict to a single character at all? Do you have an idea? Perhaps that's the first question. I could see that it's useful general advice for authors to choose simple key events, but this seems to suggest that there's a practical reason that it must be one character only, but that reason doesn't seem to be evident. Your para above starts out by saying 'must' in the first sentence, but then offers an alternative, which won't fly. It should say 'should' in the first sentence. |
The reason to restrict to a "single character" is not for presentation but because the accessKey is the mnemonic keystroke used for keyboard shortcuts/keyboard access to form fields. It has to be visible in order to show it to the end user and typable as a single keystroke (non-composing). These are, however, usage requirements, not necessarily a technical restriction that Validator can/should check for. In teleconference we had extensive discussion of what keys are present in single-press configurations on keyboards for various languages. The limitations here really are split between those that HTML can impose on the format ("validatable") and practicality for page authors ("typable"). The surrounding text in the section already makes this clear. So I'd suggest, given that this is supposed to be a keystroke, maybe something slightly different:
|
I am not really sure what their real motivation is for limiting the input to a single Unicode code point. My guess is that they just want to make this a simple mechanism for inputting key accelerators. I am ok with the suggested text: If specified, the value must consist of a string representing an available keystroke. For most languages, this will be a single printable Unicode code point. I will give them the Hindi example as justification for why we are uncomfortable with their single Unicode code point restriction. Let me know what you think. |
sounds good. Btw i was just chatting with Addison, and he and i are saying the same thing here. Addison is probably saying a little better than i did. I like his proposed text. |
whatwg/html 6.5.2 The accesskey attribute states as "one code point in length":
discussion in this issue need to be considered for issue/proposal for whatwg/html. |
I propose we close this tracker (issue already closed) in favour of issues being prepared for the WhatWG spec. |
Agreed to close during telecon. |
§ w3c/html#485
5.5.2 The accessKey attribute
http://www.w3.org/TR/html51/editing.html#the-accesskey-attribute
The accessKey attribute is now defined to be a single Unicode code point with it being a single printable character. We should remove the use of single printable character as there are many Unicode code point sequences that result in a single printable character. If the specification wants the accessKey to be limited to a single Unicode code point, then we should just say that. My guess is that what they really want to say is that the character must have the Unicode printable property.
The text was updated successfully, but these errors were encountered: