Custom elements require dashes in the name

[domenic]

Requiring dashes in the name of layered API custom elements seems unfortunate, and removes the ability to build something like MathML as a layered API without changing the layered API spec to include dashes in all the element names.

None of the proposed solutions below feel particularly satisfying:

• Allow layered APIs to violate namespacing requirements. This breaks one of the fundamental tenants of layered APIs, and also makes it impossible for the polyfill fallback to achieve parity.
• Remove the dash requirement for custom elements in general. If layered APIs really become the way we create all new HTML elements, then we don't need to worry as much about namespace conflicts, since layered APIs must be explicitly registered. Additionally, scoped custom element registries make it even easier to give a specific meaning to an un-dashed tag name without taking it over for the entire page, making this solution more feasible.

If we embrace this restriction, instead of fighting it, we have a couple routes to go

• Prefixing all layered APIs with a standard prefix, e.g. <std-infinitelist>.
• Using the unorthodox, but allowed, convention of "ends with a dash", e.g. <infinitelist->.

[bkardell]

Thinking about this, one thing is unclear to me... Would the module not give you the class and leave it to authors to register the actual tag? I realize that they could only register something with a dash currently, but I'm trying to understand the boundaries here in order to make sure I am thinking about it correctly...Secondly, does this mean that the core dictionary for HTML itself could be largely done and that while the available tags (even natively/provided) can grow, they wouldn't be part of HTML proper?

[domenic]

@bkardell these seem like separate issues from the OP, so maybe we should open new issues (this repo is fine) for them if you think they're worth diving into much further. But let me try to answer here...

Would the module not give you the class and leave it to authors to register the actual tag?

That's one model! However, I think if the idea is to provide something easy to use, requiring a two-step process (import then define) is trickier than requiring a one-step process (just import).

If there are compelling advantages to exposing an element for defining with a custom name, we could consider an additional piece that allows that. For example,

// Automatically defines with local name "virtual-list"
import "std:virtual-list";

// No automatic definition
import VirtualList from "std:virtual-list/class";
customElements.define("my-virtual-list", VirtualList);

Secondly, does this mean that the core dictionary for HTML itself could be largely done and that while the available tags (even natively/provided) can grow, they wouldn't be part of HTML proper?

I think that's possible, but I don't know how the future is going to shake out. Of note, any new HTML elements that expose new capabilities would not be implementable as LAPIs, but I think these days we're probably not in to exposing new capabilities via HTML elements anyway...

[prushforth]

I interpret this in terms of speculative polyfills for a (proposed, nearly standard) but as yet unknown element.

If we embrace this restriction, instead of fighting it, we have a couple routes to go

Another possibility: Could we use the "is" attribute? <infinitelist is="std-infinitlist"> ? When the element ships, authors could remove the attribute and it would activate natively. I guess the situation where 2/4 browsers are shipping the element, could the speculative polyfill be the fallback in the 2 that haven't shipped? The thing is still 'namespaced' by the is attribute, if that is where the browser looks for the namespace.

[domenic]

I'm not sure I understand that suggestion, or the connection to speculative polyfills. Speculative polyfills are not related to LAPIs, and LAPIs are not able to use magic (like defining custom elements with non-dashed names).

[prushforth]

@domenic

I'm not sure I understand that suggestion, or the connection to speculative polyfills.

I can understand your confusion, I should have been clearer. I think the term speculative polyfill is script centric, but is analagous to what I think this topic in the context of layered APIs is partly about (if I understand the whole thing correctly, that is).

Anyway I raised an issue on the speculative polyfills about this, maybe that will help you understand my thinking about this.

[bkardell]

If there are compelling advantages to exposing an element for defining with a custom name, we could consider an additional piece that allows that.

@domenic I can see arguments both ways I guess, it's easier to glean whether something is really successful if we can simply analyze markup with a known name as opposed it variable. Though, it feels easier to spec, write and more flexible to use the other way (where authors define) which is why I guess I assumed that'd be the thing, kind of like importing modules I guess... Idk, mostly I think I was just asking for clarification about the thought process/discussions that had already been had there arguing one vs the other since I'm new to this. .

[prushforth]

LAPIs are not able to use magic (like defining custom elements with non-dashed names)

OK I get it, nothing new, they build on what is already there.

[ojanvafai]

@bkardell I was certainly picturing that the module would define it's element names. While I like the idea of exploring a way to customize the element name eventually, that seems like more of a v2 feature since we won't want to require authors to do the two step dance if they're happy with the default name (which will by far be the common case, right?).