#901: Feature detection for supported clipboard formats

Visit on Github.

Opened Sep 20, 2023

こんにちは TAG-さん!

I'm requesting a TAG review of Feature detection for supported clipboard formats.

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.

Further details:

  • I have reviewed the TAG's Web Platform Design Principles
  • Relevant time constraints or deadlines: We're planning to ship this in Chrome 119.
  • The group where the work on this specification is currently being done: This API was approved by the EditingWG
  • The group where standardization of this work is intended to be done (if current group is a community group or other incubation venue): EditingWG
  • Major unresolved issues with or opposition to this specification: None
  • This work is being funded by: Microsoft

You should also know that...

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

We'd prefer the TAG provide feedback as (please delete all but the desired option):

☂️ open a single issue in our GitHub repo for the entire review

Discussions

2023-12-18

Minutes

Ready to be worked on.

2024-01-london

Minutes

Lea: feature is legit -- not sure about the naming pattern... some privacy concerns... but you can already detect it it's just the developer exp is bad. They now have a s&p self-review. But LGTM as functionality.

Dan: takes a look at the s&p doc

Lea: the naming is probably fine, consistent with CSS.supports(), even if different than HTMLMediaElement.prototype.canPlayType()

Tess: reading linked issues

Lea: But testing MIME type support is a very specific thing, whereas supports() is a pretty generic name. What if we want other support criteria in the future?

<blockquote>

Hi there,

We looked at this today in a breakout during our London F2F. We overall think the feature is a good addition to the web platform and a low hanging fruit for improving DX.

One concern that came up is that supports() is a rather generic name, but the type of support being tested is very specific. This could hinder both learnability and future extensibility. One way to address that would be to adopt a dictionary argument (e.g. ClipboardItem.supports({type: "image/webp"})). If it later becomes clear that MIME type is the primary criteria that support queries are used for, a string argument could be supported as an overloaded shortcut.

Btw we had a lot of trouble reviewing this feature because the explainer was a GitHub issue, and the only way to see what was actually proposed was to read the spec. It wou;d be helpful for both us and others to have an explainer, even if brief.

</blockquote>
2024-01-london

Minutes

assigned to 2a

2024-02-05

Minutes

Amy: looks like we can close this. Possibly with concerns. Lea thumbsed up this idea in slack. I can draft a closing comment and run it by Lea.

Matthew: +1

closed

2024-02-05

Minutes

we take this to breakout b