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

I would think that would be a great idea. We would need to contact the
different editor development teams and see if that works for them.


On Fri, Mar 21, 2014 at 2:12 PM, Ryosuke Niwa <rniwa@apple.com> wrote:

>
> 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
>



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