Re: High-level use cases of editing TF, 2nd try

Hey,
yes we should definitely hear more from Google Docs and the Ms Office
online team. Benjamin Peters reported some feedback from the MsOffice team
which influenced the spec about a year ago, and at the only voice meeting
we spoke about that again. But as I recalled it, BPs initial plan had been
to not allow IME input at all in version 1.0 or to only allow it in a
separate box, but that he had been told that even for version 1.0 we need
inline IME-support. I don't recall JS-based IME-handeling having been on
the table at that stage. My understanding was that he was also going to
speak to Google Docs, but I am not sure whether that actually happened.

As for the two types of editors:

The following is my personal, somewhat subjective analysis of the current
state of things. Some of it is based on technical things, but a lot is more
of a view of trends in browser based editors.

I think Koji is right in that there have been these two types of editors on
the web -- more complex and less complex. But the division is not quite as
clear as one may think:

1. While the complex one uses little contentEditable, in the end noone gets
around using at least some contentEditable. I think Google Docs uses a
hidden contentEditable field for pasting or some such thing. That's also
what I know from other editors.

2. "Simple editors" end up not really working at all. It seems to be a
common phenomenon that someone creates a tiny little library that is
supposed to just sit on top of contentEditable and connect it to jQuery as
a series of plugins (or some such thing). One then discovers that A, B and
C doesn't work and has to redo it. And before one knows it, 10 years have
gone by, one is releasing the 5th complete rewrite and even though the goal
of the editor is still to be just basic and simple, it is now a fairly
large library   that handles paragraph merging, etc. and even though it
does all that and one has a few thousand tests in place, there are still
lots of ways to break it.


The people we have been talking here from the JS side have been in the
business of 2. It's editors like CKeditor and TinyMCE which can be added to
your Wordpress site to allow comment functionality or some such thing. Now
the are tow of the editors that have been developed the most and therefore
have grown that large. Every few months one will find some new project that
tries to create the tiny editor
that "requires almost no dependencies and fits in under 500 bytes" which
will end up either having to go through the same ten year process and grow
just as large, or give up.


And because these editors for simple things in reality need to implement
just about everything one needs in Wordprocessors, they seem to be heading
towards also allowing usage that looks more and more like fullscale online
document editors.

As for the usage of contenteditable: That varies, and the relationship is
not as simple as simple editor = 90% contentEditable, complex editor = 5%
contentEditable. Most of the editors use cE for quite a lot, all have to
use it for some things. There have been varies attempts at making editors
where contentEditable is not used for the caret with somewhat different
ideas. Among the most known are:

-- The Aloha Editor 2.0: Tried to build it's own caret on top of the
browsers selections. Tries to be "simple" and not have a distinction
between the document model and the view in the browser. Development seems
to have halted in April or so, and one can see they have run into issues
with mobile, etc. . I don't know if they even attempted IME, but it's not
working.

-- CodeMirror: The code editor that can be used as a richtext editor was
known for a long time as contentEditable-less editor that was stable and
had separation of model and view. But surprise-surprise: a few versions
ago, contentEditable was reintroduced at least for some platforms. And for
proseMirror, the new richtext project by the same developer, he chose to go
contenteditable, the reason being, AFAIU, that with IME and on mobile it
seems almost impossibel to get it to work right using anything else.

So my conclusion: While it seems like one can draw a clear distinction
between those apps that allow for simple commenting using contenteditable
and dedicated online word processors that don't use contenteditable, in the
end the distinction is not as clear.


On Sat, Oct 24, 2015 at 8:54 PM, Koji Ishii <kojiishi@gmail.com> wrote:

> I failed to discuss high-level goals and use cases in my previous try.
> Allow me to try again so that we could discuss this next week. Without
> doing this properly, I think we waste a lot of time just to understand
> each other.
>
> Last year I heard that there are two different use cases of "editors
> on the web":
>
> 1. Online word processing service, such as Office Online or Google
> Docs. These are large JS, usually use its own model and editing HTML
> is not its primary target.
> 2. Editor framework, which web developers can plug it into their web
> pages and provide rich editing on, for example, forum pages.
>
> This TF primarily targets use case 2, because use case 1 is harder and
> takes longer. Also, most use case 1 products today are built without
> using contenteditable very much anyway, so we didn't hear much
> requests to work on.
>
> What I understand from Johaness's use case is that we're focusing on
> use case 1 now. It probably means that we'll disregard use case 2.
>
> I admit that I originally had a bit allergic response to the change.
> After some thoughts, the change looks ok to me if all TF members and
> editing framework developers are in consensus moving their framework
> to use case 1. It means that the use case 2 disappeared.
>
> So I'd like to confirm us that:
>
> 1. Are we changing our target use case from 2 to 1?
> 2. Are we in consensus that use case 2 is no longer important for this
> TF to work on?
>
> If yes to both, I'd like to hear more from Office Online and Google
> Docs people before we move on to discuss solutions. They have built
> it, so they should know problems and pitfalls better than we do.
>
> We did some in the past. I heard that the move from ce=events to
> ce=typing was a request from MS Office team because it's too hard for
> JS to handle IME correctly. But I didn't do it really seriously
> because I assumed that they're out of scope at least for the first
> level of the work in this TF. I would like to revisit them if our
> target use case was changed.
>
> /koji
>
>


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