> On Mar 18, 2014, at 2:22 PM, Johannes Wilm <johan...@fiduswriter.com> wrote: > > > > >> On Mon, Mar 17, 2014 at 4:59 AM, Robin Berjon <ro...@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
