This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The proposed lifecycle callbacks are awkward when one compares them to other JS components which dispatch native events. The usual approach to callbacks is that the component instance is an `EventTarget` and events are dispatched as `target.dispatchEvent(e)`. As an alternative, there can be event handler callback functions assigned to the `EventTarget` instance. For example, if there is the `READY` event, the `Element` (being an `EventTarget`) fires 'ready' events that can be listened for via listener callback functions added as `element.addEventListener(type, listener)` or via event handlers added as `element.onready = handler` It does not make any sense (at least to me) to introduce a new way of doing callbacks when there are two ways implemented throughout the whole DOM (and other places). The proposed callbacks should be converted to events as: - readyCallback -> READY, 'ready', onready (or should it be rather CREATE?) - insertedCallback -> INSERT, 'insert', oninsert - removedCallback -> REMOVE, 'remove', onremove This also allows for a seamless integration with existing libraries such as jQuery, Google Closure Library and others.
I think the intended use of these callbacks and DOM events are different. These callbacks are used by the implementation of the custom element. The created callback is like a constructor, for example. If a particular custom element wants to turn around and dispatch an event in response to one of these callbacks, it can do it. I think the integration with existing libraries will come at that level. The custom element translates the raw, low-level callbacks into some more meaningful, higher-level events that make sense for that particular element.
Right. Custom element callbacks are at a lower primitive level, compared to events. Also, event dispatch is an incredibly expensive process, and we certainly don't want the repeat of the mutation events. BTW, this has been discussed ad nauseam on public-webapps (like on this thread here: http://lists.w3.org/Archives/Public/public-webapps/2013JanMar/0790.html).
Oh, now I understand. That is reasonable.