How many other pieces of the platform does this depend on that are not yet implemented across browsers? (Things that aren't yet implemented across browsers should be viewed as somewhat less stable, since it's not yet clear how they will change when they are implemented in the other engines, or in fact whether they will be at all.)

Can you clarify the question? As a new HTML element, it doesn't really depend on anything. Browsers already have the ability to implement new elements.

If browsers want to use custom element to implement this, then they'd want to use the form participation API, as @tkent-google mentions. But that's an implementation choice for each individual browser, not exposed to web developers.

The explainer says that the element is provided as a built-in module, and import 'std:elements/switch' is needed to use it. Is that actually not the case?

That is the case. All browsers implement modules, if that's what you're asking?

So if a browser chose to implement it natively, they'd have to provide a dummy empty built-in module so the import would succeed and the script using it would run? (Is that how error handling for built-in modules works? Should it be, given that built-in modules wouldn't land in different browser engines at the same time? Where's the current spec/explainer for built-in modules? And implementation status of built-in modules, not just modules in general?)

Ah, I think I see what we're missing. We don't have a rigorous spec (or even part of the explainer) explaining what the module import does.

The intention is for the spec to require that any implementation (no matter whether C++ or JS or Rust) not interpret std-switch elements until the corresponding module is imported. (I.e., they are treated as HTMLUnknownElement.) We should add this to the explainer. Certainly it's top of mind as we move toward writing a spec, but it should be captured in the explainer stage as well.

The current spec for built-in modules is https://github.com/heycam/webidl/pull/675. There isn't a separate implementation status for built-in modules from the features that are implemented as built-in modules; it's just a technology, like other parts of Web IDL, that can be used for implementing web platform features. Similarly, allowing web platform features to use the JS language's module system doesn't have a dedicated explainer, kind of like how async_iterable (allowing web platform features to use the JS language's async iteration features) or maplike (allowing web platform features to have APIs similar to JS's Map) don't have a dedicated explainer. It's largely plumbing between web specs and JS specs.

Some of your parenthetical alludes to how web developers can use a feature provided as a built-in module even in browsers that don't implement that built-in module. With built-in globals, this is easy: web developers use well-known polyfilling techniques like window.SomeGlobal = window.SomeGlobal || .... For built-in modules, new technology is indeed needed. That is covered by https://github.com/WICG/import-maps (#340), in particular https://github.com/WICG/import-maps#for-built-in-modules-in-browsers-without-import-maps.

Thanks for these questions. Besides explaining that importing the module has that side effect, do you think any of the other things I listed would be helpful to have in the std-switch explainer?

Problems with this approach (also mentioned in https://github.com/w3ctag/design-reviews/issues/385):

• I think we need to find a way to avoid most/all future HTML elements having a std- prefix. It will make HTML quite unpleasant to read if we project out a decade or so.

• Having to do an import per-element doesn't seem like it scales well.

And after reading the comments here, I'd add:

• It's weird for built-in HTML elements to pick up the quirk of custom elements that they start out as HTMLUnknownElement.

These problems are solvable with some thought. It's probably worth taking some time to try to solve them before building a lot of these on top of the currently browser-specific concepts of built-in modules (which overlap with but don't quite match the JS standard library proposal), import maps, and this specific approach to adding new built-in elements.

If a new HTML element was being designed without trying to fit into this not-quite-yet-standard module approach, I don't think it would have any of the bulleted properties above. In the past, mostly-polyfillable elements have been defined in a way that accepts less than 100% fidelity of the polyfill, less than 100% transparency of adding the polyfill, or graceful fallback approaches other than polyfills. It's not clear that these new quirks are a good tradeoff for transparent 100% polyfillability.

(I think fewer of these objections apply to built-in modules being used to add new script APIs.)

Additionally, it seems to me that the std: prefix and its intended use needs a spec. Neither the Web IDL PR or the import maps explainer really define it, and it's not even clear if it is meant to be a specific thing like the proposed JavaScript standard library js: prefix or just an illustration, where built-in modules could use any prefix.

There are some advantages to having this as a standards module (or similar) as it's opt in.

The bar for landing new HTML elements is extremely high, like "needs to be used my most sites", which makes it hard landing elements that are using for a large percentage of sites, but not what is considered "most". This makes it pay-as-you-go.

This also means that as it is opt-in, there is less of a change of conflict with existing APIs (like if we remove the requirement for using - in the element name - though I can live with std-*).

Having to do an import per-element doesn't seem like it scales well.

Editors seems to be quite good at auto including things when used, and prompting when things are not used (DevTools could do the same). It is also not very different from how it is when using frameworks today - developers include components/elements all the time.

We might need a more declarative (non-JavaScript) way of loading these, but I assume this is where HTML modules fit in. Can you confirm @domenic ?

There are some advantages to having this as a standards module (or similar) as it's opt in.

The bar for landing new HTML elements is extremely high, like "needs to be used my most sites", which makes it hard landing elements that are using for a large percentage of sites, but not what is considered "most". This makes it pay-as-you-go.

I believe the intention is elements defined this way will be specified in the HTML standard, and will be shipped along with browser implementations (whether implemented in JS, C++ or Rust). That means they are not opt in or pay as you go from the perspective of standards or implementations, only the perspective of the default element namespace.

That's not to say doing things this way is a bad idea. But I don't think it lowers the bar and I believe it's not intended to. Switch is a popular request and probably as widely applicable as existing built-in form controls

Having to do an import per-element doesn't seem like it scales well.

Editors seems to be quite good at auto including things when used, and prompting when things are not used (DevTools could do the same).

Imagine a future where most or all elements added to HTML from now on each are each in their own built-in module. I think this is the intent of this approach, though it's being floated one element at a time. There needs to be some discussion of the design pattern on the assumption that it's meant to be applied very broadly.

In this future, for a typical webpage or web app, you might need to import 20 or 30 modules for all the elements you need. Then it's not so nice, even if some editors can help add the boilerplate. By contrast, many native UI toolkits let you import all available views with a single import/include statement.

Maybe the right answer is to have modules for related groupings of elements, instead of one per element. But then there's a versioning problem - if a new element is added to the group, Import Maps are no longer good enough to polyfill only the new one in older browsers, while using built-in implementations of the rest. But then again, this problem exists to some extent even at single-element granularity. If a new method, property, attribute or behavior is added to an element in a built-in module, there's no longer fully transparent polyfillability via Import Maps; instead old-school polyfill techniques for adding such things must be used, and may not even work in some cases (e.g. added method needs access to non-public state of an element).

Using built-in modules for elements opens up a lot of cans of worms that don't apply to using them for scripting APIs. It's good to have this (and the std-toast proposal) to use as concrete examples while thinking through those issues.

For context, the above comment is the same as https://github.com/w3ctag/design-reviews/issues/385#issuecomment-501708682

I don't think it's productive to say that the std-switch proposal or the std-toast proposal seem like vanity projects.

Also, for this proposal, the problem was discussed in a whatwg/html issue first. https://github.com/whatwg/html/issues/4180

I've posted https://github.com/whatwg/html/issues/4696 and https://github.com/whatwg/html/issues/4697 to centralize discussion around polyfillable element names and pay-for-what-you-use HTML elements, which I think is the majority of feedback so far.

What is the future of this proposal given that Web IDL modules don't seem to be moving forward (heycam/webidl#675)?

What is the future of this proposal given that Web IDL modules don't seem to be moving forward (heycam/webidl#675)?

Yeah, people are skeptical about JavaScript standard library, and we should reconsider this proposal too. Let's close this review request for now.