Feature detection for supported clipboard formats

snianu commented 10 months ago

WebKittens

@annevk @whsieh

Title of the spec

WebKit Bugzilla URL

No response

Radar URL

No response

Description

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.

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: https://github.com/w3c/clipboard-apis/issues/170#issuecomment-1064240391 Web developers: Strongly positive (https://github.com/w3c/clipboard-apis/issues/165#issuecomment-1197976360) Multiple Github issues were filed for this feature: https://github.com/w3c/clipboard-apis/issues/165#issuecomment-1197976360 https://github.com/w3c/clipboard-apis/issues/67#issuecomment-650439507 https://github.com/w3c/clipboard-apis/issues/170

marcoscaceres commented 8 months ago

Discussed this internally with colleagues and, unless anyone objects within a week, we are inclined to label this as "support".

annevk commented 7 months ago

It's not clear how this algorithm ends up working for optional data types. I filed https://github.com/w3c/clipboard-apis/issues/200 on that.

WebKit / standards-positions