Requiring imports can be suboptimal for custom element layered APIs

[domenic]

(See this document for a more thorough analysis of import-related options.)

HTML parsing

For the initial page’s HTML, the HTML parser will parse elements as HTMLUnknownElement instances until the author has imported them. This is both slower (assumedly; no data available) and just kind of weird for platform built-ins to do, even if those built-ins are layered APIs.

On the other hand, this is the same problem that web components have to deal with already, so maybe it’s not a big deal. Or maybe we need to solve the more general problem anyways if there is a solution.

Note that in a world with all module scripts, this intermediate state would not usually be observable, since module scripts run in order. Thus, assuming layered API scripts are placed first, they would run first and upgrades would complete before author script.

HTML snippets

Sending around snippets of HTML (e.g. in emails, copy-paste, etc.) doesn’t just work anymore. You need to also include the import statements. This bloats the snippet, but more importantly, it’s hard for web authors to do.

Again, this also affects web components, so might be something we need to solve more generally anyways.

A possible solution is to allow for web component authors to create a manifest of tagname → component library and have the browser have a default manifest for its built-in layered APIs. Then, for parsing HTML, we would pre-parse (e.g. just tokenize) to grab all the tag names and import the libraries up front before we do the component initialization. We might still require an import, but you’d just import the manifest instead of needing to know the contents of the HTML.