Introducing new HTML elements that are pay-for-what-you-use

[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 pay for what you use.

The problem: adding new features to the global namespace, including HTML elements, increases the weight of every web page. Each individual feature is not very costly, but together they create a tragedy of the commons. The fact that features baked in to browsers are loaded for every page creates an attitude that more features belong in libraries, and less in the platform. But this leads to a fundamentally unergonomic platform, where you have to pull in large libraries (of inconsistent quality or accessibility) to accomplish basic UI patterns (such as, but clearly not limited to, virtual scrollers, toggle switches, toasts, etc.). We're hoping that by finding a new way to make HTML elements (and other APIs) pay-for-what-you-use, we can break the web out of this paradigm.

Elsewhere on the platform, we're exploring a solution for this problem via built-in modules, imported via the JavaScript module system. For TC39 specs, the JavaScript standard library proposal is meant to power APIs such as temporal. For web specs, the Web IDL modules infrastructure is meant to power specs such as KV storage. Overall, I think there is general interest from both the browser and implementer community in built-in modules as a solution for new JavaScript APIs.

This discussion is about how we can accomplish the same for HTML elements, not just JavaScript APIs. My opinion is that we can use the same solution as the rest of the platform. That is, you can opt in to using a HTML element using the JavaScript module system, e.g.

<script type="module">
import { StdSwitchElement } from "std:switch";
document.body.append(new StdSwitchElement());
</script>

or

<script type="module" src="std:switch"></script>
<std-switch></std-switch>

(Note: check also the polyfillability discussions in #4696, for the <std- prefix.)

Apart from the alignment-with-other APIs question, the module system works well for this because it already has so much built-in: polyfilling via import maps (module the #4696 discussions), lazy-loading via import(), etc. In the past, discussions around adding new systems for loading code, such as HTML imports, have specifically gotten push back from vendors who prefer to use the JavaScript module system as the unifying way to load dependencies.

But, what do others think?

[domenic]

I'll start of the discussion by transferring over from w3ctag/design-reviews#384 (comment), where @othermaciej discusses some potential objections for using built-in modules for new HTML elements, as opposed to script APIs. In particular, the ones that are separate from the polyfillability discussion (#4696) are:

• Having to do an import per-element doesn't seem like it scales well.
• It's weird for built-in HTML elements to pick up the quirk of custom elements that they start out as HTMLUnknownElement.

I'll give my initial impressions here, to start the dialogue, and @othermaciej (or others) can chime in.

I think the scaling should work reasonably well. An import per major API is a pattern we see in many JavaScript-module-based libraries today, including UI libraries. It also encourages finer-grained loading, so that e.g. you only load the switch control once you start rendering the settings page of your app, which needs it. If there are controls we think will always be used together (e.g., a <std-tabcontainer> plus <std-tab>), then they should be in the same module, but otherwise, explicitly stating what you plan to use seems pretty reasonable to me.

I agree that it's a bit weird for an element to start out as HTMLUnknownElement and then transition to something else. I don't see many other alternatives, though. If we allow dynamic loading of HTML elements to achieve the pay-for-what-you-use goal, I think we have two options: upgrade existing instances from HTMLUnknownElement, or don't upgrade them and leave them as HTMLUnknownElement. The former has precedent and infrastructure in browsers, whereas the latter introduces a strange state where some of the <std-switch>s are HTMLUnknownElement and others are StdSwitchElement. I guess a third option could be failing the import if any <std-switch>s exist on the page?

[zcorpan]

Have you considered lazy initialization of features? So you get pay-for-what-you-use by just using the features you need, and the browser paying the cost of initializing those features when they are first used.

[domenic]

@zcorpan, I think it depends on what you mean.

If you do blocking initialization, then I think that works transparently as you envision. This would be similar to a JavaScript API for which you synchronously load the implementation whenever someone first accesses the corresponding global property. This can cause some jank, though, unless everything's already loaded into memory anyway, which kind of defeats the point.

If you do async initialization, in order to get no-jank lazy-loading, then in my opinion having an explicit opt-in, and in particular an explicit point at which the feature is fully loaded, is quite helpful. E.g.

<script type="module" src="std:switch"></script>

<script type="module">
console.assert('on' in document.querySelector("std-switch")); // no longer HTMLUnknownElement
</script>

or

import "std:switch";

console.assert('on' in document.querySelector("std-switch")); // no longer HTMLUnknownElement

or

loadOptionsSheet.onclick = async () => {
  await import("std:switch");
  optionsSheet.innerHTML = `... <std-switch></std-switch> ...`;
};

[Jamesernator]

The one thing I am wary of is a Flash of Unstyled Content with builtin elements.

With user defined custom elements you can use your own logic to determine some initial DOM.

But with these std: elements, you need to effectively reimplement a good chunk of them to prerender them. Worse, because some of them might have UA specific styles you might not even be able to prerender them.

Perhaps there could be a mechanism for blocking rendering of following elements until a module is loaded e.g.:

<script type="module" src="std:switch" render-blocking></script>

The exact semantics that this would need I'm not sure (maybe just hiding the rendering of elements after the current element until loaded).

[Yay295]

I don't think JavaScript should have any say in what HTML objects are "imported" into your page. This seems like something that should be in <head>, like:

<head>
  <meta charset="utf-8">
  <title>HTML Import Example</title>
  <import>
    <switch>
    <toast>
  </import>
</head>

I do agree that this could be a good feature though. This could even help sold the other issue you just created: #4696. One issue mentioned there was that if you define a custom element with JavaScript, and then the element eventually become a standard native element, it could break the page. This wouldn't happen if the native element has to be imported first, because without the import it would continue working as a custom element.

[dbatiste]

@Yay295 : I think lazy-loading via dynamic imports would be worthwhile though.

I agree there is potential for collision if future element is built-in, depending how this works.

[kenchris]

For custom elements you can call https://developer.mozilla.org/en-US/docs/Web/API/CustomElementRegistry/whenDefined

Should this also work for the built-ins? Even if not implemented as custom elements internally in the browser

[zcorpan]

@domenic, I envision sync initialization when used in script, however I suppose it can be hard to define what constitutes "use" in script. createElement and accessing the global are obvious for elements, but maybe there are more.

When an element is found by the parser, it can load the implementation as part of the tree builder, before inserting the element. This would block the parser but not the main thread (except maybe for document.write and innerHTML).

[domenic]

@zcorpan yeah, blocking the main thread on innerHTML or createElement seems pretty bad to me. Especially if you're in a browser that doesn't implement the element, and so you're polyfilling using import maps (#4696 bleeding in to this issue). Then you'd block on a network fetch, not just a potential disk fetch. Async initialization still seems necessary to me if we want pay-for-what-you-use.

[dcleao]

The declaration of a certain XML namespace, used for a certain group of standard elements would support this well.

[zcorpan]

@domenic if you're loading a polyfill, can't that can be done up front and async?

Otherwise, if you don't implement the new element, how would you know to fetch a polyfill from parsing the tag?