Properly specify the constructor algorithm and internal slots for SensorErrorEvent

[anssiko]

We should properly specify the constructor algorithm and internal slots for SensorErrorEvent:

https://www.w3.org/TR/generic-sensor/#the-sensor-error-event-interface

[rakuco]

I've been confused about this before too, and I think the current text is fine as-is.

The constructor algorithm is actually specified in the DOM spec:

When a constructor of the Event interface, or of an interface that inherits from the Event interface, is invoked, these steps must be run, given the arguments type and eventInitDict:

1. Let event be the result of running the inner event creation steps with this interface, null, now, and eventInitDict.
2. Initialize event’s type attribute to type.
3. Return event.

which also takes care of initializing the error attribute.

As for the description of the attribute itself, I'm following the style used by the WHATWG specs as well as e.g. AppHistory:

• https://dom.spec.whatwg.org/#dom-event-type
• https://websockets.spec.whatwg.org/#dom-closeevent-wasclean
• https://wicg.github.io/app-history/#dom-apphistorynavigateevent-cantransition

@domenic is this the recommended style or is it better to have internal slots for the attributes and follow the more usual "the error getter steps are to return [=this=].[[Error]]" path?

[domenic]

Yeah, good question. Events are an unfortunate and confusing exception to the usual rules; we generally fudge them, even in recent specs, as @rakuco points out. So I think your current draft for SensorErrorEvent is reasonable; I would even delete the separate 7.2.1. SensorErrorEvent.error section and do it like other specs.

(Although, separately, it looks like a mistake to have SensorErrorEvent different from ErrorEvent. For app history, we just reuse ErrorEvent.)

[rakuco]

Thanks @domenic. #430 should make things a bit more clear. I guess it's too late to deprecate SensorErrorEvent though :/