Re: contentEditable=minimal

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

Received on Monday, 12 May 2014 16:27:06 UTC