Don't recommend extensions use vendor prefixing

[mgiuca]

From a discussion on MicrosoftEdge/MSEdgeExplainers#623: it appears that the manifest spec explicitly recommends vendor prefixing in Proprietary manifest members:

Although proprietary extensions are undesirable, they can't realistically be avoided. As such, the RECOMMENDED way to add a new proprietary manifest member as an extension is to use a vendor prefix.

Quoting @bathos on that thread:

Perhaps the proprietary extensions section of the Web Manifest spec should be updated to either remove the recommendation that vendor prefixes be used (it surprised me!) or clarify that this advice is (I’m guessing?) meant to apply only to extensions that are truly platform-specific and not intended to be standardized?

I think this is a good idea. Vendor prefixing in the manifest is a bad idea for the same reason it was bad in CSS properties / JS APIs, and we've largely done away with it in favour of things like Origin Trials, which we have happily run on manifest members (like share_target and tabbed display mode) for years. Let's stop recommending vendor prefixing please.

[aarongustafson]

Works for me. That's how I approached widgets: only the Microsoft-specific member (for an adaptive card template) proposed a vendor prefix.

[mgiuca]

What is widgets?

Looking at the extension registry which the spec encourages implementations to put proprietary extensions in:

• There's one registered extension there which isn't deprecated: gcm_sender_id (the "gcm" is Google Cloud Messaging). I'm not quite sure what this is for (why it belongs in Manifest) but this feels like an appropriate proprietary vendor-prefixed extension. It isn't prefixed with "google" just because it happens to be in Google's browser; it's prefixed with "gcm" because it's talking to a proprietary service called GCM. So it wouldn't be appropriate to standardize this, but it's also not strictly tied to a single user agent. For example, a non-Google browser could implement GCM and make use of this proprietary extension. So I think this is an example of how proprietary extensions should be used. ✔️
• There's a footnote that suggests we could add "edge_web_store", "safari_web_store", etc. I think those are also appropriate proprietary extensions: again, they aren't vendor prefixed, they're links to proprietary related URLs. It wouldn't make sense to generalize this to a standard "web store URL" member, because those URLs differ from one store to another. ✔️

The key distinction between these examples and the one proposed in MicrosoftEdge/MSEdgeExplainers#623 (edge_side_panel) is that the above examples are members that are specifically tied to a proprietary ecosystem (GCM, or specific store websites) - they could theoretically be used by any user agent. Whereas the edge_side_panel is only Edge-prefixed because the Edge team is inventing it and implementing it first. To me, the former is not a "vendor prefix", it's a "proprietary extension", whereas the latter is a "vendor prefix" and should be discouraged.

[mgiuca]

I put up a PR in #1073.

[aarongustafson]

What is widgets?

Experimental feature:
https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/PWAWidgets/README.md

[mgiuca]

@alancutter discovered 3 more proprietary extensions on the Oculus browser (described here). I've added them to the Extensions Registry.

The package name one looks like it fits this use case. The other two (tabbed and scope extensions) have nothing to do with Oculus or VR and are in fact directly competing with our tabbed and scope extensions proposals.

[alancutter]

@alancutter discovered

Credit to @tomayac.