Re: 2 Proposals for Minimum Viable InputEvent

> On Feb 14, 2017, at 21:22, Johannes Wilm <johanneswilm@gmail.com> wrote:
> 
> I've read the document. I like that you added getTargetRanges to the input event.
> 
> The other concerns are probably the same: This will only be usable if one combines it with a diffing mechanism to roll back changes. And it will have to be a diffing mechanism that can reach across several block level elements because it's impossible to know how much of the DOM it will change. In many/most/all cases this will mean JS editors will opt for existing events instead. In the case of IME, it may still be more useful than the compositionupdate due to the availability of the target ranges (not sure).
> 
> How about this for compromise: Given that Chrome has indicated that they may still ship the entire current spec some time in the future and given that the current spec seems much more useful for JS editors, I wonder if it's possible to do the following: create a version 1 of the spec with Google's changes applied and simultaneously start a version 2 of the spec that is the current spec without the changes applied. That way Google can ship what they want to ship anyway right now and be spec compliant, and we don't destroy what we have come up with already.
> 
> Any expert on W3C process can say whether this was possible?

Leaving it up to the various participants in this conversation as to whether such a thing is desirable, I'll just respond as to whether it is possible.

TL;DR: yes, presuming version 1 and 2 are combatible. Also, there are lighter weight approaches to do the same thing.

You can have 2 editors drafts, call one of them level 1 and the other level 2, and have level 2 says that it supersedes level 1. Level 2 should be written so that any conforming implementation of level 2 is also conforming with level 1 (but not necessarily the reverse, obviously), otherwise you don't have two levels, you have two competing proposals.

Getting both to be published as Working Drafts is also allowed by the Process, even though that will require (as any WD publication does) approval from the Working Group (and a trip to the Administrative Committee for the First Public Working Draft).

A lighter weight approach to do the same thing is to only have 1 level, and to mark some aspects (those that would otherwise go into level 2) of it "at risk". This is a term of art that means that when we get to the point where we are testing implementations against the spec to see if it is fully implemented and ready to go to REC, if everything's fine except the things marked at risk, you can still move the spec forward by removing the at-risk parts without further process churn. Whether to put the removed parts in a next level document or to drop the altogether is a decision we can make then.

You can also spec the parts that are desirable-but-lacking-implelementation-commitment parts as "the UA **should** do such and such" instead of  "the UA **must** do such and such".

Or you can combine both, writing "the UA must do such and such" and "This requirement is at risk, and may be relaxed from a MUST to a SHOULD.

Anyway, all of this are ways to write things down assuming we are in agreement on what to do eventually, but in disagreement on whether to do it now or later. If we are not in agreement over what to do eventually, the only things we can do are more discussion (possibly mediated by a WG Chair), or ship-and-see-what-sticks.

—Florian

Received on Wednesday, 15 February 2017 02:31:29 UTC