Lack of implementations of customized built-in elements is hurting Web Components

[prushforth]

The spec says we should be able to extend or at least use built-in elements as the author interface to our custom elements, but currently no browser supports this facility and indeed the polyfill libraries which might implement this part of the spec are shying away from it, even though the community has provided the code for it. We want to know what will happen to our already implemented web components which rely on previous versions of libraries, and when. Not being able to count on an outcome is hurting web components overall, for example because we are not able to port our customized built-in components to the newer versions of these libraries and are not able to present them with pride.

If the mechanism for customized built-in elements is to be deprecated, please give us an alternative that achieves the same goals, and/or remove it from the spec so that we can plan / move on.

[annevk]

FWIW, I think the status quo is still such that Safari does not want to implement this, but everyone else is okay with it.

[prushforth]

I think we (the community) understand that re: Safari. I believe it is that issue that is blocking the library devs, if not (other) browser devs from proceeding on implementation. In the meantime, we're blocked, after having made such good progress in v0, we can't fully get behind v1 until we can participate.

Anyway, thanks for that.

[trusktr]

@prushforth #509 has discussion about it.

[prushforth]

Disagree with the premise of that post, and besides its part of the spec so need to have a resolution. As I mentioned, the community has provided polyfill code, so it would be important to keep the spec authors, implementors and community on one page.

[tomalec]

@prushforth There is an alternative polyfill https://github.com/WebReflection/document-register-element.
It has some ceveats. Hopefully you could use it to move on and don't have to wait for Polymer team to merge community PRs.

[prushforth]

Thanks for bringing that to my attention. I will definitely check it out, and I think there is a lesson for the big teams working on web components that the community who is actually working in these things, and not just talking about "issues" needs to be taken more seriously. The fragmentation that arises from not taking them seriously hurts the efforts of the big teams to create a viable standard. That is all.

[matthewp]

I don't think it's fair to say that people working on this spec are not taking it seriously. I think there's just simply disagreement that has not been resolved. Hopefully it will over time? Since words have not worked to convince all vendors of this feature's worth, I think the only thing you can do is use the polyfills and make cool stuff that take advantage of this feature. And hopefully seeing all of the cool stuff created pushes the one vendor to change its mind.

From my perspective, the lesson is not to standardize something that there isn't consensus on.

[prushforth]

That is a fair comment regarding standardizing something that doesn't have consensus. OTOH, that is why polyfills exist, and if you look at caniuse.com I think it is clear there are many many things which will never be implemented by all browsers.

I guess my concern is that no vendor appears to be working on either a native implementation or a polyfill even, and even when the polyfill is available from the community, the flagship library promoting Custom Elements won't accept the PR.

Finally, the reasons that a vendor gives for not implementing a feature are often not clearly articulated to the community. In the case of customised built ins, we heard something about liskov substitution principle; with imports it was wait and see how modules turn out. Never any specifics, and certainly not done in public, like for example discourse.wicg.io/