Thanks Yoav! I pinged the TAG review thread. ________________________________ From: Yoav Weiss <yoavwe...@chromium.org> Sent: Wednesday, October 4, 2023 3:58 AM To: blink-dev <blink-dev@chromium.org> Cc: Anupam Snigdha <sni...@microsoft.com>; Sangwhan Moon <s...@chromium.org>; blin...@chromium.org <blink-dev@chromium.org>; Sanket Joshi (EDGE) <sa...@microsoft.com>; Evan Stade <est...@chromium.org>; jsb...@google.com <jsb...@google.com>; Chris Harrelson <chris...@chromium.org> Subject: Re: [EXTERNAL] Re: [blink-dev] Intent to Implement and Ship: Feature detection for supported clipboard formats
Thanks for working on this! This seems like a welcome addition, and the example code of the current status quo is definitely something we need to solve! On Wednesday, September 20, 2023 at 6:50:40 PM UTC+2 snianu wrote: Thanks Chris for the clarification! Filed TAG review: https://github.com/w3ctag/design-reviews/issues/901 Thanks for filing a TAG review. I think this can benefit from a holistic view of image formats and feature detection. E.g. do we have such feature detection for drawImage()<https://developer.mozilla.org/en-US/docs/Web/API/CanvasRenderingContext2D/drawImage>? HTMLImageElement.decode()<https://developer.mozilla.org/en-US/docs/Web/API/HTMLImageElement/decode>? Are there other APIs that can benefit from a similar pattern? Are there reasons for these APIs to have separate feature detection methods? (i.e. do we expect support to diverge between them) I don't have any answers, but I appreciate you thinking through these questions with the TAG and coming up with some :) Mozilla: https://github.com/mozilla/standards-positions/issues/889 Webkit: https://github.com/WebKit/standards-positions/issues/259 Please let me know if I missed anything. Thanks! -Anupam ________________________________ From: Chris Harrelson <chris...@chromium.org<mailto:chris...@chromium.org>> Sent: Wednesday, September 20, 2023 8:58 AM To: Anupam Snigdha <sni...@microsoft.com<mailto:sni...@microsoft.com>> Cc: Sangwhan Moon <s...@chromium.org<mailto:s...@chromium.org>>; blink-dev@chromium.org<mailto:blink-dev@chromium.org> <blink-dev@chromium.org<mailto:blink-dev@chromium.org>>; Sanket Joshi (EDGE) <sa...@microsoft.com<mailto:sa...@microsoft.com>>; Evan Stade <est...@chromium.org<mailto:est...@chromium.org>>; jsb...@google.com<mailto:jsb...@google.com> <jsb...@google.com<mailto:jsb...@google.com>> Subject: Re: [EXTERNAL] Re: [blink-dev] Intent to Implement and Ship: Feature detection for supported clipboard formats Please do file a TAG review and ask for official vendor signals. It's great that it was approved by the editing WG, but we also need wider TAG review for features, and WebKit and Gecko would like to see signals requests go through their official process. On Tue, Sep 19, 2023 at 9:25 AM 'Anupam Snigdha' via blink-dev <blink-dev@chromium.org<mailto:blink-dev@chromium.org>> wrote: Why is it not applicable? Note that this API is already in the clipboard spec and was approved by the EditingWG members<https://github.com/w3c/clipboard-apis/issues/170#issuecomment-1099368334>. I wasn't sure if we would need TAG to review it after it was approved by representatives from Webkit, Firefox and Chromium so I didn't file a TAG review request. I can certainly do it if it's required. Please let me know. -Anupam ________________________________ From: Sangwhan Moon <s...@chromium.org<mailto:s...@chromium.org>> Sent: Monday, September 18, 2023 11:10 PM To: Anupam Snigdha <sni...@microsoft.com<mailto:sni...@microsoft.com>> Cc: blink-dev@chromium.org<mailto:blink-dev@chromium.org> <blink-dev@chromium.org<mailto:blink-dev@chromium.org>>; Sanket Joshi (EDGE) <sa...@microsoft.com<mailto:sa...@microsoft.com>>; Evan Stade <est...@chromium.org<mailto:est...@chromium.org>>; jsb...@google.com<mailto:jsb...@google.com> <jsb...@google.com<mailto:jsb...@google.com>> Subject: [EXTERNAL] Re: [blink-dev] Intent to Implement and Ship: Feature detection for supported clipboard formats You don't often get email from s...@chromium.org<mailto:s...@chromium.org>. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification> Interesting problem, never thought about this ergonomic problem. On Sep 19, 2023, at 2:12, 'Anupam Snigdha' via blink-dev <blink-dev@chromium.org<mailto:blink-dev@chromium.org>> wrote: Contact emails sni...@microsoft.com<mailto:sni...@microsoft.com>, sa...@microsoft.com<mailto:sa...@microsoft.com>, est...@chromium.org<mailto:est...@chromium.org>, jsb...@chromium.org<mailto:jsb...@chromium.org>, asu...@chromium.org<mailto:asu...@chromium.org> Explainer https://github.com/w3c/clipboard-apis/issues/170 Specification https://w3c.github.io/clipboard-apis/#clipboard-item-interface https://w3c.github.io/clipboard-apis/#dom-clipboarditem-supports 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. Blink component Blink>DataTransfer<https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EDataTransfer> Search tags asyncclipboard<https://chromestatus.com/features#tags:asyncclipboard> TAG review None TAG review status Not applicable Why is it not applicable? WebFeature UseCounter name kAsyncClipboardAPISupportsTypes Risks Interoperability and Compatibility None Gecko: Positive (https://github.com/w3c/clipboard-apis/issues/170#issuecomment-1064240391) WebKit: Positive (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 Other signals: Ergonomics N/A Activation N/A Security N/A WebView application risks Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications? N/A Debuggability Existing devtools support should be sufficient to query the static method from ClipboardItem. Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)? Yes Is this feature fully tested by web-platform-tests<https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>? Yes Flag name on chrome://flags ClipboardSupportedTypes Finch feature name None Non-finch justification None Requires code in //chrome? False Tracking bug https://bugs.chromium.org/p/chromium/issues/detail?id=1483026 Measurement Added usage metrics: AsyncClipboardAPISupportsTypes Adoption expectation Excel online is ready to use this API for adding web custom format support. Adoption plan Support for web custom format is already in inner rings, so once this gets added to the clipboard API, Excel would be ready to use it right away. Sample links https://lake-cobalt-way.glitch.me<https://lake-cobalt-way.glitch.me/> Estimated milestones Shipping on desktop 119 DevTrial on desktop 119 Shipping on Android 119 DevTrial on Android 119 Link to entry on the Chrome Platform Status https://chromestatus.com/feature/5176417696612352 This intent message was generated by Chrome Platform Status<https://chromestatus.com/>. Thanks, Anupam Sent from Outlook<http://aka.ms/weboutlook> -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org<mailto:blink-dev+unsubscr...@chromium.org>. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/BY5PR00MB08403037ADC9DD9A11BB4603CFFBA%40BY5PR00MB0840.namprd00.prod.outlook.com<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/BY5PR00MB08403037ADC9DD9A11BB4603CFFBA%40BY5PR00MB0840.namprd00.prod.outlook.com?utm_medium=email&utm_source=footer>. -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org<mailto:blink-dev+unsubscr...@chromium.org>. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CH2PR00MB0841C834F1E79CD70FF81114CFFAA%40CH2PR00MB0841.namprd00.prod.outlook.com<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CH2PR00MB0841C834F1E79CD70FF81114CFFAA%40CH2PR00MB0841.namprd00.prod.outlook.com?utm_medium=email&utm_source=footer>. -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CH2PR00MB0844BD3377E6A33F9C7D11D1CFCAA%40CH2PR00MB0844.namprd00.prod.outlook.com.
