- From: David Håsäther <hasather@gmail.com>
- Date: Wed, 28 Nov 2012 13:00:29 +0100
- To: www-dom@w3.org
On Wed, Nov 28, 2012 at 12:37 PM, Olli Pettay <Olli.Pettay@helsinki.fi> wrote: > On 11/28/2012 01:12 PM, David Håsäther wrote: >> >> On Wed, Nov 28, 2012 at 12:04 PM, Olli Pettay <Olli.Pettay@helsinki.fi> >> wrote: >> >>> On 11/28/2012 12:30 PM, David Håsäther wrote: >>>> >>>> >>>> The only reason for CustomEvent is to be able to pass a `detail` >>>> object. It seems unnecessary to have a separate constructor just to be >>>> able to pass an extra object, and I would suggest that Event could >>>> take `detail` too (thereby deprecating CustomEvent). >>> >>> >>> What is the use case for having .detail in Event? >> >> >> Same use case as for having it in CustomEvent, to provide custom data. >> Custom events could then use the Event constructor, instead of >> CustomEvent. >> >> -- >> David Håsäther >> > > So just use CustomEvent. Right. The question is if it makes sense to use a separate constructor for custom event, when the only thing it adds is the possibility to add a custom object, and this object could just as easily be available on Event. > Or are you asking for .detail for all the events, so that > for example UIEvents and MouseEvents could have it too? That was not the use case I had in mind, no. > UIEvent has already .detail, but not the same type as > CustomEvent.detail, so we can't move .detail to Event, but perhaps > we could add some other property. .additionalData? A bit long. Yea, UIEvent has detail, so you could overwrite it then. This is not a problem as far as I can see. > But again, what is the use case? Less typing for absolutely no reason. -- David Håsäther
Received on Wednesday, 28 November 2012 12:01:16 UTC