[idea] making builtin elements more like custom elements

[trusktr]

If you imagine builtin elements as having the same underlying building blocks as custom elements (i.e. the Web Manifesto explains builtins, and we can do the same stuff in custom elements), then one would think that we could do the following:

const oldConnectedCallback = HTMLVideoElement.prototype.connectedCallback

HTMLVideoElement.prototype.connectedCallback = function() {
  oldConnectedCallback.call(this)

  // ... do something any time a video element is connected ...
}

I think it'd be nice if this were possible.

This would make it simple to implement a lot of stuff. For example a childConnectedCallback (described in #550) could be easy:

const oldConnectedCallback = HTMLElement.prototype.connectedCallback

HTMLElement.prototype.connectedCallback = function() {
  oldConnectedCallback.call(this)
  this.parentElement.childConnectedCallback && this.parentElement.childConnectedCallback(this)
}

Would it be easy to move existing logic of builtin elements into lifecycle methods without breaking existing sites?

If we wouldn't want to do this, why not?

[andyearnshaw]

As mentioned in #550, the main arguments against childConnectedCallback were performance related (the main reason mutation events are also inadvisable). I think those objections preclude adding anything that would make it straightforward to implement the same thing in a roundabout way such as this.

Speaking as someone who has used a lot of hacks to work around otherwise-unassailable problems over the years, I see this as something that would be used in much the same way. When you find a lot of dependencies all using this technique to work around their own otherwise-unassailable problems then you can find yourself deep in performance issues. Imagine thousands of nodes being connected at once, each one triggering your function, which adds more nodes, which triggers more connected callbacks. Now imagine your dependencies doing the same thing in addition. This kind of impact is detrimental to the web, even if you have good use cases and intentions.

Besides the performance implication, this suggestion renders closed shadow trees nearly pointless. Although it is easy to override attachShadow to prevent closed shadow trees, that's an intentional action that requires awareness of the consequences of doing so. Providing any override method on all elements means that closed shadow tree access and mutation could happen unintentionally (by accessing this properties within the override).

[domenic]

The way built-in elements work is similar to the following code:

class SomeBuiltinElement {
  connectedCallback() {
    // do something
  }
}

// This call causes the system to store SomeBuiltinElement.prototype.connectedCallback for later use.
customElements.define('somebuiltinelement', SomeBuiltinElement);

// But, it's not accessible to users.
delete SomeBuiltinElement.prototype.connectedCallback;

[rniwa]

We're not going to do this due to performance issues but also because browser engine code needs to update its internal states prior to start invoking JavaScript. It's simply not attainable to make all builtin elements' implementation work with the proposed API.

It's possible we can add some mutation observer observation records for when a node is connected or disconnected though.

[caridy]

A much lower level api like the one described in whatwg/dom#533 should be sufficient.

[trusktr]

Ah, yeah, I think that'd be nice!