Skip to content
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

Normalization and accesskey #1023

Closed
r12a opened this issue Sep 21, 2017 · 6 comments

Comments

Projects
None yet
4 participants
@r12a
Copy link

commented Sep 21, 2017

5.5.2. The accesskey attribute
http://w3c.github.io/html/editing.html#the-accesskey-attribute

Decomposed characters in Normalization Form D, such as accesskey="ñ" to assign ñ as a shortcut, are not valid values, and in many browsers no shortcut will be assigned. Characters in Normalization Form C are valid values. Printable characters that may represent more than one Unicode code point, such as accesskey="श्र", are valid values.

I can't see why ñ would be invalid while श्र is valid. They are both just sequences of characters.

Perhaps what the spec is trying to say is rather along the lines of the following?

Normalization is not applied when keys are matched against accesskey values, ie. decomposed characters such as accesskey="ñ" do not match keys that produce the corresponding precomposed character, ie. accesskey="ñ" (ñ). Accesskey values that contain more than one Unicode code point, such as accesskey="श्र" (श्र), are valid values, although they will only match keys that produce the same sequence of characters with a single press.

There may however also be an issue related to the fact that some keyboards may not produce the same normalised form as used in the accesskey value, while other keyboards do (i'm thinking Vietnamese, for example). If this is true, we may need to require, instead, that normalisation take place before matching keyboard results with accesskey values.

@chaals

This comment has been minimized.

Copy link
Collaborator

commented Sep 22, 2017

The spec is trying to say something like what you outline above.

I've been trying to align the spec with observed reality, less than expect browser developers to actually produce something better, since they have shown a long-standing unwillingness to improve their implementations.

@andjc

This comment has been minimized.

Copy link

commented Sep 23, 2017

@chaals maybe it needs a health warning for Web developers that depending on language, implementations may not work as expected.

@chaals chaals self-assigned this Sep 24, 2017

@chaals

This comment has been minimized.

Copy link
Collaborator

commented Sep 24, 2017

@andjc I think it would be helpful to clarify in more detail that implementations may not work as expected anyway. The whole thing is a "best effort", without explicit requirements. Sadly, there are very few good implementations. Given that this has been raised, I'll have a go at actually fixing it in the spec.

@r12a

This comment has been minimized.

Copy link
Author

commented Sep 25, 2017

Chaals, not sure whether you've seen it, but there are some tests and results at https://www.w3.org/International/tests/repo/results/accesskey.en.html (no normalization tests though).

(I did those partly because i think the tests you produced may not be accurate - mainly because you combined several tests on one page. Also, these tests are in WPT format.)

chaals pushed a commit that referenced this issue Jan 28, 2018

chaals
Clarify accesskey
fix #1012 , #1023

Editorial.

Clarify the suggestions to authors.

LJWatson added a commit that referenced this issue Jan 30, 2018

Clarify accesskey (#1159)
* Clarify accesskey

fix #1012 , #1023

Editorial.

Clarify the suggestions to authors.

* Whoops. Commit changes

(missed some of the changes made)

* Added Russian language markup, corrected Capitalisation.

* Capitalisation fix

* fxi typo
@chaals

This comment has been minimized.

Copy link
Collaborator

commented Jan 30, 2018

closed by #1159

@chaals chaals closed this Jan 30, 2018

@aphillips

This comment has been minimized.

Copy link

commented Feb 4, 2018

I'm concerned that the changes here haven't really nailed this issue down. There is a recommendation against using characters in NFD as accesskey values because "many browsers won't assign an accesskey". Of course, NFD is one way in which characters might be decomposed by a keyboard or by a user. The problem here, as I see it, is to match what keyboards produce and what browsers expect to match. In an ideal world, users could press a key and have it match any equivalent accesskey value and the browser take care of normalization form and other trivia.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.