Yep, we do use contentEditable as an input source and also as the view to which we render (you wouldn't be able to reliably handle the keyboard otherwise). I c

Yep, we do use contentEditable as an input source and also as the view to which we render (you wouldn't be able to reliably handle the keyboard otherwise). I covered the "Can't it be avoided?" section in this article a couple of years ago: https://medium.com/content-uneditable/contenteditable-the-good-the-bad-and-the-ugly-261a38555e9c https://medium.com/content-uneditable/contenteditable-the-go... tl;dr: Unless browsers will open for the Web multiple crucial features (such as IME, keyboard, selection, touch, on-screen keyboard, spellchecker, etc.) contentEditable is the only sane way to handle text editing. There's an ongoing initiative to fix this situation but it's an extremely complicated topic. I wrote a few words about it in https://medium.com/content-uneditable/fixing-contenteditable-1a9a5073c35d https://medium.com/content-uneditable/fixing-contenteditable... but later things got even more tricky. Since then I've been on W3C's meeting in Paris and contributed to many discussions about the standards and I can say that this whole topic makes even the most experienced browser people suffer when trying to solve it. Fortunately, 2 years later I can still say that things move forward. E.g. the beforeinput event landed in a couple of browsers.