Re: [w3ctag/design-reviews] Feature detection for supported clipboard formats (Issue #901)

> @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 ](https://github.com/WebKit/standards-positions/issues/259)and [Firefox](https://github.com/mozilla/standards-positions/issues/889) 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](https://github.com/w3c/clipboard-apis/issues/170#issuecomment-1064240391) 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.



-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/901#issuecomment-1910036757
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/901/1910036757@github.com>