idea: it might be worth doing a PR to mrhenry/polyfill-library

[kapouer]

The polyfill-library is a module for building bundles based on feature-detection or user-agent detection.
It has bad reputation because of the polyfill.io security debacle, however it is still very much useful.
The hard part is to correctly define the dependencies of view-transitions-polyfill w.r.t. polyfill-library.
For example, view-transitions-polyfill depends on CustomElement, which is not yet available as a polyfill, so opening a PR there is too early.
Does it depend on other recent DOM/CSS features that might have existing polyfills ?

[demarketed]

Some newer browser features that the polyfill depends on (other than CustomElement) are the Web Animations API (notably Element.animate() and Document.getAnimations()) and requestAnimationFrame().
It uses the new CSS :where() selector, but it is not necessary.
Everything else is just ES6 or common DOM methods.
Technically, the polyfill could be refactored to avoid using custom elements, replacing things like <view-transition> with divs, and the style encapsulation provided by Shadow DOM is not strictly necessary.

[kapouer]

What features it depends on are very interesting informations - it might be worth adding them to this project's README.md.

As you can see here, animate is polyfilled, as well as requestAnimationFrame.
However, getAnimations isn't, as we can see in WebAnimations polyfill project.

At some point it's interesting to see if your providePROJECT can provide a degraded version (or not ?) if getAnimations isn't available.
For CustomElement I started to ask them if they're okay to add it.
For Shadow DOM it's a lost battle. It might be a good idea to try to not depend on it.

[demarketed]

I'll add information on notable features required by the polyfill to the README. Maybe I could start working on a degraded version in a separate branch.