On 12/05/2014 00:46 , Johannes Wilm wrote:
Also this looks good. There seems to be consensus that contenteditable is just not going o get fixed, and so removing the faulty behavior entirely and replacing it with this would be almost as good.
It depends on what you mean by "fixed". It is conceivable that given enough time and energy the current contentEditable behaviour could be made interoperable, but the problem is that even if that happened it seems clear from developers' feedback that it wouldn't do what they want. A lot of the time you would still want to disable a lot of what it does by default and handle it yourself. This is therefore just intended as a way of providing developers with primitives for editing.
Intercepting key strokes is already now possible and probably the best one can do. The one thing where this gets complicated is when typing characters using more than one key stroke. such as ~ + n to make ñ. I am not sure if you include that under the "Some keyboard input handling".
Yes, text input is a hard problem and you can't get away without solving it. We are talking about providing primitives here, so things can be expected to be a little bit hairy though.
DOM 3 Events has something called composition events for the example you bring up (which can get a whole lot more complicated, notably with things like Kotoeri and such). On the face of it it would seem to be the needed part but I've never used them (or seen them used) in the real world. (The quality of browser support is also unclear at this point.) Some cases also require the IME API.
Developers relying on the bare bones cE would probably have to handle the rendering of ongoing composition themselves (which isn't the end of the world, but you need to think about it or you are guaranteed to mess things up). This is probably acceptable at this level, libraries can make it easier.
-- Robin Berjon - http://berjon.com/ - @robinberjon
