Clarify what to do when some badging mode is not supported

[marcoscaceres]

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:

• OS doesn't support "flag"
• OS doesn't support numbers

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

[marcoscaceres]

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]

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]

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.