A toggle switch control element #384
I'm requesting a TAG review of:
You should also know that...
An implementation of this feature could be a custom element, and depend on Form Participation API, of which TAG review is not completed yet, but the feature itself doesn't depend on it.
We'd prefer the TAG provide feedback as (please select one):
Needs a venue
Jun 11, 2019
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.
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 heycam/webidl#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
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 #385):
And after reading the comments here, I'd add:
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
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
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.
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
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
according to this page:
i am counting at least 200 HTML elements currently (forgive if my selector is bad):
are we really saying that none of the current elements can fill this role? I agree with @zcorpan, this seems like a vanity project and should go through the normal process. not be rushed through "because google".