Feature detection for supported clipboard formats

[snianu]

こんにちは 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.

• Explainer¹ : Feature detection for supported clipboard formats w3c/clipboard-apis#170
• Specification URL: https://w3c.github.io/clipboard-apis/#dom-clipboarditem-supports, https://w3c.github.io/clipboard-apis/#clipboard-item-interface
• Tests: [Async Clipboard API] Add supports method to async clipboard API. web-platform-tests/wpt#41993
• User research: N/A
• Security and Privacy self-review²: url
• GitHub repo (if you prefer feedback filed there): https://github.com/w3c/clipboard-apis/issues
• Primary contacts (and their relationship to the specification):
  • Anupam Snigdha (@snianu), Microsoft, Sanket Joshi (@sanketj), Microsoft
• Organization(s)/project(s) driving the specification: EditingWG
• Key pieces of existing multi-stakeholder review or discussion of this specification: Feature detection for supported clipboard formats w3c/clipboard-apis#170
• External status/issue trackers for this specification (publicly visible, e.g. Chrome Status): https://chromestatus.com/feature/5176417696612352

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: 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

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

[snianu]

@cynthia Just checking if TAG got a chance to review this proposal? If there is a similar pattern elsewhere (like supported image formats for drawImage etc) that this API could benefit from, then we could also think about using a similar design pattern in the clipboard API as well. Note that we do have consensus from all major browser vendors & EditingWG for this API.

[LeaVerou]

Security and Privacy self-review²: N/A

Hi, since the clipboard is a pretty privacy sensitive part of the Web Platform, a majority of the TAG feels that any API touching the clipboard needs a Security & Privacy self-review. Would you mind filling that in? Thanks!

[snianu]

@LeaVerou Thank you for reviewing this feature! Added the security/privacy doc here.

[snianu]

I found a similar API canPlayType for media element that informs the user about the supported MIME types. So, it looks like there is some precedent for this kind of design.

[LeaVerou]

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.

[snianu]

@LeaVerou Thank you for reviewing this feature! Apologies for not writing an explainer. Chromestatus entry for this feature has a brief explanation of this proposal and a demo page to show how it would be used by web authors, but an explainer with this info would have been better.

Since we already shipped this API in Blink and I think Safari and Firefox are also planning to implement this API soon, I'm not sure if we can change the API at this point. However, I agree that perhaps adding an overloaded supports method with a dictionary argument would be better for readability. We did Bikeshed the naming few times on the EditingWG group and at the end picked supports as it's a static method in the ClipboardItem that authors use to write formats to the clipboard.

[LeaVerou]

@LeaVerou Thank you for reviewing this feature!

To clarify, while I wrote the comment, reviewing is a collaborative effort.
This reply is also collaborative work, authored in a breakout with @torgo @ylafon @cynthia.

Since we already shipped this API in Blink and I think Safari and Firefox are also planning to implement this API soon, I'm not sure if we can change the API at this point.

Typically if an API has not shipped in other browsers yet, it can absolutely be changed, at least in terms of web compat. Especially if it’s about to ship in other browsers, that makes any changes pretty urgent — soon after it ships across the board, it's too late to make changes. Also, the purpose of design reviews is to get feedback on a variety of aspects, including API design. if you're not in a position to change the API, why is this review open? TAG resources are very limited and time spent on a review is time not spent on another review, so please be considerate of this in the future.

We did Bikeshed the naming few times on the EditingWG group and at the end picked supports as it's a static method in the ClipboardItem that authors use to write formats to the clipboard.

Our concern wasn't that supports() is not a good name (we agree it is!), but that it implies a more general type of feature query so the API should be designed accordinfly.

[snianu]

if you're not in a position to change the API, why is this review open?

Note that this review was opened in September 2023 and we waited couple of months for feedback. Just for my understanding, in the future, should we close the issue if we ship it in one or more browsers? Is there a specific tag that I need to be aware of in the issue that indicates that it is in-review and we should wait for feedback?

I'll consult with other stakeholders to see if we can make a change to add a dictionary argument instead of passing the MIME type as I personally think that it makes it more readable, so thank you for that feedback! FWIW, there was some precedent for passing the MIME type in a method that has similar functionality, so we followed that design pattern.

[snianu]

I have opened an issue in the Clipboard API repo for feedback from the EditingWG. Please post any concerns in that issue so we can discuss with all the stakeholders. Thanks!

[annevk]

I disagree with this feedback.

HTML uses supports() static methods as well and there too we use a simple string for the primary thing we have identified we want support testing for. None of those have really evolved beyond that need and I kinda doubt we'll get there anytime soon (i.e., next 5 years) for those or for clipboard. As such I think keeping it simple now and expanding to a dictionary when there's need is still the right call.

[LeaVerou]

@annevk
No strong opinion here. A string argument and a dictionary overload makes total sense if a) the string argument is the "primary" criteria for testing, and b) its meaning is clear when you see function calls in the wild. If you don't envision any other conceivable criteria for testing in the near or medium term future, that would indicate that MIME type might fall in that category. I have some reservations about (b) for the custom types, but they’re not super strong.

@snianu

Note that this review was opened in September 2023 and we waited couple of months for feedback. Just for my understanding, in the future, should we close the issue if we ship it in one or more browsers? Is there a specific tag that I need to be aware of in the issue that indicates that it is in-review and we should wait for feedback?

There is no such tag because reviews happen quite fast, most of the (unfortunately long) wait time is review requests waiting in the queue. You can however follow the milestones, which indicate when we plan to get to it.
If an API is about to ship, ideally, you should ping us so we could bump it in the queue.
But if an API has shipped and reviewing would not make a difference any more, yes, I would recommend closing it (or ping us, so we can close it with the right label: timed out) so we can reallocate these resources to reviews where reviewing would actually make a difference.

[rhiaro]

Thanks for taking our feedback on board, the rationale for your API design makes sense.