Re: New rich editing roadmap position paper

On Sat, Oct 21, 2017 at 1:36 PM, Johannes Wilm <johanneswilm@gmail.com>
wrote:

> Hey,
> thanks for posting this. Some of us received this a few weeks ago, and
> given that this may change a lot, I have not posted a preliminary schedule
> for the meeting at tpac until now.
>
> My first reaction to this is a bit a mix of:
>
> A) I'd wished you two had participated in the TF more actively in the
> past. That could have helped you guys understand why the TF ended up with
> working on contenteditable the way it has done. It could also have helped
> us understand that Chromium is now heading in a new direction.
>
> B) This seems to say that one should not make great new plans but then
> goes on to make grand suggestions of things that sound like they will need
> a decade to get fully specced and implemented in all browser engines. It
> seems it would be much less work to fix the Android IME to be compliant
> with input events level 2 as it is now, or find an alternative way of
> reaching what level 2 does rather than start with a completely new approach.
>

InputEvents Level 2 isn't designed to solve items B, C, and D which require
a separate solution regardless.  E is a narrow special case of Level 2.  F
and G are pretty small features that might still be useful even in presence
of level 2.

Overall only item A appears somewhat scary/challenging and is also
disproportionately useful for hidden textarea editors and little else.  So
I'd suggest projects B, C, D and E would be practical, uncontroversial
items to spec first.


> C) The approach of using a hidden textarea is not entirely insane. It will
> create some new challenges, such as figuring out vertical caret movement,
> but there are issues with all approaches and this may work for some as it
> already does for Google Docs. However, there are also advantages to
> cE-based approaches and several attempts of making non-cE editors in recent
> years were given up. I don't think it's a good idea for us to take this
> decision for all editor projects. Writing a production-ready editors will
> take several years and many iterations weighing all tge advantages and
> disadvantages against each other and trying things out with realworld
> users. We likely should not think we can replace this process by an
> arbitrary decision we make among ourselves after a 30 minute discussion.
>
> So yes, I'm rather critical. But I think several of the concrete action
> points are something for us to look at.
>
> We should probably put this on the schedule as one of the first items just
> to figure out if it still makes sense for us to continue work on any of the
> things we have been working on so far.
>
> Given that you will be leaving Chromium, will this be the official
> Chromium position going forward?
>

I'd like it to be, but all I have is my "dead man's hand" so that would be
overpromising.  Chromium-team doesn't have a clear process or decider to
define "official Chromium position" on matters like this, at least until
before the Intent to Implement/Ship stage.  It would be fairest to say that
Chromium-team generally favors mobile-first and incremental approaches and
that there is goodwill towards the doc because it attempts to embody that
(as well as a bit of worry because of the questionable history of hidden
textarea editors).


>
> On 21 Oct 2017 22:09, "Alexandre Elias" <aelias@chromium.org> wrote:
>
>> Hi, after I was involved in the IME event level debate, I was asked to
>> formulate my opinion on where I think things should evolve instead, based
>> on my experience with Android IME.  Here is my position paper on that,
>> which I've already passed around to other Chromium-team members and
>> incorporated their feedback:
>>
>> https://docs.google.com/document/d/10qltJUVg1-Rlnbjc6RH8Wnng
>> pJptMEj-tyrvIZBPSfY/edit
>>
>> It's a new approach involving hidden textareas which I believe avoids the
>> pitfalls of previous variants of that idea.  More importantly, each of the
>> individual standardization items should be small, uncontroversial and
>> compatible with other visions -- because I don't expect or want to force
>> everyone to hidden textareas.  Basically, it's a way of framing small
>> practical subprojects in a way that they appear as incremental steps
>> towards eventually enabling a full Office-style text editor.
>>
>> One more note: I'll be leaving Chromium-team at the end of this month so
>> I unfortunately won't be able to defend the position at TPAC.
>> Chromium-team editing folks have mostly been positive about this roadmap,
>> but are still overall debating how and how much to invest in editing, so
>> I'm putting this paper out there as a starting point for future discussion
>> that I won't be involved in.
>>
>