@WebReflection Do you think the we should still keep the custom elements polyfill around? I'm sure he has a more complete picture than me.

@WebReflection Do you think the we should still keep the custom elements polyfill around? I'm sure he has a more complete picture than me.

If you don’t use builtin extends and you don’t use the argument in whenDefined resolved promise I think the time to drop that polyfill might be right but I’d rather check dependent projects as they might assume a-frame provides the polyfill and might trust those features so that it might break others.

@WebReflection Thanks, A-Frame uses neither of those. Good point regarding dependent projects. In general adding new (A-Frame) custom elements will be done through registerPrimitive which is all handled inside A-Frame. So it'd only be a potential problem for projects that use A-Frame and Custom Elements outside of A-Frame (yet depend on the polyfill provided by A-Frame).

It probably suffices to mention it in the release notes, along with instructions on including the polyfill manually for those affected by the change.

Thanks both for the work and the feedback 👏

It probably suffices to mention it in the release notes, along with instructions on including the polyfill manually for those affected by the change.

Absolutely, my comment was rather about the fact I think dropping polyfills should be considered a breaking change or nothing less than a minor release (but as it could break, maybe breaking change is more appropriate, semver speaking).

If you think the risk is minimal though and this library users won't be affected, a note is likely all you need 👍