I'm sure there is a reason why this can't return a boolean, but the return values here seem suspect at best. Do you actually get any more information out of a 'maybe' response than a 'probably'?
The return values are definitely terrible, but the information I’m inferring is:
- Maybe: the mime type is likely a container, and there are a wide range of possible contained formats… some supported, some not. As in the example, mp4 is such a container.
- Probably: this is either a known format that’s definitely supported (boolean true) or a container format with a narrower range of contained formats, all of which are likely to be supported if any are. Newer or more obscure containers will more likely fall in this category.
I hate to imagine the bikeshedding that must have gone into this API.
> I hate to imagine the bikeshedding that must have gone into this API.
I can't imagine any comprehensively bikeshedded API that wouldn't result in a number being returned here. And it's in the HTML5 spec., which has a reputation for being dictatorially authored by a single individual.
It seems clear that they're trying to communicate confidence level, for which a boolean would be insufficient. But I can't see why it couldn't have been a % value in that case.
I thought it might be that each value is specified to correspond to some specific confidence, but the spec. is extremely and deliberately vague, which makes the whole thing even more useless as that will inevitably just lead to different implementers returning inconsistent values for arbitrary confidences.
