Need to adjust IDL to make overload definitions distinguishable? about autoplay HOT 2 CLOSED

The deeper issue here is there's no way to distinguish these two types, so such an overload---or union---is meaningless. JavaScript functions passed to your method don't signal their return value in some way spec code can distinguish. You can't know what a JavaScript function will return, until you call it!

Probably instead you want the callback to return object, and then you can do tests in prose accounting for the three cases of interest: the result of calling the callback implements HTMLMediaElement, the result implements AudioContext, or neither of those things are true.

from autoplay.

Hmm, that means that browsers would need to call the constructor themselves to check the return type. That does not sound like very good design (arbitrary constructors may have side effects).

For context, the current design originates from #15 (comment)

@alastor0325, this may suggest that the spec needs to consider a different approach. Perhaps with an enum? Something like:

enum AutoplayPolicyMediaType { "audio", "video", "media" };

[Exposed=Window]
partial interface Navigator {
  AutoplayPolicy getAutoplayPolicy(AutoplayPolicyMediaType type);
};

from autoplay.