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.

[captainbrosset]

Is changing caniuse really required here?

From caniuse's point of view, the feature is partially implemented because resizeQuality isn't implemented in Firefox (bug), but that doesn't mean the feature can't be used.

What if we didn't change caniuse but pinned our feature in a way that makes it widely available?

For what it's worth, that's what MDN is doing:

That's the first time I'm seeing the little asterisk symbol and note about the partial support by the way. I'm guessing this is an override on their end.

Personally, the only thing I'd do here is use compute_from to make the feature be widely available (and leave the resizeQuality parameter in the feature).

[ddbeck]

Is changing caniuse really required here?

Yes. Our documented guidelines for setting caniuse values says:

For example, if Can I Use shows that one browser of the core browser set does not support a feature but web-features's status reports that the feature is supported across all of the browsers, then do one of these:

• Do not set the caniuse value for that feature.
• Submit a correction to Can I Use.
• Submit a correction to mdn/browser-compat-data.

As of #3165, we've broken from caniuse. I've sent #3172 to bring us back into alignment with our own guidelines.

As for MDN, they are not overriding us. MDN shows the per-key status for the key defined in that page's frontmatter (in this case, api.createImageBitmap. They show the asterisk when the compat table on that page shows data for compat keys that have a different status then the shown in the banner. They're not currently using our high-level feature groups.

[ddbeck]

I've sent Fyrd/caniuse#7348 and #3173, to sync up the two features without resizeQuality. This would partially undo some of the changes in #3165 (cc: @foolip).

[ddbeck]

One last question here for @jgraham: if createImageBitmap() is Baseline, do you still wish to see a standalone feature for resizeQuality?

For my part, I think although it might be interesting to have a feature (e.g., for associating with WPT or getting developer signals), in most cases I'd probably not make a standalone feature for this compat key, leaving it as a "later addition" on the createimagebitmap feature.