Re: [WICG/webcomponents] Anonymous Custom Elements (Issue #1074)

> I was afraid that from an implementation perspective that this might not be feasible. I might have made it harder for myself by using custom element in the title? If we consider `<anonymous>` to be a new type of element that is not connected to custom elements at all does that change how this would related to custom element registries? Or would it still be considered a type of custom elements for implementation properties?

If you want to do the things a custom element does - such as having the callbacks (`CEReactions`) then you need to have a definition, and the definition is kind of handled by tag name. For the most part it would work internally as elements have an element definition pointer, so all the while the element exists, it knows its definition, and therefore can have a backing class, but the problem comes with how you reference it with the existing HTML APIs which are all predicated on tag names; namely serialisation.

> I think that this is actually a fine compromise. The primary use case would be as an alternative to scoped element registries. 

Personally I don't think it is a fine compromise. It makes for inconsistent modelling of APIs. It's very strange to not be able to select for an element because it's missing or otherwise has a generic tag name; it makes for an inconsistent API where _almost everything_ works except for this one new thing. _Selling_ this idea to implementers might be a struggle. 

> In my mind yes, it could be worth it. I don't pretend to know how such a thing could be implemented and what the actual cost is. The fundamental change here is not so much the omission of element name as it is the use ES modules as the primary way to defined elements over element registries.

Implementing such a change could take months of coding, if it were even viable. Analysis would need to be done, each API would need to be assessed and altered. That's if we can get consensus with all the implementers, which alone could take years to come to consensus with all the changes. With the cost of the change should come the scale of the benefit. What comes to mind is a feature like customisable select; a large project that requires significant refactors and has taken years of work. Customisable select has extremely well motivated tangiable benefits though (accessibility, avoiding massive duplication of efforts, etc).

So the challenge with this proposal is if you're proposing a roughly eqiuvalent amount of work, can you advocate that it'll give a roughly equivalent amount of benefit? Having been in a few conversations around standards, I imagine some questions you'd need to answer:

 - Are many people trying to do this today?
 - If so why? What problem does it solve? Are you prepared to talk about the problem space in abstract (without mentioning anonymous elements) that makes a convincing case?
 - How do people solve this today? Are there very popular userland libraries that solve for this today? Are there many smaller libraries that solve this in slightly different ways that deserve convergance?

> Is there problem with userland generated APIs? Is it still the possibility of name collisions?
> Is finding an appropriate tag name non-trivial? In particular if it supposed to be compatible scoped registries too. Maybe a helper on customElements that does some time-based randomization?

You could probably use `crypto.randomUUID()` to achieve something close with incredibly low risk of collisions that would be compatible and usable today:

```js
function getAnonymousName() {
  return 'anonymous-' + crypto.randomUUID()
}
customElements.define(getAnonymousName(), MyExampleElement);
```

I think it would be interesting to find evidence of people using patterns like this (generating random names) which could provide some evidence to this feature being useful. Of course, if you find little or no evidence, it might be a sign that this _isn't_ a feature that people really _need_ or that it really solves a problem for people.

It's an interesting idea with some great out of the box thinking, but browser vendors, in general, want to prioritise ideas that have a good chance of broad adoption that improves the lives of web users; which is their success metric. They're unlikely to pick ideas that offer speculative/specuous returns.

I don't want to discourage you from coming up with many more excellent ideas, I hope you don't see this as me pooh-poohing this one. Just trying to offer some constructive feedback.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/WICG/webcomponents/issues/1074#issuecomment-2384258366
You are receiving this because you are subscribed to this thread.

Message ID: <WICG/webcomponents/issues/1074/2384258366@github.com>