Re: The web doesn't need another poorly implemented API

> 1. There is no way that browsers will implement such a complex API in a
reasonably consistent manner.

First of all, there's no so much API to be implemented, because modular
approach to cE limited the scope. Second, the whole "editing" thing is
highly platform specific (it depends on OS, device, browser and other
components) and the new API takes that into consideration. It's going to
reduce the complexity with which you'd have to deal if you tried to
implement cE from scratch in JS. If that was possible at all...

> 1. It is possible to write client code that implements all of this,
without using any contentEditable at all.

No, it isn't possible currently. And there's a very long way to go before
it'd be possible. I've written an article to explain exactly this situation
–
https://medium.com/content-uneditable/contenteditable-the-good-the-bad-and-the-ugly-261a38555e9c

> After dealing with current `designMode` and `contentEditable`
implementations, I can tell you, they are bad. But you know that. What
guarantees that implementations of this will be any different?

Because:

* they will be based on a spec, the current ones are based on personal
preferences,
* the spec is a result of discussions between browser developers and editor
developers,
* all of us (or at least majority) believe that cE is necessary.

On Tue, Sep 8, 2015 at 9:05 PM, Olivier Forget <teleclimber@gmail.com>
wrote:

> > 1. It is possible to write client code that implements all of this,
> without using any contentEditable at all.
>
> Yeah but these are by necessity very hacky and usually leave some edge
> case (or several) poorly handled: IMEs, bidi text, OS-based special
> character insertion, etc...
>
> Not saying it can't be done, just that it's not a nice solution. CE=Typing
> (or whatever we're calling it now) should allow for more well-rounded
> editors with less brittle code.
>
> Nobody is going to force you to use CE. Just ignore it if you don't like
> it. Some of us don't want to leave editing on the web the way it is and are
> attempting to do something about it. You've made your point but I don't see
> this conversation being productive going forward.
>
> - Olivier Forget
>
> On Tue, Sep 8, 2015 at 10:33 AM Johannes Wilm <johannes@fiduswriter.org>
> wrote:
>
>> Ok,
>> you may not be trolling, but I don't think your comment is in any way
>> constructive. We haev started with the first steps of getting toward
>> speccing contentEditable. A process that may last up to several decades to
>> be entirely done.
>>
>> Nothing guarantees that these implementations will be different, but
>> there is some likelihood for that happening because the current specs are:
>> A) much simpler than full cE=true and therefore much easier to get to
>> work similarly across browsers
>> B) actually in writing
>> C) coming out of a process involving all the main JS editors and all the
>> main browsers
>>
>> I propose we close this discussion topic as it will lead nowhere.
>>
>> On Tue, Sep 8, 2015 at 5:53 PM, Shahar Or <mightyiampresence@gmail.com>
>> wrote:
>>
>>> Under minor trolling accusations (
>>> https://github.com/w3c/editing/issues/88), I reiterate here:
>>>
>>> There is no need for such an API. I feel that the contentEditable stuff
>>> should just be deprecated.
>>>
>>> For two reasons:
>>> 1. There is no way that browsers will implement such a complex API in a
>>> reasonably consistent manner.
>>> 1. It is possible to write client code that implements all of this,
>>> without using any contentEditable at all.
>>>
>>> After dealing with current `designMode` and `contentEditable`
>>> implementations, I can tell you, they are bad. But you know that. What
>>> guarantees that implementations of this will be any different?
>>>
>>
>>
>>
>> --
>> Johannes Wilm
>> Fidus Writer
>> http://www.fiduswriter.org
>>
>


-- 
Piotrek Koszuliński
CKEditor JavaScript Lead Developer
--
CKSource - http://cksource.com
--
Follow CKEditor on: Twitter <http://twitter.com/ckeditor> | Facebook
<http://www.facebook.com/ckeditor> | Google+
<https://plus.google.com/107736718646302128806> | LinkedIn
<http://www.linkedin.com/company/cksource>