Open Bug 70630 Opened 20 years ago Updated 7 months ago
reduce keybindings by allowing modifiers to be ignored
We could reduce the number of keybindings we need to specify if we could use "ignore*" in the modifiers attribute. These variants would ignore the state of that particular modifier key for the purpose of matching. I think we should add the following (or some similar set) to possible values for the modifiers attribute: * ignoreAlt * ignoreShift * ignoreControl * ignoreMeta These could be used with any other values in the modifiers attribute except the modifier. If "alt,ignoreAlt" were specified, the keybinding would be bad and shouldn't match anything (imo); it should probably be ignored and not maintained. An example where we could use these in keybindings is in single-line editfields (input): Pressing Home+Control should do the same thing as just Home Rather than defining a key for "home" and another for "Home + Control", we could just define one with "ignoreControl"
I don't want to do this. It runs counter to the concept of filtered handlers that is specified in the XBL spec.
It would be cleaner to do this with a separate ignore attribute that took the same values as modifiers, e.g., <key keycode="VK_HOME" ignore="control"/> How many duplicate keybindings are you having to define anyway? I can't believe that this is that big a problem.
The issue comes up on punctuation keys a lot, since you never know whether a punctuation key (e.g. +) is going to be shifted or unshifted; so right now, we have an accel-+ binding that has to be done three times, for accel-+, accel-shift-+, and accel-= (the most common unshifted item below shifted plus). We've also hit this on keys like home/end, return and delete, where users get upset that the key doesn't do what they expect when a modifier is pressed, so we end up having to define several combinations of bindings for some of these keys, and we're often having to add small bugfixes for combinations that no one thought of or thought people would hit. Would the ignore= syntax also run counter to the filtered handlers idea? (I don't understand the conflict, but I don't want to add something that you think would be inconsistent with the spec.)
Status: NEW → ASSIGNED
ignore= would be acceptable.
cc'ing jesse, I think this is a better solution than the shift special-casing idea.
Summary: reduce keybindings by having "ignore*" modifiers → reduce keybindings by allowing modifiers to be ignored
i like the ignore= idea.
This will require modifications to many files and will require coders to add ignore="shift" to many future keybindings. Shift is usually ignored (when no other keybinding exists) whereas other keys are ignored infrequently. Still, this is a more general solution. (This bug for ignoring shift is bug 70140.)
We don't ignore shift now (though bug 70140 was a nice idea and I can certainly understand why it was filed) so no existing key bindings would have to be changed if this ignore= were allowed. It would give us the opportunity to coalesce several existing bindings which are defined both with and without shift, however. It also provides a mechanism for the feature requested in bug 70140 to be implemented, if that were agreed upon; with the current code, I think that bug would be very difficult to implement.
please open a discussion in the accessibility newsgroup on bug 56775 vs this one. I know this bug is assigned, but please don't implement yet. bugs to be discussed: bug 139106, bug 70140, bug 91094, bug 56775
Component: Keyboard: Navigation → User events and focus handling
You need to log in before you can comment on or make changes to this bug.