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

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 quirks 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 "js" prefix or just an illustration, where built-in modules could use any prefix.


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

Received on Thursday, 13 June 2019 02:04:12 UTC