Further developer guidance regarding political status of Level 1 (for Mozilla, Microsoft) and Level 2 (Google)

[js-choi]

The split between Level 1 and 2 appears to have occurred about twelve months ago, at about 2017-02, when the Android team objected to an impedance mismatch (see a 2017-02 proposal by Alexandre Elias of Chromium et al.). Shortly before 2017-02, Apple implemented both Level 1 and 2; shortly after 2017-02, Google implemented only Level 1; Microsoft’s and Mozilla’s commitments to implementation are uncertain.

On 2017-10, @johanneswilm said in https://github.com/w3ctag/design-reviews/issues/173#issuecomment-340883576:

[There are currently] rapidly changing political circumstances around the specification. An opinion paper was recently launched by Alexandre Elias [et al., in 2017-10,] which presents a very different view [on rich-text editing than from Input Events Level 2], and it is unclear to as of this date to what degree it represents the view of the Chromium team as a whole. Should this be the view of the entire Chromium team, then we will likely have to roll back expectations of finding consensus on level 2 or 3 of the spec. I have not been successful in getting a good answer to this, but I hope to obtain more information during TPAC [2017, held some weeks after this message].

@johanneswilm also pushed a commit with a detailed explanation of the political situation with regard to Apple and Google at that point on 2017-10.

One month later, on 2017-11, @johanneswilm added in https://github.com/w3ctag/design-reviews/issues/173#issuecomment-346167575:

We did get clarity I think [at TPAC 2017 from the Chromium team, regarding its plans for Input Events]. If this is something [the W3C TAG is] interested in, I'll be happy to chat with [the W3C TAG]. In short, the document [by Alexandre Elias from 2017-10] is more a summary of various ideas [he] had. The document has value in that it documents historic ideas existing at one time, and it may in the future inspire new standards, but given there is currently no plan to make specs of all of it, so level 2 continues to be the current state of where the discussion has gone. Hopefully the Chromium team will be able to clarify soon whether they support it or propose an alternative.

As a developer of a rich-text editor, I am glad that these specifications are being written, but I am uncertain to what extent should I design a text editor to match either of the level's models. After all, Level 1 and Level 2 require significantly different approaches on the part of the text-editor developer. It is difficult to progressively enhance or polyfill from Level 1 to Level 2. It is thus important for the developer to know how confident the prospects are for Level 2’s eventual cross-browser implementation before relying at all on its capabilities, even polyfilled.

But today, in 2018-02, there is little existing guidance for the developer regarding the political prospects of these proposals. The most recent update comes from the readme at 2017-10, before the WebKit–Chromium discussions at TPAC 2017. The most recently published browser-vendor article seems to be the WebKit blog announcement from 2017-01 by @whsieh—from merely a few weeks (?) before Chromium’s split, becoming rapidly out of date after its publication (it still links to Level 1, despite its demo relying on Level 2). Chrome Platform Status’s entry similarly does not even distinguish between Level 1 and 2, despite its being last updated on 2017-08; Chromium bug 585875 also makes no mention of Level 2, being marked as resolved in 2017-04, when its Level 1 implementation was enabled by default. Caniuse, of course, can offer the developer no further guidance in the absence of other public information (cf. Fyrd/caniuse#3165 and Fyrd/caniuse#4003). There is not even yet an entry on MDN for the beforeinput event (Mozilla bug 1399643 and Mozilla bug 1387770)—though MDN’s InputEvent entry has been updated to refer to Level 2, but with no other developer guidance.

Even Level 1 is uncertain, due to the absence of implementation from Mozilla and Microsoft. Of course, representatives from Microsoft such as Ben Peters have participated in input-event discussions since 2014 or earlier and more recently in 2016-01. And Mozilla has bug 970802, which shows some sporadic recent activity. But it is uncertain to what extent the Firefox and Edge teams support the specifications’ current drafts and commit to their implementation, for even Level 1.

It's uncertain for the developer whether they should even be uncertain. After all, perhaps there have been, hopefully, indeed recent productive discussions occurring between the UA developers—especially the WebKit and Chromium teams since 2017-11—behind doors. Therefore:

In the past three months, since the last update to the readme in 2017-11, how have prospects changed for consensus on the current Level 2 draft between the WebKit and Chromium teams, including the Android team?

And relatedly, have Mozilla and Microsoft expressed any opinions on the specifications as currently written, even Level 1? May a developer have a reasonable expectation that Mozilla and Microsoft will join Apple and Google in Level 1’s consensus and implement Level 1 in Firefox and Edge?

Ideally, both this repository’s readme and MDN would be updated with any answers and guidance for developers, regarding Level 1’s and 2’s current political reality.

[johanneswilm]

@js-choi Patience :) At TPAC 2017, we heard Microsoft mention they were looking at implementing level 2. The Chromium editing team recently lost Alexandre who had written the position paper and it is still not clear to me whether they have managed to get a full replacement. They did not have anyone responsible for contenteditable at the time, and until they have that, it is unlikely they have the resources to implement level 2. As I understood it, they could not commit to level 2 at this time, but they did not really have a sustainable plan for planning and implementing an alternative way of stabilizing text editing either.

[johanneswilm]

The current hold-up for this spec to move further in terms of process is that the static ranges spec we are referencing needs to be moved to become an official W3C document in some way. In early December it was tried, but there was no consensus on that. Now instead we are trying to get it in as a pull request to one of the DOM specs that have official status already. Process may not mean a lot, but then again, it may be that last little bit that makes the difference for some fo the browsers on deciding what to do.

Given that contenteditable as of today is such a mess that you effectively need to target all four browsers individually, it is a hope that level 1 and 2 are somewhat useful even now in specific cases where Webkit/Blink needed to be targeted specifically due to bugs in their default behavior while the other browsers didn't have that same problem.

[js-choi]

Excellent; thank you for the news. Hearing about Microsoft’s positive signals at TPAC 2017 is particularly encouraging. Hopefully Microsoft, Mozilla, and eventually Google will give further, definite public signals of their commitments to implementation, especially after the specifications formally advance further.

I am a huge fan of what you all are doing, and I wish you luck on advancing both Static Ranges and Input Events.

[js-choi]

See also w3c/staticrange#12, whatwg/dom#589, whatwg/dom#590, and whatwg/dom#591 for related specification issues, and see also “How to feature detect Input Events Level 1 or 2 support” on Stack Overflow for an example of another developer dealing with the differences between Level 1 and 2.

[js-choi]

As an update to any other lay readers, it looks like Mozilla does not currently plan to implement Level 2 in Firefox due to, if I understand correctly, concerns about backwards compatibility with existing IME software. @masayuki-nakano gives some more information in https://github.com/facebook/react/issues/11211#issuecomment-481754450. It’s a shame that there is no current consensus regarding these specifications, but of course this may hopefully change in the future. I’m rooting for everyone here. 👍

[johanneswilm]

@js-choi Yes, it seems like we do not get any further with this for now as there is no willingness to agree on level 2 or a full proposal of an alternative to level 2. There have been several partial/initial proposals by individuals over the past few years saying things like "we should give access to the foundational blocks of IME", but as far as I can tell there has been nothing concrete enough to discuss as an alternative to level 2.

[ianstormtaylor]

This is super unfortunate because Level 1 is not really useful for IME-based editing is concerned—at least as far as I can tell.

I work on Slate.js and Safari (on desktop and mobile) works beautifully for compositions because of the presence of the Level 2 insertByComponent input type. Without that, there seems to be no way to cancel the final "committed" input from an IME?

Right now Chrome is degraded with no easy way to fix things.