Re: [Editing] Splitting Selection API Into a Separate Specification

> On Mar 18, 2014, at 2:22 PM, Johannes Wilm <johannes@fiduswriter.com> wrote:
> 
> 
> 
> 
>> On Mon, Mar 17, 2014 at 4:59 AM, Robin Berjon <robin@w3.org> wrote:
>>> On 15/03/2014 18:44 , Johannes Wilm wrote:
>>> yes btw -- where should one go to lobby in favor of the editing spec? I
>>> have been communicating with several other browser-based editor
>>> projects, and there seems to be a general interest of more communication
>>> with the browser creators and spec writers. Currently the situation is
>>> that it's so broken in all the browsers, that one needs to use a 100%
>>> javascript approach, painting the caret manually and creating a separate
>>> system for selections, to circumvent the main problems of
>>> contenteditable (for example:
>>> https://bugzilla.mozilla.org/show_bug.cgi?id=873883 ). Codemirror is a
>>> good example of that.
>> 
>> My understanding from talking to various people is that at least part of the problem comes from the type of code that is currently deployed in the wild. An awful lot of it works around browser inconsistencies not through feature testing but through user agent switching. This means that when a given browser fixes a bug in order to become more in line with others (and presumably the spec), it actually breaks deployed code (some of which is deployed an awful lot).
> 
> That is interesting. I had not heard that before, but it certainly makes sense in many cases. Some other issues, such as when joining two paragraphs by hitting backspace at the beginning of the second one leading to the two paragraphs not being merged the way one would assume by joining the contents of the two paragraphs, but instead by a number of <font> elements and similar being inserted, don't seem like they would be used by any current editor. It is my understanding that the reasoning behind this is just that A. there is no full and good spec on doing this, so B. everybody waits until there is one with fixing this.
>  
>> 
>> I've been talking with some editor developers and have heard some interesting ideas, notably from the Substance.io people.
> 
> They are also some of those I have spoken to. We share a lot of the same problems as they have, but it is my understanding that they have not yet had to deal with "noneditable islands" or "noneditable islands with editable lakes" and similar items. The CKEditor on the other hand does have to deal with this, as do we.
>  
>> One suggestion has been to make at least the selection API interoperable, which seems achievable. So I'm very glad to see Ryosuke propose it here, I was about to suggest the same.
>> 
>> Another that I've been mulling over is to have something like contenteditable=minimal (bikeshed syntax at will). This would give you a caret with attendant keyboard motion and selection, but no ability to actually edit the content. Editing would happen by having a script listen to key events and act directly on the content itself. The hope is that not only is this a saner architecture for an editor, but it can also bypass most (possibly all, if the selection API is improved somewhat) browser bugs to do with editing.
> 
> This would certainly be an improvement. As it is now, we for example do not use contenteditable for anything else than the caret movement, so if that could be done right in all cases, that would mean a lot. 
> 
> Creating a javascript/contenteditable editor is not that hard, if one only has to deal with the various text formatting and adding functions. The problems starts if one has to get around bugs related to the cursor not moving correctly or not moving at all to certain places (for example between two inline non-editable objects in Firefox). Then one needs to create a fake-cursor, etc. which is a much bigger task and only has been achieved by a very few projects so far.
>  
>> 
>> I reckon a spec for that could be put together relatively easily. I'm still digging through Web editors' code to get a feel for how much it would actually help.
> 
> If it would help, I could help organize a meeting with the various editor creators (Aloha, TinyMCE, CKEditor, Substance.io, Fidus writer, HalloJS, etc.) to discuss this. In my experience, these developers are very interested in getting in contact with the browser makers about this, and haven't always been successful in this.

Understanding the real needs of editor developers would be great.

Would it be possible to have this meeting at this year's TPAC?

- R. Niwa