Feature detection for supported clipboard formats

[snianu]

Request for Mozilla Position on an Emerging Web Specification

• Specification title: Feature detection for supported clipboard formats
• Specification or proposal URL (if available): https://w3c.github.io/clipboard-apis/#clipboard-item-interface, https://w3c.github.io/clipboard-apis/#dom-clipboarditem-supports
• Explainer URL (if available): Feature detection for supported clipboard formats w3c/clipboard-apis#170
• Proposal author(s) (@-mention GitHub accounts): @snianu @sanketj
• Caniuse.com URL (optional):
• Bugzilla URL (optional):
• Mozillians who can provide input (optional): @smaug---- @EdgarChen

Other information

Note that this was discussed in the EditingWG meeting and was approved by representatives from Webkit, FF & Chromium: https://www.w3.org/2022/04/14-editing-minutes.html#r01

Positive signal from Gecko: w3c/clipboard-apis#170 (comment)
Web developers: Strongly positive (w3c/clipboard-apis#165 (comment)) Multiple Github issues were filed for this feature: w3c/clipboard-apis#165 (comment) w3c/clipboard-apis#67 (comment) w3c/clipboard-apis#170

Summary

Currently during async clipboard write operation, there is no way for the web authors to detect if a particular mime type is supported by the UAs or not before attempting to actually write the formats to the clipboard. This not only affects developer ergonomics as now web authors have to attempt to write to the clipboard first in order to find out whether write failed due to a particular mime type not supported by the UAs (or sometimes add version checks that are unreliable at best), but also leads to unnecessary cost in terms of CPU cycles, COGS etc in order to produce an expensive web custom format which may not be supported by a particular browser.

[EdgarChen]

I think it is a reasonable API we should support as currently there is no good way to determine if a specific format is supported by the browser.

[zcorpan]

@EdgarChen does this need an entry on the dashboard?

[EdgarChen]

This is a small and simple API, I think this could be considered as an improvement of async clipboard API, so don't needs an entry on the dashboard.