Re: [w3ctag/design-reviews] A toggle switch control element (#384)

> 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.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/384#issuecomment-501637220