w3c / uievents

UI Events
https://w3c.github.io/uievents/
Other
145 stars 52 forks source link

Clearly specify initUIEvent #133

Open dtapuska opened 7 years ago

dtapuska commented 7 years ago

Since initUIEvent probably isn't going away anytime soon. It should be clearly documented with respect to its arguments instead of its current specification of no arguments.

It is present in multiple browsers according to MDN; https://developer.mozilla.org/en-US/docs/Web/API/UIEvent/initUIEvent

We need to decide what the actual specified behavior is:

Chromium has this: void initUIEvent([Default=Undefined] optional DOMString type, [Default=Undefined] optional boolean bubbles, [Default=Undefined] optional boolean cancelable, [Default=Undefined] optional Window? view, [Default=Undefined] optional long detail);

But it identifies that all the values should not be optional. We need to figure out what other vendors have.

@garykac @foolip @smaug----

foolip commented 7 years ago

In this issue I would include all the init*Event methods in the spec, especially initMouseEvent and initKeyboardEvent. Even if the arguments differ in different implementations, there's probably some number of leading arguments that would be enough to support.

foolip commented 7 years ago

Context: https://bugs.chromium.org/p/chromium/issues/detail?id=692720

smaug---- commented 7 years ago

How does chromium handle those undefined values? Does undefined boolean end up treated as false?

foolip commented 7 years ago

Yes, Chromium's IDL is effectively this:

void initUIEvent(optional DOMString type = "",
                 optional boolean bubbles = false,
                 optional boolean cancelable = false,
                 optional Window? view = null,
                 optional long detail = 0);

As in https://github.com/whatwg/dom/issues/387, I think we should make the first argument non-optional and make the rest optional with defaults.

annevk commented 6 years ago

Yes, this should be aligned with DOM.