Extract information on cancelability of events

[dontcallmedom]

This extracts the cancelability of all actually-cancelable events listed in #772 (comment), except for the copy/cut/paste events which would need a patch (the same way they need one for bubbling), and for dblclick (due to a bug in the spec)

I've also verified that all the events that get extracted as cancelable are indeed marked as such in the source spec.

I don't know of a good way to check that it's not missing other cancelable events.

This is in the context of https://github.com/orgs/mdn/discussions/665#discussioncomment-9008930

This doesn't have test, nor does it update the aggregation/validation code, hence marking it as draft (happy for someone else to take a stab at those :)

[dontcallmedom]

now with test and updated schema

[tidoust]

This part looks good to me.

I suppose the aggregation code still needs to be updated to add a setCancelablePerTarget method (or to amend setBubblingPerTarget), right? Or is the expectation that the cancelable will not depend on the target interface? If the latter, we'd need a test to make sure that the assumption is correct.

[dontcallmedom]

thanks for the reminder re aggregation :)

AFAICT cancelability is orthogonal to the target interface; in some cases, cancelability is not systematic, which this extraction doesn't capture, but it's not obvious to me that we can or should try to do so; I wouldn't try until we have a clear use case.

[tidoust]

thanks for the reminder re aggregation :)

In practice, if we consider that cancelability is an intrinsic property of an event, the aggregation logic does not need to change. It already copies the cancelable property over to the aggregated file. I just updated the related JSON schema to add the property.

I also adjusted the extraction logic to report an error to the log if it finds the same event twice in a spec with different cancelable properties. I tested locally, that never happens.

Now, one last thing I'm wondering about is the nuance between undefined and false (that also applies to bubbles with the additional nuance that bubbles is meaningless when an event is not fired in a bubbling tree).

When I run this code against the Presentation API, it tells me that the spec defines a connectionavailable event that is not cancelable because the spec explicitly says that. But it tells me nothing about the cancelability of the change event, because the spec is not explicit about it.

But then when a spec uses a "fire an event" phrasing without specifying anything, the created event will not be cancelable (unless a spec one day decides to change cancelable in the init dictionary that extends EventInit but no spec does that AFAICT). In theory, the Presentation API could drop "The event must not bubble and must not be cancelable" when it fires connectionavailable and that would not change anything. Should we set cancelable to false (and possibly bubbles too) by default when we find a "fire an event" phrasing?

Maybe we don't really care as the most interesting case is probably to know when an event is cancelable.

Running the crawler locally with this update, I see 74 cancelable properties in the result (41 times set to false, 33 times set to true) out of the 441 events that we extract (not applying the events curation that we have in Webref). We have 127 events associated with a "fire an event phrasing".

[dontcallmedom]

The false vs undefined question also arose in the MDN discussion that started this (in the context of bubbles); I would suggest we merge this as, where false reflects the spec being explicit about it, although I agree that in practice we may just need to track cancelable: true in the end. I think we'll be in a better position to make that change once we get consumers.