XRLightProbe: Use single entry for event

[Elchi3]

Summary

Companion PR for mdn/content#10373. See the discussion at https://github.com/mdn/content/discussions/9098

[hamishwillee]

@Elchi3 If we're going to have a single entry for both the event and its handler, should the spec here moved down to reflectionchange_event ? (i.e. it has an array of specs)?

[Elchi3]

Yes, I think this is a great idea!

[ddbeck]

@Elchi3 OK, so this suggests something very interesting and slightly surprising to me: we will be omitting exposed interfaces that web developers can find and that tooling can inspect. Should we worry about that? Do we forbid any other things that are developer-exposed names? Are we OK with that?

I think if we're going to merge something like this, we ought to have data guideline that explains exactly which bits of IDL we're ruling out (e.g., "Don't create features for attribute EventHandler on*").

[Elchi3]

Yes, I believe this is what we would like to do. @foolip what do you think about this?

See also #12510 which I believe goes in the same direction and suggests the same consequences.

[foolip]

We need a guideline for this, yes. It wouldn't be the first bit of IDL that's excluded though, there's already https://github.com/mdn/browser-compat-data/blob/main/docs/data-guidelines.md#constants

[ddbeck]

I forgot about the constants case. Yeah, I'm much more comfortable with this, given the precedent. I would like to see an accompanying guideline before any of these merge, so that I have something to point to in the release notes.

[Elchi3]

Opened #13595 to discuss the data guideline change.

[Elchi3]

Content updates merged and new events guideline is in place. This is ready.

[foolip]

Post-merge review in light of #13924 (comment).

Here the versions of the on* properties matched the version of the interface, so there's nothing to research. (It is possible that the event wasn't actually fired, but that's a less common situation than missing on* properties.)