Re: 2 Proposals for Minimum Viable InputEvent

On 12 Feb 2017 11:23 p.m., "Neil Jenkins" <neilj@fastmail.com> wrote:

On Mon, 13 Feb 2017, at 11:23 AM, Johannes Wilm wrote:

But who are these small, yet production-ready editors?


Hi! Author of Squire <https://github.com/neilj/Squire> here; probably the
smallest production-ready editor (~4600 loc; 15KB minified+gzip; used in
production at FastMail <https://www.fastmail.com> and elsewhere).


Ok, but it doesn't take more than a few seconds to break it without really
trying: On Android, write something, hit bold-button, write something more.
Result: bold-button is activated but the subsequently typed text is not
bold.

I tried a few more tines with the other buttons trying to press and depress
them, typing a few characters and deletibg them again and within a minute I
was in a situation where the state of all buttons was different from what
was happening with the text and I found no way to get out of it.

Maybe having issues like this show up is fine in an app where being able to
editing consistently is secondary to other things such as code size. So
maybe I should have not used the term "production-level" but used a more
appropriate term.

Now this is not a criticism of your work. Squire generally looks really
great and the editor I programmed back in the days gad a lot of similar
isdues.

The thing is, there just seems to be no way to make an editor that works
more or less ok as of today with all the inconsistencies and bugs in
platforms without spending a substantive amount of time on it and for it to
get kind of large.




It does not use execCommand. I agree with all the other authors: the only
sane way for editors to work is for the editor to handle all (or at least
most) of the DOM manipulation. The browser should just tell the editor what
the user wants to do semantically as much as possible, and nothing more.


We totally agree on that!



Neil.