Keybindings are currently specified using event.keyCode values, but that is considered a deprecated API, because (among other things), it's not possible to represent certain input events in a cross-platform and locale-independent way (e.g., how to bind to the @ character?). Though overall support for the replacement event.key is only at 60%, for the non-mobile, non-mac userbase it's much higher, so it would be nice to be able to use this API for Quill keybindings.
I think supporting both .keyCode and .key handlers would be relatively simple: add a .keyCodeBindings map to Keyboard and update Keyboard.listen to check both binding maps. (.keyCode bindings would be called before .key bindings). Keyboard.addBinding would also have to change to handle .key bindings. We could add a useKeyCode property (default true) to binding definitions that would toggle between the two.
Thoughts? Happy to take care of this if there's interest and agreement on the API changes
Edit: It appears support for keyCode has landed in webkit nightly!
I would prefer to support one or the other, not both as that would make the API confusing and complex. Once adoption of key hits all of Quill's supported browsers, we can take another look.
How to bind to the @ character cross platform then ?
@jhchen event.key is now at 85%. Perhaps we can move towards now?
@jhchen We are also in need to implement the @ character mapping. What about adding an abstraction layer transparent to the current API which handles the @ character independently? This way we can maintain the current behaviour, have a workaround for the @ symbol now, and switch to the new API in a future version where breaking legacy compatibility will be more appropriate?
First the criteria is 100% of all platforms Quill supports, not some arbitrary percentage point. There is no second class citizen or platform--either Quill supports it or Quill doesn't, and if it does then 100% of features Quill purports to have must work on these platforms.
That being said the caniuse graph does indicate all of the platforms Quill supports has added key so I will spend sometime investigating the reliability of this information and if true move towards using key. Because of how current key binds currently are documented to work and semver, this will be a major version bump when this happens.
This would be very helpful. I wouldn't mind using an experimental branch or strict: false so that a major version bump can be delayed.
Closing this as the PR is merged and in the 2.0 branch.
Most helpful comment
How to bind to the @ character cross platform then ?