A way to define custom built-in element

[Lodin]

Just found that defineCE function serves only for Custom Elements but cannot define Customized Built-In Element. Can we add a new function to helpers? A signature could be like the following:

function defineCBE<TBase extends Constructor>(klass: TBase, extends: HTMLElementTagNameMap): string;

And usage:

const tag = defineCBE(MyElement, 'input');
const myElement = await fixture(`<input is=${tag} type="text">`);

[daKmoR]

We left that out on purpose as Customized Built-In Elements are part of the spec indeed but Webkit e.g. all Apple products will not implement it. (also I think it is not polyfilled by webcomponentjs)

Therefore such elements will never run on Iphone, Mac or Safari which is probably something you will want in most of the cases.

What is your use case for it?

[Lodin]

Well, a lot of them. My project, Corpuscule, supports Customized Built-in Elements as first-class citizens, so I need to test them. For now, I use native API with a generated name, but I would prefer to have all the tools in one place. Customized Built-in Elements is an official specification after all, why should we restrict using it?..

Regarding polyfill: not sure about webcomponentsjs, but there is a very small polyfill from Andrea Giammarchi that allows using this spec on Safari.

[daKmoR]

Safari has introduced Custom Elements v1 in March 2017 and since then it never supported Customized Built-in Elements.

Even way before in 2016 they said they will never implement this part of the spec.

Like we've stated multiple times in the past, we're not going to implement custom builtin elements in WebKit but all other aspects of custom elements should be interoperable across browsers.

Quote from: WICG/webcomponents#544 (comment)

I believe as Open Web Components we should not recommend something that will "forever" require a polyfill in Safari.

PS: As soon as safari would show any intend to implement this - then this would be whole different story.
PPS: besides that the function signature looks good - so how about publishing it independently? We could link it in the documentation 👍 (with a fair warning)

[Lodin]

Ok, I see your point. Quite sad that Customized Built-In Elements have such a fate. I see them as a handy tool.

PPS: besides that the function signature looks good - so how about publishing it independently? We could link it in the documentation 👍 (with a fair warning)

Nice idea, I'll think about it.

[nweldev]

@daKmoR as I'm working on this topic right now, I would be happy to create this helper.

Now, Apple has obviously chosen to slow down any progress on WebKit, and by consequence, all the Web. So I prefer to advocate for considering Safari as an obsolete browser (like IE) hoping that they reconsider their position on this matter and many others.

If you still consider relevant the (very valid) point you previously made, I would be happy to create this helper as part of fullweb.dev and to make a PR linking it in the docs.

[bennypowers]

The problem is that Apple maintains an iron grip on their platform, enforcing a monopoly by not allowing browser engine competition. There's literally no way to use customized built ins on iPhones without a polyfill. And Apple, as you know, commands a sizeable share of the marketplace.

Apple is firm on both points: they will never support customized built in elements on their devices, and they will not allow any one else to either.

We here at open-wc would love to recommend customized built-ins. We see it as an important and useful part of the spec, but we are unable to convince Apple to do the right thing here, so we can't just throw Apple's customers under the bus.

Unfortunately, for the time being, customized built in elements will have to remain a userland feature.

[nweldev]

Thx @bennypowers for this answer. I totally agree with you on most of what you say here. Yet, I can't see how dynamically loading a very light polyfill, that isn't drastically affecting performance, for a standardized feature, could be "throwing customers under the bus". I would love to read more details about that, and why you globally do not recommend to use customized built-in elements, for my own education. Only discussions I could find about this in WhatWG / W3C lead me to think everybody agrees with the standard and continues working on it ... except for WebKit of course ...

[bennypowers]

you're right @noelmace that's a needlessly strong phrase to use here.

A good analogy is import maps. We have lots of plans for supporting import maps throughout our tooling, but since the spec is still up in the air, we're not recommending it yet.

All the more so customized built-ins, for which there's absolutely no hope that they will ever be implemented (barring some movement on Cupertino's part), we can't recommend them.

Sorry, "Safari doesn't count" isn't something we can reasonably recommend at this point

[nweldev]

Thx, now I better understand your point of view 🙂

Even if, well ... (sorry I can't help myself) customized built-in elements have been standardized in 2016 and are now supported by all <troll> modern </troll> browsers, while imports-map is still a WICG draft, but let's just aggry to disagree 😉 Nice to exchange ideas with you anyway.

So, what do you think about @daKmoR comment?

PPS: besides that the function signature looks good - so how about publishing it independently? We could link it in the documentation (with a fair warning)

Should I release this kind of helper anyway as part of my own project, and make a PR linking it in the docs? I won't do that right away, but it would be good to know your opinion on that matter for the near future.

[bennypowers]

I think that would be helpful to lots of people.

Personally, I do all kinds of non-standard things in my project - importing css and graphql files usually.
I published helpers for those, but not under open-wc, which has different goals

[nweldev]

Ok, so I'm adding this issue to my TODO list then. Could you reopen it so that I don't forget to send the PR please?

Also, nice to know about your other projects, I will keep an eye on that then, thank you!