Split createImageBitmap feature

[jgraham]

This feature would have baseline status, except it depends on api.createImageBitmap.options_resizeQuality_parameter which clearly isn't a blocker to most uses of the feature. This should be split out into a separate feature.

[jgraham]

#3140

[ddbeck]

@jgraham do you have some evidence that shows that developers don't care if resizeQuality works (or don't expect it to), as part of createimagebitmap?

We modeled our feature after caniuse's feature, which does mark implementations without resizeQuality as partial. I had to go to some lengths to reconcile caniuse, BCD, and web-features in the first place.

If we were to change this, then I'd like to request a change in caniuse as well, but there would need to be some sort of justification. (I don't think we should break the link with the caniuse feature, in any case.)

[jgraham]

This seems like a pretty straightforward case where different implementations have shipped different parts of a feature at different times, so we need to split in order to accurately reflect what's available to web developers. I think it's been widely discussed that this kind of partial implementation is likely to be common, and that we should split when it happens.

In terms of caniuse, it seems like if they don't want to split the feature on their side they need a way to make composite features from more than one web-platform-feature and mark the implementation as partial if not all the component features are supported. Again, I expect this to be a very common case when we start handling new features, so we need a way to make this work.

In terms of the value of resizeQuality if you look at the specification the meaning of the parameter is basically entirely implementation defined, and not having it doesn't usually[*] break anything but changes some of the details of the output. I can't see any Firefox compatibility bugs in bugzilla that have been attributed to the lack of resizeQuality. On the other hand not supporting createImageBitmap at all would clearly break sites that depend on that feature.

[*] Of course some site might try to readback the image data and expect a specific output depending on the algorithm, but that would always be an interop risk given that implementations are free to change the behaviour at any time.