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 most 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 ? -- 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-501625324
Received on Thursday, 13 June 2019 09:28:08 UTC