`tagName` should not be part of the manifest

[Andy Earnshaw]

This might prove controversial, especially since the practice of a library registering its custom elements is already commonplace in most examples I see across the web. Even the example in the README here defines the element just below the class declaration. Everyone seems to have forgotten that global namespace pollution is bad and people are repeating the same mistakes made in an old paradigm of library development before module scoping made everything better.

If your library defines its custom element when it is imported, then it will suffer some of the same pitfalls that polluting the global object presents.

// This is a bad practice
window.jQuery = jQuery;

// So is this
customElements.define(
  "awesome-element",
  class AwesomeElement extends HTMLElement {
    // ...
  }
);

You might argue that collisions are less likely with custom elements, given the forced hyphen. However, what if I have two dependencies that rely on different versions of awesome-element? Those dependencies should attempt to define each version of the element under their preferred tag name (ideally in a scoped custom element registry if it ever becomes standardised).

If you can agree that the above makes sense, then the logical conclusion to be drawn is that tagName should not be part of this manifest.

[Pascal Schilp]

I dont think this is controversial at all, but browsers do support registering custom elements on the global registry however, so I think it makes sense that the manifest supports tagName.

[Andy Earnshaw]

@thepassle I'm not sure if you understood my post. I guess the gist of it is that having tagName in the manifest (and the example in the README) promotes bad practice. Browsers support registering on the global registry, but any library or package exporting a custom element should not be doing that registration, it should be up to the consumer. Therefore, the tagName should not be in the manifest because it should not be decided what the tagName is by the library or package exporting it.

[Pascal Schilp]

I understood your point, but my point still stands. You can globally register custom elements in the browser, and in many cases this is not actually a problem. There are indeed cases where you'd need something like scoped elements. If you register a custom element in the global registry, you can use it via that tagName in your HTML, and a browser will know what to do with that element, so it still makes sense to support tagName in the manifest regardless of your opinion of it being a good or bad practice.

[Justin Fagnani]

To reenforce @thepassle's take here - the CEM is trying to describe what packages of elements can do, not prescribe what they should do. If there are elements out that the use global registration, this format should have the structure to say so.

That could enable tools that detect tag name collisions, or disallow using the global registry altogether, if that's your goal.