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 rn...@apple.com wrote:
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
--
Johannes Wilm
Fidus Writer
http://www.fiduswriter.com
