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

Firstly I want to say great job on thinking through an idea like this! Thanks for presenting it, I hope we get to see more ideas from you.

On the surface this might look like a reasonable API, but from an implementation standpoint this would be a significant amount of work; the class is a backing object for the internal "Custom Element Definition", which gets created and attached to the backing class when `define()` is called. Avoiding the `define()` call would mean some kind of "anonymous custom element definition" which would be very difficult to keep track of as most of the custom element APIs are predicated around a custom element definition being attached to a name. This would likely need non-trivial changes to the way HTMLElement constructor runs and require large refactoring of the Custom Element Registry. In addition to those changes, the DOM would need some drastic changes in order to support anonymous HTML elements...

Some things that would be prevented or made significantly more difficult by an anonymous HTML element:

 - Presumably there would be no way to query it via `.querySelector` or CSS, unless you attach a class name or attribute to each one (kind of defeating some of the point of the anonimity, no?). If you used the name `<anonymous>` then it would make it difficult at-best and impossible at-worst to differentiate anonymous elements from eachother. Does the use case warrant effectively hampering CSS like this?
 - There would be no tractable way to call `outerHTML`, or `innerHTML` on a parent. This would probably break a _lot_ of frameworks and libraries. Using the `<anonymous>` tag would mean re-attaching it could potentially change or lose its definition which seems dangerous. Additionally it would be very strange for existing APIs (e.g. `createElement`) to be able to create `<anonymous>` elements presumably have no definition?
 - It would potentially break the design of scoped registries, as there would likely need to be special handling if your element moved to a new shadow root.

Given the amount of work involved on the implementation side (very large and lots of careful refactors required) I wonder if it would be worthwhile? How problematic is giving a name to an element today? Is it so bad that it warrants such a large amount of work and potentially making other APIs more awkward to use?

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

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