I've made a rough refinement proposal to the platform provided behahviors after the hackfest WHATNOT, I wonder what people think
https://github.com/MicrosoftEdge/MSEdgeExplainers/issues/1353

(e.g. keithamus Luke Warlow might be interested)

We can bikeshed on that but if it was static I think activationBehavior can return a LinkBehavior interface etc. we can find a shape for it if it's not static, e.g.

internals.activationBehavio.setLink({href: "/example"});
internals.activationBehavior.setSubmit({formData: "POST"});

const submitBehavior = new SubmitBehavior();

// Throws if element is connected
element.internals.activation = submitBehavior;
submitBehavior.formAction = "POST"

I don't think it makes sense to design individual web platform features to be polyfillable, but I think it's defensible as a goal that the platform should provide the low-level primitives that make polyfilling viable a whole. There are gaps that affect both polyfills occupying the same namespace or ponyfills. For example:

• CSS polyfills currently require refetching and reparsing the entire stylesheet, making individual polyfills effectively unviable
• HTML polyfills that work correctly across shadow DOM boundaries are practically impossible to implement performantly because of the lack of hooks to monitor (even open) shadow roots, monitor mutations across shadow roots, or fetch elements that match a certain pattern across shadow roots.

I would much rather people write a library that demonstrates the need for something

I see "library that implements some feature" and "polyfill" as synonymous, but I can also see that fails to capture everything.

The psychology of the two is completely different. One is introducing another dependency and all the risk-benefit and comparative evaluation that comes with that. The other is simply bridging a gap temporarily, with the intent of being removed later. You're no longer need to evaluate whether an API meets your needs, and can swap one implementation for another with no integration effort. Basically, you get the API benefits of standardization, even before you get the implementation benefits.

Anyhow, my takeaway from reading this discussion (and from some private discussions over the last few days) is:

• it does not appear to be committee consensus that pollyfills are undesirable though we recognize it's a tradeoff and not without costs
• there are some views that ponyfills might be a better solution
• speculative polyfills of still in-design APIs are have a worse cost-benefit than polyfills of mature features
• it's less clear to what extent we consider making their existence possible a standards goal.

Please correct me if you feel this is inaccurate.