api.EventTarget.addEventListener.options - add signal option #9562
Conversation
github-actions
bot
added
the
data:api
api/EventTarget.json
Outdated
| "description": "<code>signal</code> option", | ||
| "support": { | ||
| "chrome": { | ||
| "version_added": "89" |
There was a problem hiding this comment.
@ddbeck FYI you indicated Chrome 90, my testing shows 89 works, but the fact Opera works on Opera 74 indicates maybe it went in on Chrome 88?
There was a problem hiding this comment.
Nice catch. You must have experimental web features turned on. It was added behind a preference in 88 and enabled by default in 90.
You can enter them as two support statements (one with a flag added in 88 and removed in 90, then one without a flag added in 90), or you can ignore the flag and only report 90 (since, by the time this lands in BCD, it will be interesting to web developers for a couple of weeks at best).
| "ie": { | ||
| "version_added": false | ||
| }, | ||
| "nodejs": { |
There was a problem hiding this comment.
Note, the spec predates the last release we have, so I have just put as false.
There was a problem hiding this comment.
Thank you, @hamishwillee. Suggestion for handling the 88 vs. 90 question in a line comment.
Further, I just called this subfeature
signal. There is a bit of a mess of naming, and I guess that will impact ordering. I was wondering if perhaps we should rename according to a patter. So perhaps option_signal, option_passive, option_once. Then the passive option exceptiosn could be option_passive_default_etc. I will leave unchanged unless you decide renaming is sensible.
Let's leave this for now. The structure here is a bit weird. It's probably the case that we ought to have passive_true_touch and passive_true_wheel as subfeatures of passive, or rename all of them, as you suggest. But really, we don't have a guideline for how these things are supposed to be and I'm not inclined to rearrange things without a guideline. I'll open a separate issue for that.
api/EventTarget.json
Outdated
| "description": "<code>signal</code> option", | ||
| "support": { | ||
| "chrome": { | ||
| "version_added": "89" |
There was a problem hiding this comment.
Nice catch. You must have experimental web features turned on. It was added behind a preference in 88 and enabled by default in 90.
You can enter them as two support statements (one with a flag added in 88 and removed in 90, then one without a flag added in 90), or you can ignore the flag and only report 90 (since, by the time this lands in BCD, it will be interesting to web developers for a couple of weeks at best).
|
Thanks @ddbeck . I ended up ignoring the preference versions and just updating to v90 (and equivalent, if there was a matching release). Should be good to go. |
Fixes #9555
@ddbeck Comments inline.
Further, I just called this subfeature
signal. There is a bit of a mess of naming, and I guess that will impact ordering. I was wondering if perhaps we should rename according to a patter. So perhaps option_signal, option_passive, option_once. Then the passive option exceptiosn could be option_passive_default_etc. I will leave unchanged unless you decide renaming is sensible.