Should the share method be directly on Navigator?

[plinss]

From the TAG review:

Although this is only a single method, it may be better to add an interface to Navigator containing the share method rather than adding a method directly on Navigator. In the event that other methods or properties are added in the future it would prevent polluting the Navigator namespace and make feature detection easier and more consistent.

[saschanaz]

Something like this looks feasible:

[Exposed=Window, SecureContext]
interface NavigatorShare {
  Promise<undefined> request(optional ShareData data = {});
  boolean supportsBlob(DOMString mimeType); // based on the proposal from Marcos

  // maybe also a share target registration api?
};

partial interface Navigator {
  [SecureContext] NavigatorShare webshare; // needs a new name
};

[marcoscaceres]

Although arguably right about the namespace pollution and making feature detection easier and more consistent, I'd be reluctant to make drastic changes to the API's location at this point. The API surface is small enough that this is not a huge issue.

[plinss]

But is it guaranteed to never get bigger? I already see proposals for more related methods...

[mgiuca]

I agree with @marcoscaceres . The API has been shipped in multiple browsers for several years, and is in widespread use. It is probably a better idea to put the share method into its own namespace, but it is not worth making a breaking change to the API at this late stage. Indeed, there might be more methods added to Navigator, but it's a small amount of pollution.

Contrary to this, when we designed the Badging API, we went in the opposite direction to Web Share, and proposed a Badge namespace. At TPAC 2019, the working group made the decision to put the four methods of Badge directly into the Navigator namespace. I don't really know why that is (and I wasn't there), but it is a precedent.

I'm going to close this because it is not practical to make this change.

[marcoscaceres]

Sent request to TAG to remove label https://lists.w3.org/Archives/Public/www-tag/2022Aug/0000.html