NOTE: The current preferred location for bug reports is the GitHub issue tracker.
Bug 502 - add datatype checking for value of accesskey attribute
add datatype checking for value of accesskey attribute
Classification: Unclassified
Component: Datatype library
All All
: P2 normal
Assigned To: Michael[tm] Smith
Depends on:
  Show dependency treegraph
Reported: 2009-05-03 16:40 CEST by Michael[tm] Smith
Modified: 2009-05-26 18:40 CEST (History)
1 user (show)

See Also:

patch with proposed change (4.30 KB, patch)
2009-05-07 11:45 CEST, Michael[tm] Smith
updated patch, allowing surrogate pairs (3.41 KB, patch)
2009-05-26 18:27 CEST, Michael[tm] Smith

Note You need to log in before you can comment on or make changes to this bug.
Description Michael[tm] Smith 2009-05-03 16:40:02 CEST
The spec states that the value of the accesskey attribute "must be an ordered set of unique space-separated tokens, each of which must be exactly one Unicode code point in length".
Comment 1 Michael[tm] Smith 2009-05-07 11:45:32 CEST
Created attachment 100 [details]
patch with proposed change

As always, not sure if the particular approach is this patch is the best way to implement this. But I tested it and it does work as expected for the tests I used.

I'm also not sure if the error messages are optimal or in line with existing conventions. In the error messages, I used "key label" rather than "token" or whatever else. Although "key label" is not used in the spec in that way, it seems like it will be clear enough to users in the context of the error message. I considered using "item" instead, but "key label" seems better to me. Certainly seems better to me at least than "value" or other alternatives. But I'm happy to change it whatever seems best.
Comment 2 Michael[tm] Smith 2009-05-08 11:06:14 CEST
also, I guess it's worth mentioning that the sort() causes the first-in-alphabetical-order invalid (duplicate or mult-character) item in the value to get reported (instead of the whatever the first invalid item is in the original document order). which could be potentially confusing to users, I guess. only other useful way I can to handle the reporting better would be to maybe just walk through the array of items as now, but instead of throwing on the first invalid one, put it and any subsequent invalid items into a collection, the throw with the whole list of them after.
Comment 3 Henri Sivonen 2009-05-20 11:20:08 CEST
> if (label.length() > 1) {

If length() == 2, you should check if there's a high surrogate followed by a low surrogate and allow that.
Comment 4 Michael[tm] Smith 2009-05-26 18:27:31 CEST
Created attachment 101 [details]
updated patch, allowing surrogate pairs
Comment 5 Michael[tm] Smith 2009-05-26 18:40:01 CEST
syntax r428