- From: Raphael Kubo da Costa via GitHub <sysbot+gh@w3.org>
- Date: Tue, 14 Dec 2021 10:54:43 +0000
- To: public-device-apis-log@w3.org
I've been confused about this [before](https://github.com/w3c/web-nfc/issues/622#issuecomment-946023029) too, and I think the current text is fine as-is. The constructor algorithm is actually specified in the [DOM spec](https://dom.spec.whatwg.org/#concept-event-constructor): > 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? -- GitHub Notification of comment by rakuco Please view or discuss this issue at https://github.com/w3c/sensors/issues/426#issuecomment-993419471 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 14 December 2021 10:54:45 UTC