Link exposed to the WebIDL definition, remove potentially confusing note

[shannonbooth]

I recently implemented this, and noticed that this could be linked, so this does that. However, on deeper investigation, I did notice that browsers didn't behave as I expected for DeviceMotionEvent since that is only exposed in secure contexts.

I expected browsers to throw on document.createEvent('devicemotionevent') like they do for new DeviceMotionEvent('foo') in non secure contexts, but from some limited testing they seem to not do that.

Since the intent of the spec reads to throw in this situation, I'm just removing the spec note here which seems to indicate it only applies for TouchEvent and will write a corresponding WPT test if this change is fine.

Sidenote: TouchEvent by strict reading of the IDL is always exposed on window in the IDL definition and the spec instead uses a separate implementation defined boolean which reads to only apply for the mixin, so this wouldn't apply here. But that seems to not reflect with the intent of the touch events spec, and now that specification is unmaintained.

• At least two implementers are interested (and none opposed):
  • …
  • …
• Tests are written and can be reviewed and commented upon at:
  • …
• Implementation bugs are filed:
  • Chromium: …
  • Gecko: …
  • WebKit: …
  • Deno (only for aborting and events): …
  • Node.js (only for aborting and events): …
• MDN issue is filed: …
• The top of this comment includes a clear commit message to use.

(See WHATWG Working Mode: Changes for more details.)

---

Preview | Diff

[shannonbooth]

Ah, apologies, I completely missed #952 which mentions TouchEvent since I was looking at the device motion event instead of the touch event, now I am not sure about this merge request at all.