[w3c/webcomponents] Better custom event support for custom elements would be great (#546)

`<img onerror>`, `<button onclick>`, *&c.*: these things are convenient and consistent. But custom events? One can create and dispatch custom events easily, but you don’t get the `onfoo` attribute and property for free, and it’s not so easy to get them working with the same semantics as the built-in event types.

I believe that Custom Elements is a great place to canonise the pattern and provide a standard implementation of this bit of scaffolding for custom events, so that they just work as expected, just like Custom Elements is all about making such things just work as expected from HTML authors. I expect that doing this will encourage the use of custom events as well (where people simply haven’t thought about it, for example, but they see that it’s now easy to do), which I think is probably a good thing.

Defining an event attribute `foo` has two parts; the property `onfoo` is added to the element’s prototype, and its HTML attribute `onfoo` is monitored and the `onfoo` property updated when the attribute changes.

I see two main approaches to specifying this (that an element of type `MyFancyElement` can have a `foo` event dispatched on it and thus should provide and support the `onfoo` attribute and property):

1. A property like `observedAttributes`, producing a sequence of event names (`['foo']`). `customElements.define` would then add the properties to the class prototype at that point (this is feeling like metaclasses) and set whatever monitoring for the HTML attributes is required in place.

2. Make an extra function call (`customElements.defineEventAttributes(MyFancyElement, ['foo'])` or similar) which adds the properties to the class prototype and sets things up, rather than making `customElements.define` do it.

(If we wait for standardisation of ES7 decorator proposal they could make the latter approach neater. Aside, I’d like `customElements.define` to support being called as a decorator.)

This proposal is easily polyfilled; https://github.com/chris-morgan/custom-element-events is such a polyfill (using the second approach, so it can sit on top of a native implementation or a polyfill).

---

There’s also the possibility of making this more general, using the second approach but making it work with *any* element by putting the property on `HTMLElement.prototype` or similar. This would make custom events work as expected for *any* element, and is not a bad idea. This would take it out of the scope of Custom Elements specification, though, and I’m not sure where it’d wind up, though still as a part of the web apps working group, I imagine. Maybe it’d be a new specification. I dunno. Anyway, I wouldn’t object to it being implemented generally like that. I believe it should also be straightforward to polyfill, I believe.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webcomponents/issues/546