Should the API be forwards compatible?

[RByers]

Is the requirement to use feature detection or a polyfill OK?

Olli Pettay suggests:

...but unfortunately that is not backwards compatible. If we could find a nice backwards compatible syntax. addEventListener("wheel", listener, true, { preventDefault: "never" }); would behave fine, but is a bit long. Would it be good enough?)

To me the benefit of this doesn't seem worth the cost in verbosity, but I could live with it if there was consensus otherwise.

Another option is discussed in #11

[domenic]

It's not a perf optimization though. It changes preventDefault and everything that keys off of an event's canceled status. This is a new feature with serious semantic impact on event life cycle.

[jacobrossi]

It's only intended to be used in scenarios where the event already wasn't being canceled, so it's not very serious of a change in practice.

[domenic]

Maybe, but it's also only intended to be used in scenarios where you feature test its presence.

[jacobrossi]

Pretty much all features are intended to be used with feature detection, but the reality is code isn't always written that way. We have the opportunity to avoid an issue here, we should take it.

[RByers]

Thanks Jacob, I think I understand your argument better now: Normally when we add a new API we don't get the luxury of forwards compat, but at least feature detection is normally trivial. Here, with the 4th arg design, we could probably get away with treating it as forward compatible, not needing a polyfill. We shouldn't squander that opportunity, especially given the non-triviality of feature detection. Olli / Jacob, does that capture your argument accurately?

So if we went with the 4th arg design, would we bother even to recommend using feature detection in most cases? Probably not right? That simplifies things for developers quite a bit and so probably lowers the barrier to adoption of passive listeners. That's a potentially compelling reason to me to accept an uglier API.

None of this makes it any harder to offer a new / simplified syntax in the future if the benefits of adding an alternate method outweigh the cost. It sounds like there's other reasons we might want to do that in the future, so maybe we shouldn't get too hung up in trying to make an already ugly API a little less ugly?

[jacobrossi]

Yep that captures my thoughts well, Rick.

[annevk]

I don't think it's acceptable to move to four parameters here. Developers dislike the current API enough as it is, we should not make it worse.

[jacobrossi]

What's your acceptance criteria here? One of the utmost concerns of API design for web developers is compatibility, which is the issue being raised here. Getting rid of an historical boolean argument seems like the least of web developers' pains.

[tabatkins]

Again, the issue raised here is forward compat; the "utmost concern of API design" is backwards compat, which nobody is raising as a serious issue here.

The boolean argument is nonsense cruft which, luckily, can usually be ignored. This change (and the future changes it enables that will add more options to the dict) will require authors to understand and specify it every single time they want to use one of the further options.

As has been pointed out, feature-testing the 3-arg variant, while not trivial, is possible without too much difficulty, and can be easily built into any of the feature-testing libraries like Modernizr. Or if we absolutely cannot accept this, creating a new method with 3 args (and giving it a nice name like .listen) is acceptable to at least some people in this conversation too, and sounds great to me.

(I'm sorry that adding this useful feature is requiring so much side-argument over syntax.)

[tabatkins]

Note as well that all dict-taking APIs have this feature-testing difficulty. Passing an options dict with unused properties doesn't cause an error, so you always need something like what Rick's example shows to tell whether the property in question is being used. This is not a new or unique difficulty that we're dealing with here, so it shouldn't be anything near a deal-breaker.

[jacobrossi]

Note as well that all dict-taking APIs have this feature-testing difficulty.

This API is special in that it is attempting to replace an already defined API with different behavior. In the failure case here, it produces bugs that are very expensive and confounding for developers to debug (a change in the event timing). We should help developers (and their/our customers) avoid that pain by designing a better API like proposal 2.

Never have we ever been able to rely on developers' use of feature detection as a replacement for sensible API design.

This feature is a perf optimization with no user observable change in behavior. It's very similar to will-change in that regard. will-change gets ignored by browsers that don't support it and falls back gracefully. This API can and should do the same. Other than "Booleans suck," I haven't seen a technical argument as to why we can't do that for our customers.

For at least several years, hundreds of millions people will be using browsers that will be at risk of compatibility woes caused by this API not being designed properly, and web developers will be the ones that feel the pain of figuring it out and fixing it. That's just not warranted for such a simple perf optimization (not to mention, one for which better APIs without this perf problem already exist).

I'm sorry that adding this useful feature is requiring so much side-argument over syntax.

If it was just minor syntax that was affected, like changing API names, I'd agree. But this discussion has actual interoperability issues at hand. After interop disasters like -webkit APIs, I'm confident developers want us to spend the extra few days to think through API design in an interoperable manner.

[tabatkins]

This API is special in that it is attempting to replace an already defined API with different behavior. In the failure case here, it produces bugs that are very expensive and confounding for developers to debug (a change in the event timing). We should help developers (and their/our customers) avoid that pain by designing a better API like proposal 2.

I don't think this is different from any other new option that can cause a significant behavior change.

However, if you feel that strongly about this, then let's just make a new method name. I feel strongly that we should not force authors to pay the boolean-understandability tax for the infinite future, and authors already complain about the length of the addEventListener name. Let's just make a new .listen() method that takes an event name, a callback, and an options arg, defined for now to have two keys: "passive" and "capture".

[dtapuska]

I don't think that we should just consider this feature as a perf optimization. We are effectively designing an alternate approach for options passed into any event listener. Mozilla's 4th argument for untrusted events could have just been an option in the dictionary.

My gut tells me that we should just use a new named API like listen(); as Tab indicates.

On Mon, Feb 29, 2016 at 12:07 PM, Jacob Rossi notifications@github.com wrote:

Note as well that all dict-taking APIs have this feature-testing difficulty.

This API is special in that it is attempting to replace an already defined API with different behavior. In the failure case here, it produces bugs that are very expensive and confounding for developers to debug (a change in the event timing). We should help developers (and their/our customers) avoid that pain by designing a better API like proposal 2.

Never have we ever been able to rely on developers' use of feature detection as a replacement for sensible API design.

This feature is a perf optimization with no user observable change in behavior. It's very similar to ''''will-change'''' in that regard. ''''will-change'''' gets ignored by browsers that don't support it and falls back gracefully. This API can and should do the same. Other than "Booleans suck," I haven't seen a technical argument as to why we can't do that for our customers.

For at least several years, hundreds of millions people will be using browsers that will be at risk of compatibility woes caused by this API not being designed properly, and web developers will be the ones that feel the pain of figuring it out and fixing it. That's just not warranted for such a simple perf optimization (not to mention, one for which better APIs without this perf problem already exist).

I'm sorry that adding this useful feature is requiring so much side-argument over syntax.

If it was just minor syntax that was affected, like changing API names, I'd agree. But this discussion has actual interoperability issues at hand. After interop disasters like -webkit APIs, I'm confident developers want us to spend the extra few days to think through API design in an interoperable manner.

— Reply to this email directly or view it on GitHub https://github.com/RByers/EventListenerOptions/issues/12#issuecomment-190292427 .

[domenic]

I strongly oppose squatting on a good name like listen for the current EventTarget design. People expect us to use that for some kind of redesign, e.g. based on observables or https://gist.github.com/annevk/4475457. If we're going to use up a good name we need to spend some serious time redesigning EventTarget to be more user-friendly, at least, even if we're not going whole-observables.

[annevk]

Agreed, we should not make a legacy API worse and we should not use a new name lightly. We've been iterating on this third parameter switch for a while before it was put into the standard. I still don't see a good enough reason to change that. (Overloading the first argument seemed attractive at first, but that breaks with how new Event() arranges its parameters. Not great.)

[phistuck]

What about overloading the second parameter? It already accepts an object with a handleEvent method and uses it as the callback. Seems almost classic... Or is there a this issue there? I forget.

[jacobrossi]

However, if you feel that strongly about this, then let's just make a new method name.

I agree with @domenic. If we're going to create a new method, then we should take the time to do a major overhaul of events. But I don't think we want to gate this perf optimization feature on that redesign. If and when we do that overhaul, then the minor inconvenience of the 4th arg goes away.

We've been iterating on this third parameter switch for a while before it was put into the standard. I still don't see a good enough reason to change that.

When compatibility/interoperability is at stake, the burden of proof is the other way around. You need to show sufficient argument why a breaking change to one of the most popular APIs on the web is necessary for this feature. "We don't like the old boolean argument" is not sufficient.

[phistuck]

I just checked - yes, this is the second parameter instead of the event target. Perhaps this is not so bad, though.

[domenic]

This is not a breaking change. It's important everyone understand that. It is not forward-compatible, but is backward-compatible.

[jacobrossi]

Let's not argue the semantics of a "breaking change." I think we understand what breaks and doesn't here.

[annevk]

The web doesn't have a forward-compatible principle.

[RByers]

What about overloading the second parameter?

That's discussed (and rejected) in #11.

[jacobrossi]

The web doesn't have a forward-compatible principle @jacobrossi.

Says who? Forwards compatibility is important opportunity to take advantage of that benefits our customers, both developers and users.

About 1.2M (of a sample size of ~2.5M) pages use aEL with three arguments. As these pages update to take advantage of this new feature, forwards compatibility serves as an important protection to the hundreds of millions of customers browsing without this feature.

Forwards-compatibility isn't a MUST in all API design cases. But when we have an easy opportunity to enable it and we're talking about one of the most popular DOM APIs, we should take it.

[tabatkins]

Let's not argue the semantics of a "breaking change." I think we understand what breaks and doesn't here.

But apparently we don't, since you're using the term "breaking change" to refer to something that is slightly harder to feature-test for than normal. ("normal" meaning "this API will throw an error if used in legacy browsers" or "can be tested for just by seeing if a property exists on some object").

Overloading the third argument of aEL() to allow an object is not a "breaking change" by any reasonable definition of the word. The burden is thus relatively low here - we're simply deciding whether it's more important that (a) the API be slightly easier to feature-test for during the transition period, or (b) the API not enshrine a confusing boolean param in its signature forever.

Worst case, authors just don't use the new API until it's widely supported enough to depend on. This is an unfortunate outcome, but not unusual - the same thing happens regularly for major CSS features. It's also the outcome whenever some API depends on functionality that can't be polyfilled.

But that shouldn't happen, because it's not that hard to feature-test this. It's non-trivial, but the code to do it is short, and Rick already demonstrated it. Building this into the feature-testing libraries like Modernizr will be very easy and cheap. I don't think this is a big pain for authors to pay for the short transition period (and we can make it shorter by all pushing to this syntax form quickly).

[RByers]

Let's not argue the semantics of a "breaking change." I think we understand what breaks and doesn't here.

In a way this is exactly what we should be arguing. We all care about the same principle here: most code on the web should behave the same in the browsers that the vast majority of users are using. We just have different opinions on how the different choices here are likely to affect that principle. Ideally we should be trying to bring data to try to back up these opinions.

In particular, I'm still concerned that if we try to use an API form that's forwards compatible it may cause more compat issues than it solves. I'm thinking about the case of touch-action and hammer.js. In that case a developer didn't fully understand the implications of a new API, and so chose a default that appeared to work in his quick tests. Then when site developers found it broke their site on IE, they added UA checks to avoid using the library in IE. Then when Chrome shipped an identical feature to IE, we had thousands of sites that were badly broken only in Chrome.

The similar risk here is that someone cargo-cults the use of passive listeners, tests thoroughly only on browsers without passive listener support, not realizing their logic relies on preventDefault continuing to work from within a passive listener. This can result in some subtle bugs (eg. dragging-while-zoomed being broken). Or in the flip scenario, testing only on browsers with passive listener support, and iterating until things appear to work - not realizing they have some incorrect preventDefault calls that are being ignored. On old browsers scrolling may now be completely broken. The solution for both types of issues, I think, is to strongly encourage the use of a good polyfill. Forward compatibility here is a unicorn - would be nice but doesn't really exist in practice.

[jacobrossi]

The similar risk here is that someone cargo-cults the use of passive listeners, tests thoroughly only on browsers without passive listener support

I really doubt anyone would do this nor have I ever seen anyone do this to an API before (evangelize using something without using it themselves?).

Or in the flip scenario, testing only on browsers with passive listener support, and iterating until things appear to work - not realizing they have some incorrect preventDefault calls that are being ignored.

This scenario implies they have listener code that calls preventDefault and then they make that listener passive. If the preventDefault calls were incorrect, then they were already broken in browsers before they made it passive. If the scenario is that they somehow iterate the listener after making it passive to now have incorrect preventDefault calls, then that's a scenario that seems very far fetched (or at least an edge case and not something we'll see en masse) to me.

The cargo-cult scenario we should be anticipating is an evangelism of converting your listeners to passive wherever you can. This will easily get boiled down too simply to "just swap out the third arg for this object and you'll make your touch handlers fast in Chrome!" Devs will flock to implement this "quick tip" without thought of how objects will be considered truthy in other browsers.

This is going to be a much more mainstream scenario than the others you presented IMO. We see this kind of thing all the time at conferences and on blogs where folks put together "10 quick perf tips" (like the translate3d "trick" for GPU accelerating all the things!).

[grorg]

/me reluctantly enters this heated (but very polite) discussion :smile:

If it helps move forward, I would categorize my + smfr (Simon Fraser) + WebKit's position right now as preferring the 3 argument form over the 4 argument form.

I also like the idea of going towards an API that only takes a single dictionary.

[RByers]

Thanks @grorg!

To summarize the current state - the two main options that appear to have the most support are:

1. Leave things as-is (EventListenerOptions is the 3rd arg). This is seen as cleanest long-term, addressing the existing boolean arg wart, at the cost of foward compat risk when developers fail to feature detect / rely on polyfills. @annevk (spec) @domenic @foolip @tabatkins (blink) @grorg (WebKit) are in favor of this choice.
2. Move the options to the 4th arg position. This is much more likely to be forwards compatible, but makes common scenarios more verbose / opaque. @jacobrossi (Edge) and @smaug---- (Gecko) are strongly in favor of this approach.

I'm personally willing to ship either of these, but I need to make a decision one way or the other soon. It seems to me this is a judgement call weighing two different things that are hard to quantify. Does anyone have any suggestion of data they could bring to the argument to better quantify the tradeoff? Would a conference call / video chat be likely to help here?

[RByers]

Here's another option that may be crazy or may actually get us the best of both worlds. Like #11, but would it be sufficiently compatible if we changed the signature to to addEventListener(DOMString type, EventListenerOptions? options, optional boolean capture) and add required EventCallback handleEvent to EventListenerOptions (with `callback EventCallback = void(Event)') or something to that effect? That would have the advantage of letting people put the options before the handler, as in:

  element.addEventListener("touchstart", {
    passive: true, 
    handleEvent: function(event) {
      ...
   }});

I think this might be both forwards and backwards compatible for ECMAScript bindings at least. We'd have to define what happens if both the 3rd arg and the capture option is specified (3rg arg always wins? throw?), and of course it's not forwards compatible anymore if you specify the capture option without also using the 3rd arg. But maybe those are minor issues relative to the strong concerns some folks have with all the other options?

[RByers]

Oh - and you commented that it was rejected. :) #11

Yep, I'm saying we should revisit that and discuss it in more detail. Sorry we didn't do that sooner - I don't think we gave the idea the attention it deserves. In the original approach I think we were thinking of persisting the legacy "callback interface" pattern, but this is a little different (at least conceptually) - just a dictionary that happens to be structured such that (in ECMAScript) it works the same.

The only issue might be the unusual this (unless you use arrow functions, of course).

Yeah for compatibility I think we'd have to say that handleEvent is called with this set to the EventListenerOptions value, which is kinda weird but maybe tolerable if it gives us something all the engines can live with?

[phistuck]

I know of at least one (popular?) library that used (or uses?) that handleEvent pattern - iScroll. So there might be compatibility issues with this approach (what if the object happens to also define a capture or passive property?). An HTTP Archive research would be a place to start, but a use counter would be even better (or an internal Google index search). It might be a bit tricky to find, though.

[smaug----]

I haven't seen anyone coming up with any compelling reason to why not use 4th param version here. The slight more verbosity shouldn't really be a deal breaker here. And if someone doesn't like the 4th param version, "just polyfill" it everywhere and use whatever syntax script library author happens to prefer. But let's not force everyone to polyfill.

If we later want to add some nicer API to add listeners, that should use totally different function name. Designing that API will take significant amount time.

(I kind of like that 2nd param as object approach but unfortunately it doesn't solve the issue.)

[tabatkins]

I haven't seen anyone coming up with any compelling reason to why not use 4th param version here.

The fact that "this API shape is terrible, everyone agrees that it uses a terrible pattern, and we shouldn't make it more terrible" isn't a compelling reason is why the DOM has a well-deserved reputation of being terrible. :/

[smaug----]

3rd param version isn't really making the API less horrible, so I don't see the point. In fact, now that I think of it, I think it is making the API even worse, by making this magical 'boolean or object' param. 4th param case has the same issue, but only in Gecko, so that is fine.

[tabatkins]

No, I'm referring to API usability. Everyone recognizes and agrees that boolean positional args are terrible API design. The current aEL() suffers from this, but most of the time the boolean arg can be ignored and left off, so it's not too bad.

The 4-arg proposal kills that - if you want to specify any of the extended options (passive, or anything we add in the future), you'll have to write out the boolean third arg, and remember what it does to make sure you used the correct value.

[jacobrossi]

I don't personally think it's worth stressing over the Boolean aspect as this is really only going to be used by a subset of use cases for 2 maybe 3 events (touchstart, wheel, and maybe touchmove since the first one is cancelable) and will very likely be replaced altogether in the future with a better listener registration method.

That said, if the Boolean is a deal breaker for some folks then I really like the 2nd arg approach above. It seems like a reasonable design that gets rid of the forced bool and is forwards compatible.

I'm not too worried about the possible collision with an existing passive member of the object. I tried to grab crawler data on handleEvent usage but it's thrown off by a Google Translator lib that doesn't appear to actually use it in runtime. So I've added a UseTracker to this but we won't get meaningful data for a couple weeks.

[foolip]

I don't think the 2nd arg approach will work with EventListenerOptions as a dictionary. The argument is now a EventListener callback interface, which is either a function or an object. If it's a (non-callable) object, the handleEvent property lookup is done when invoking the callback. So the handleEvent property can be replaced after registering the event listener, and crazy things like this work in all browsers:

var callback = {};
document.addEventListener('foo', callback);
callback.handleEvent = function(event) { console.log(event) };
document.dispatchEvent(new Event('foo'));

Even modifying the handleEvent property during dispatch works consistently: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3980

A proper WebIDL dictionary with a handleEvent member could not preserve this behavior, so the argument would have to be handled entirely in prose, and it would have the odd characteristic that handleEvent can be modified at any time, but the other "dictionary" members could not.

This does not look promising to me, but if someone has a processing model in mind that isn't too crazy, please elaborate.

[RByers]

@foolip ugh, thanks - that's nasty. What do you estimate the chances are that essentially nobody actually does that sort of thing in practice, and so it's something we could break? Eg. have you seen an actual example of that in the wild?

[domenic]

We had someone file an issue on jsdom for that behavior not working per spec that we needed to fix, I assume because he was using jsdom to scrape/test a real world website. So, that's one site at least.

[annevk]

Note also that this will be different for such callbacks. It'll be the object you passed and not the event target. We cannot change that.

[phistuck]

@annevk - I noted that earlier, but arrow functions (with transpilers) should take care of that annoyance anyway.

Regarding the presented issue where the handleEvent method is evaluated at the event dispatching time - I am not sure this matters. I expect most of the uses to be like -

addEventListener("click", {handleEvent: e => {this.value = "foo"}, passive: true});
addEventListener("click", {handleEvent: e => doStuff(e), passive: true});
addEventListener("click", {handleEvent(e) { doStuff(e) }, passive: true});

[RByers]

Ok, I can see why this 2 arg option is likely either too breaking or too weird to spec.

I'd like to try to make the forwards compat argument a little more concrete to see if that helps in evaluating tradeoffs. I think the argument rests primarily on the likelihood of the following situation occurring:

1. User uses a browser over a year old (sounds like this is the biggest risk, we can discuss the evergreen-but-no-ELO-support seperately), AND
2. User visits a page that has opted in to using ELO for an event type the user generates (eg. touch), AND
3. That page fails to follow our feature-detection / polyfill guidance, AND
4. The listener being incorrectly capturing results in user-visible breakage

My gut conservative instinct of the chances of these occurring are (very roughly without much real data to back it up):

1. 25% (maybe 40% on mobile, 10% on desktop with usage roughly evenly split?)
2. 30% (eg. 50% of touch listeners on mobile, after a few years of evangelism)
3. 1% (we'll work with the biggest frameworks/sites here to make sure they do it right, so in terms of page loads I suspect we can probably get lower than this)
4. 20% (anecdotally most cases I look at don't matter, but I can believe it's not uncommon they will)

This works out to 0.015% of page views. I'm personally OK with that level of medium-term breakage in order to give developers a more convenient API (similar to what we'd be willing to break on blink in order to remove a bad API that had a strictly superior alternative). Anyone want to argue I was an order of magnitude off one way or the other somewhere? Better yet, anyone want to come up with some data to provide more justified values? I wouldn't, for example, be OK with a total value 10x higher than this - if we believed that was the most likely outcome I'd personally weight the compat costs higher than the developer ergonomics.

[foolip]

Reminds me of the Drake equation :)

I think it's correct to view this as a medium term risk, as the numbers will change over time. Non-ELO browser share (1) will start out at 100% and slowly converge to 0%. ELO-using page views (2) will start out at 0% and converge to, say, 30-50%. Non-feature-detecting page views (3) has to start out at almost 0% because of (1), and can only increase significantly once (1) has fallen to some tipping point. (4) is likely roughly constant over time.

Once (2) is "close" to its final value, this will be determined by (1) vs. (3). My hunch is that web developers would be slower to remove/forego feature detection than users are to upgrade, because cleanup work doesn't have much of an upside.

[jacobrossi]

Non-feature-detecting page views (3) has to start out at almost 0% because of (1), and can only increase significantly once (1) has fallen to some tipping point.

This is not how it typically goes in reality. Like it or not, many developers only test in one browser. So the tipping point is really just once one browser with significant share (e.g. Chrome) ships with the feature (note Chrome already has ELO, but it isn't really adding a new capability until they ship passives).

[RByers]

Reminds me of the Drake equation :)

Yeah, I was thinking that too. Like a Drake equation, despite low confidence in the values, I think this formulation can still make it possible to have a meaningful discussion of probabilities.

I think it's correct to view this as a medium term risk, as the numbers will change over time.

Right, I was trying to focus on the time period where the risk is greatest (basically after our evangelism and it's follow-on effects have had the bulk of the impact in changing code, but before EventListenerOptions is widely supported).

Non-feature-detecting page views (3) has to start out at almost 0% because of (1), and can only increase significantly once (1) has fallen to some tipping point.

This is not how it typically goes in reality.

Yeah I agree this could be (eg.) 1% of the pages using ELO right out of the gate. Now I do think there is likely to be some change over time - with the earliest adopters being the most popular libraries/pages and so getting direct support from us (and so hopefully lower than the long-tail of uses which may be updated via cargo-cult communication).

[foolip]

As I wrote my previous comment, I tinkered with a spreadsheet of made-up numbers, where my "tipping point" assumption translated to a medium-term peak in accidental capturing. The problem of feature-frozen and older browsers is what I assumed we were all most concerned about, from @jacobrossi in https://github.com/WICG/EventListenerOptions/issues/12#issuecomment-187041061

But, yes, testing in only one browser is also a problem. I guessed 0.05%, but if it (3) is 1% from day one, that would make "peak accidental capturing" a near-term event. @jacobrossi, is this the concern, and has this actually happened with a mobile-centric feature first launched in Chrome/Opera for Android over the past few years?

[smaug----]

This is very different to some random new feature. We're changing an ancient API in a way where new usage can easily accidentally behave differently in browsers not supporting the new syntax (assuming 3rd param approach is taken).

I'm not aware of any similar change been done to commonly used old APIs. So there isn't much we can compare to.

[jacobrossi]

I agree with @smaug---- . You can't really do this type of comparison because we're not just adding a new API, we're replacing an old one with different meaning and the replacement can be "misunderstood" by browsers that don't support it. I can't really think of other mobile features that have done this, which is really why I'm very nervous here.

But yes, the concern is feature-frozen browser (e.g. IE11 or FF ESR, both still in support but don't get new features by design), older browsers (IE <11, Android Browser, other variants of Android browsers, many users but will go away in the _long _term), and any browsers that decide for other reasons not to implement this.

[RByers]

Ok it sounds like there's nothing else we can do to better quantify the tradeoffs here. At least if we end up shipping with this risk, it sounds like we'll all learn something new about such risks to help us better quantify similar tradeoffs in the future ;-)

We still need to make a decision on what we'll ship in blink ASAP. Anyone else want to go on the record saying they feel there's enough risk here that it should block shipping an implementation according to the current spec? So far we have @jacobrossi (Edge) and @smaug---- (Gecko) strongly opposed to shipping the design as spec'd due to the potential forwards compat risk.

[jacobrossi]

I think we can at least agree that the forwards compat risk will be non-zero. It would be possible to write a browser extension that wraps AEL and flips the third argument to true. Browsing around with this would give you more data on how much user-facing breakage would occur. Obviously this won't tell you exactly what will break (nothing can tell the future), but it will give you data on the propensity for a change in the event phase to cause user-facing breakage, which would be valuable (#4 in your matrix).