Are you referring specifically to option 1, handling keyboard events in Elm here? Or do you think this also applies to 2 and 3?
I think this applies regardless – if you want to get the benefits of using contenteditable, you want to get away from keypress events as much as you can for all the reasons outlined in the medium post. The idea of capturing user intent is what beforeinput and input get you – check out Input Events Level 1
I think we discussed briefly on Slack, and you were in favour of using
contenteditable? CodeMirror does also usecontenteditableand its a config option (CodeMirror 5 User Manual - Search for the ‘inputStyle’ option).
I think using contenteditable directly lets you leverage the most native capability from the browser. If you’re at Google writing the next Google Docs, do whatever you want, you have ~infinite resources, otherwise use contenteditable 
I think contenteditable would need to be wrapped as a custom element to work with Elm? Since it changes the DOM, it would not play nicely with virtual-dom otherwise. But that isn’t such a huge problem, elm-rte-toolkit 1.0.4, is for contenteditable and it just tells you in the README where to get the npm package for the implementation.
[/quote]
Yep, that is the drawback of contenteditable from Elm.