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

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.


>
>
> --
> Robin Berjon - http://berjon.com/ - @robinberjon
>



-- 
Johannes Wilm
Fidus Writer
http://www.fiduswriter.com