- From: Domenic Denicola <notifications@github.com>
- Date: Wed, 09 Nov 2016 19:27:05 -0800
- To: whatwg/dom <dom@noreply.github.com>
- Message-ID: <whatwg/dom/issues/372/259592919@github.com>
Examples and explanations are always good; we should add some. In general "create an event" should be used very rarely, in specialized situations where you need to separate event creation from event dispatch. [Fire an event](https://dom.spec.whatwg.org/#concept-event-fire) is usually more appropriate. > But, the algorithm has not called x's constructor Sure, but why would you need to? "create an event" runs all the constructor logic. Compare [create an event](https://dom.spec.whatwg.org/#concept-event-create) and [event constructor](https://dom.spec.whatwg.org/#concept-event-constructor) > - not has it set its type. Yep. You can do that yourself pretty easily though. "Initialize _event_'s `type` attribute to "`foo`"". > Why not allow type to be provided with "create an event"? It's cleaner to explicitly state what you're setting, than passing it in as an unnamed argument. (And if you pass it in as a named argument, you aren't really saving anything.) > Also, if I want to have cancelable as true as default You should never override the default of basic properties of events like `cancelable`. That would be very unexpected. However, you can just ensure that whenever you fire or dispatch an event yourself in your spec, you initialize `cancelable` to true, as in the "fire an event" example. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/whatwg/dom/issues/372#issuecomment-259592919
Received on Thursday, 10 November 2016 03:27:37 UTC