As observed in PR #196,
Handling the intersection of custom shortcuts with interactive elements in a reliable way is challenging e.g. custom peripherals being arbitrary, you may, or may not want to preventDefault in an input for instance.
Let’s imagine one of your shortcut is just key b for bookmarking or ArrowRight for navigating, you do not want this to preventDefault() and trigger the peripheral event if an input is focused, for obvious reasons. But some other shortcuts like IDK, zooming, you want to preventDefault() even if an input is focused.
The complexity being event is not clonable through window.postMessage so you cannot preventDefault() in the host app.
Adding interactiveElement to the data sent can probably help observe how much that happens, but at this point it is already too late, you cannot “unprevent” the event.
Attempts at smart-ish heuristics for contextual prevention helped surface possible corner/edge cases, especially with inputs because well, on some platforms, you achieve some accented letters or special characters with a combination that may be a custom shortcut at the same time, so it is very difficult to handle this properly, in a manner that makes sense to the person who customised peripherals.
That also begs the question of what we should be doing with inputs, etc. in the first place. In EPUB there has been quick discussions in the past, as other reading apps are disabling them as you can send form data with them. And we protect a lot of other stuff anyway.
On Web, this is not sustainable though, especially if we make it an alternative for interactive publications.
As observed in PR #196,
That also begs the question of what we should be doing with inputs, etc. in the first place. In EPUB there has been quick discussions in the past, as other reading apps are disabling them as you can send form data with them. And we protect a lot of other stuff anyway.
On Web, this is not sustainable though, especially if we make it an alternative for interactive publications.