Re: 2 Proposals for Minimum Viable InputEvent

Neil and I have communicated a bit off-list and he has explained to me how
they actually have added iOS mobile support and worked quite a lot on
mobile support in general. That is great and it wasn't my point to say that
Squire isn't a good editor.

What is necessary to point out though is that also Squire is a multi-year
effort by a professional developer [1]. Squire may well have managed to
ccreate an editor with the smallest code size, but it is NOT an editor that
a middle school kid can write in 15 minutes to create a comment box for
their own website. Such a type of tiny editor just does not exist, or to
the extent that people actually do add such editors to their websites, they
will quickly discover that this is not feasible (or they'll spend a year
doing so if their name is Johannes Wilm).

And for the editors that do exist, it should not be too difficult to deal
with say 20 or 30 different inputTypes of the beforeinput event, especially
if that means they don't have to listen to a ton of other events or engage
in other questionable practices. It is precisely the smaller editors that
don't have a built-in DOM-diffing mechanism that would profit the most from
the JS having access to fundamental building blocks and be able to isolate
the IME process instead of having the browser try to be "smart" so that
they end up having to undo what the browser just did.

[1] See https://github.com/neilj/Squire/network

On Mon, Feb 13, 2017 at 7:00 AM, Johannes Wilm <johannes@fiduswriter.org>
wrote:

>
>
> On Mon, Feb 13, 2017 at 5:55 AM, Neil Jenkins <neilj@fastmail.com> wrote:
>
>> On Mon, 13 Feb 2017, at 02:42 PM, Johannes Wilm wrote:
>>
>> 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.
>>
>>
>> You were trying the demo integration <http://neilj.github.io/Squire/> I
>> presume? A reasonable thing to do I admit, but Squire itself has no UI and
>> the demo site was done by an intern 3 years ago; it's not the integration
>> we use in production, and it's using an out-of-date version of Squire. I
>> must find the time to update the demo site with something more production
>> quality.
>>
>
> Right. I have since tried your fastmail, and it looks like richtext
> editing is more or less disabled in the mobile version (one only deals with
> richtext if one starts writing inside a reply to an email that did have
> styling -- and then there are no style buttons, right?). It is reasonable
> to disable richtext on mobile -- gmail seems to do the same in the HTML
> version. But to me it also highlights two issues:
>
> * Creating editors that work on mobile is unreasonably hard. Instead of
> making iOS and Android function differently and continuing the necessity of
> diffing DOm structures, etc., it would be helpful if it we could go ahead
> with the IME beforeinput event as was planned, as that will at least allow
> isolation of IME input and therefore make it easier to support such
> scenarios.
>
> * Richtext editing continues to be mainly a desktop thing in the case of
> many apps. This is where the priority for richtext editng lies. We should
> therefore not make it harder to edit richtext just because things don't
> quite work as expected on mobile yet.
>
>
>>
>>
>> Neil.
>>
>
>
>
> --
> Johannes Wilm
> Fidus Writer
> http://www.fiduswriter.org
>



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