w3c / badging

Badging API
https://w3c.github.io/badging/
Other
88 stars 12 forks source link

Clarify what to do when some badging mode is not supported #102

Open marcoscaceres opened 1 year ago

marcoscaceres commented 1 year ago

This issue come up in WebKit.

It might be helpful to provide some guidance for what to do when a particular mode is not supported by the OS or user agent.

For example:

It should also provide some guidance as to what happens when, say, number is supported and shown, but "flag" passed.

marcoscaceres commented 1 year ago

In the WebKit issue, it was proposed that perhaps the number "1" could be used as a fallback for "flag" on systems where flag is not supported. However, it was noted that the semantics of "flag" and, say, using the number "1" as a fallback are different enough that that wouldn't make sense (or could be confusing to users).

In the case where either flag or number are not supported, then it might be prudent to throw a NotSupportedError if either is not supported.

Of course, the risk is that authors themselves try/catch for the NotSupportedError and end up using "1" as a fallback, which is not great either.

Thoughts?

fallaciousreasoning commented 1 year ago

Some vaguely related discussions from the explainer: https://github.com/w3c/badging/issues/2

FWIW, adding a NotSupported error would be a breaking change, as currently the API never throws, so I think we should try and avoid that, if we can.

marcoscaceres commented 1 year ago

Sure, thought we might need to take the compat hit as the point of standardization is to make improvements to this early API based on implementation and deployment experience.

At this early stage of standardization (we haven't even published a FPWD yet) we should expect to be making a lot of breaking changes. We should only really expect the API to stabilize once it hits Candidate Recommendation.