Introducing new HTML elements that are polyfillable

[domenic]

Recently, my team (within Chrome) has been working on initial explainers and explorations for new HTML elements: a virtual scroller, a toggle switch and a toast. There are a couple common issues we're attempting to tackle with these that need a central place to discuss, and the whatwg/html community is a good place to have those. These issues are polyfillability, and pay-for-what-you-use. They are somewhat connected, but I want to try to use two separate issues to discuss them; we'll see if that works. This issue is about polyfillability.

The problem: if we introduce new HTML elements the same way as we have in the past, they are not polyfillable, because custom elements are restricted to have a dash in their name, whereas built-in elements traditionally do not.

In the past this hasn't been too much of an issue; we'd introduce new HTML elements that aren't polyfillable anyway, such as <dialog> (magic top layer/inertness), or <details> (magic slot=""-less shadow DOM and marker rendering). Some new element proposals follow this trend: e.g. <portal> introduces a fundamentally new way of dealing with browsing contexts, that needs deep integration into the internals of browsers. But the ones I mention above do not; they explicitly attempt to follow the extensible web manifesto and not build any new magic into the element. I.e., if it weren't for the dash issue, they would be polyfillable.

There are several potential solutions we've thought of so far. I'll outline them here, but I'm sure the community can think of others. Note that the specific names ("virtual scroller", "switch", "toast") are used as examples, and discussions on those repos may point us toward better names (e.g. WICG/virtual-scroller#163).

1. Introduce a new dash-containing prefix for such polyfillable built-in elements, e.g. <std-. Use it everywhere. Result: <std-virtualscroller>, <std-switch>, <std-toast>, ...

2. Ensure that such elements have at least two words in its name, and separate them by dashes, instead of HTML's usual <textarea> or <frameset> convention. Result: <virtual-scroller>, <toggle-switch>, <toast-banner>, ...

3. Minimize visual noise by just using a dash suffix. Result: <virtualscroller->, <switch->, <toast->, ...

4. Lift the restriction that custom element names require a dash, thus allowing them to be used to polyfill built-ins. Result: <virtualscroller>, <switch>, <toast>. This is where things get interesting; let's dig in to the details.

   • Why did we divide up the namespace in the first place? To avoid future conflicts with new browser-provided elements. I.e., what happens if code does customElements.define('awesomeelement'), but browsers later introduce a native <awesomeelement>? It would either break web pages, if we made customElements.define() throw, or it would require extra work from browsers, to allow native <awesomeelement>s to get converted into custom <awesomeelement>s (probably using a variant of the custom element upgrade machinery). Note that one route out here is to implement that conversion.
   • But this issue is predicated on browsers introducing new elements to the global namespace. What if they didn't, or did so only rarely? For example, if we declared that all new elements will not be added to the global namespace, but instead only appear to pages that load a corresponding built-in module, then there would be no future collisions to worry about.
   • Even in today's world, the custom element dash restriction is not a guarantee of conflict avoidance. Authors are already using non-dashed element names, e.g. https://www.apple.com/shop/product/MRXJ2/airpods-with-wireless-charging-case uses <favorite>, <overlay>, <loader>, <content>, and <validator>. Or the famous picturefill incident. In practice, introducing a new element already requires some compat analysis on the existing web. So one possibility is that we could say that most new elements (maybe, all polyfillable new built-in elements?) use a built-in module or other opt-in form, but if we really need something baked in to the global namespace, we can do some compat analysis and figure out a name that works.
   • We could continue to encourage a cultural norm that dashes be used for most custom elements, reserving non-dashed custom elements mostly for polyfills. It's unclear whether this would work, but we have weak evidence, from the fact that relatively few sites are using undashed non-custom elements such as <favorite> or <loader>, that the norm might continue to hold.

Looking forward to hearing folks thoughts!

[matthewp]

Would it be possible that <toast> is essentially an "alias" for <std-toast>? That way <std-toast> is developed with the constraints that it be polyfillable, but there is a nicer-named <toast> as well that is the same thing. Most developers with use <std-toast> until some future date when browser support meets their requirements, then they would switch to using <toast> instead.

[zcorpan]

I think 4 is much better than 1-3. But it should be coupled with strong recommendation to not use dashless names except for polyfills. (Edit: conformance checkers can check for this!)

In practice, we have the problem of web developers polluting the standard's namespace in JS, DOM, and even HTML attribute names (when they are reflected as IDL attirbutes, as most are). Maybe we consider HTML elements names to be more holy, but if so, our standard HTML element names shouldn't be "ugly".

[zcorpan]

@matthewp I think that would just mean that all new HTML elements have two names forever, which seems bad. Also, if abbr vs acronym is any indication, it can lead to a lot of wasted time for web developers discussing which one to use.

[Yay295]

Remember when chrome prefixed all in-development CSS properties with -webkit-? Remember when they stopped doing that? Let's not go through that again. Option 4 is the only real option.

[matthewp]

@zcorpan I don't think it would be confusing for long, as developers would quickly recognize the pattern.

I don't mind option 4 here either but it is more complicated. As you note, there is advice on attributes not to use non data- custom attributes but yet it is very common to do so anyways. Unless the language restricts it, people will do so. But it's also true that people already do use non-dash names, just without going through customElements.define().

[dbatiste]

I think for 2, there's bound to be new elements that this convention doesn't work well for. 3 just seems like a weird version of 1.

Re the point in 4...

We could continue to encourage a cultural norm that dashes be used for most custom elements, reserving non-dashed custom elements mostly for polyfills.

We build lots of custom elements, and we certainly would not want any conflicts so we would almost certainly continue our convention of prefixing our components (including hyphen). If built-in elements are to be explicitly imported (as described in your pay-for-what-you-use post) then such possible conflicts would be avoided. On the other hand, if they are lazily loaded by the browser without explicit import, then I think collision may be a concern.

[othermaciej]

Comments on the grand naming problem

I tend to agree that option 4 is the least bad of these.

But there is also option 5: don't aim for perfect polyfillability for new elements by client-side JavaScript.

The idea of perfectly polyfillable new elements, in cases where an element can be implemented on top of existing functionality, is cool. But it's not so cool that it's worth it at any cost. Weird naming artifacts are not a cost worth paying.

I think all the options that leave a visible artifact in the names of elements are not good if you project forward to the future. Imagine all new HTML elements follow this convention. Any HTML source that heavily uses new elements would be awkward to read. If only elements believed to be polyfillable at the time they are standardized followed the convention, that would be even more strange. A mysterious marker in the element name for what is at a spec-level implementation detail.

Imposing weird names on standard elements maybe tactically useful for the short term by making the sweet transparent polyfill is possible. But then a strange naming convention is stuck in HTML source forever, even for elements that are implemented directly in browser engines in. And the future is bigger than the present.

[dcleao]

So why didn't the custom elements spec choose to support the well established XML namespaces, allowing non-standard elements to be namespaced to their authors unique URLs?

We would have gotten rid of the name clash problem for ever and ever...
Instead, this incomplete poor-man naming scheme was chosen, and here we are.

What's cheap, many times ends up coming out as expensive.

[bkardell]

@othermaciej can you expand on what you mean by option 5 'don't aim for perfect polyfillability for new elements by client-side JavaScript.'?

I'm not sure specifically how this is different from option 4 and I feel like this could run a pretty wide course of possible interpretations and as there are already a number of thoughts/options here, I would prefer to not confuse the conversation by replying to the wrong one. For example, if there would ever be a new element in the regular namespace, could we for example, use Shadow DOM to polyfill those (or is that something about your perfection comment)? Currently it seems the compromises that @domenic explained which we currently have would prevent this which seemed unfortunate at the time, because while the 'first era' of polyfills helped us move forward, they also kind of informed ideas about how that could be better (a lifecycle and a shadow dom makes it better because your tree- the thing everything uses to reason about everything, doesn't at some undefined point in time disappear and get transformed into some completely different tree and leave you with two sets of relationships to deal with) -- but to me, at the time, seemed like a conversation which could be had at another time (like, now perhaps).

[Yay295]

@dcleao I suppose that could still be added, though I haven't looked into it at all. It wouldn't fix existing uses, but it could help with future uses.