Add a meta tag to indicate custom elements manifest location on webpage

[Matsuuu]

Documented here: #70

As in some situations, the tooling might not have access to a package.json, it would be beneficial to be able to indicate the location of the custom elements manifest in the html page. A meta tag should be enough for this.

This came up in a discussion with @claviska (https://github.com/claviska), when discussing CEM and DevTools support with the shoelace documentation site.

This would allow documentation sites to indicate the location of the CEM through a meta tag, allowing the devtools to find the manifest for an enhanced experience on the docs page.

[justinfagnani]

I'm not quite following the use case here. Is the idea that the devtools extension will know how to enhance the docs pages somehow? It seems like it'd be better to include whatever functionality is needed right in the page so that viewers don't have to install an extension or open devtools. We can build really nice documentation components to cover these cases, yeah? What kind of enhancements are we talking about?

[Matsuuu]

The devtools case maybe wasn't the best example here. But the use case that raised this need was that you would be able to inspect and fiddle with elements in a storybook/custom similiar environment (shoelace.style in this case).

But thinking about this more, I think it'd be beneficial to allow sites without a package.json or other configuration to allow tooling to discover their custom-elements-manifest more reliably. As the adopting of the CEM grows, more tooling could utilize the meta tag to reliably find the manifest, instead of the developers having to declare it explicitly to every tool.

Cases that come to mind would be a cataloging crawler, something like the custom elements locator. As those tools might not have access to any other reliable source to confirm the location of a custom-elements.json, They'd have to either guess the location, or fetch it from the meta tag.

[Matsuuu]

Nudging this.

shoelace.style has already adopted this pattern and it is a fairly small thing for the developer to do to add support for more easily discoverable CEM's that I don't see a downside on adding this to the README.

The PR here #70 also has a few of the web component people thumb upping it, so I'm guessing this is a feature that would be wanted

[Malvoz]

If metadata as described here is needed, wouldn't a link relation be more suitable?

https://html.spec.whatwg.org/multipage/semantics.html#the-meta-element:

The meta element represents various kinds of metadata that cannot be expressed using the title, base, link, style, and script elements.

https://html.spec.whatwg.org/multipage/semantics.html#other-metadata-names:

a new metadata name should not be created in any of the following cases:

• If either the name is a URL, or the value of its accompanying content attribute is a URL; in those cases, registering it as an extension to the predefined set of link types is encouraged (rather than creating a new metadata name).
• [...]

[justinfagnani]

I'm still very confused by the use case here. Where are the manifests going to be stored? Is there a canonical location like unpkg.com? Or should libraries host their manifests somewhere? Should the be versioned? How are the <link> tags going to make it into the page? If a page uses elements from many libraries, should they have many link tags?

Then, what's the use case for a public page to have its manifest(s) published? Is there any precedent with JS libraries, like a <link> tag for saying which npm packages a page uses?