Could you add this detail to the Clipboard spec, since it seems to be needed for programs to be interoperable?
Thanks, Jeffrey On Wed, Jun 12, 2024 at 11:43 AM 'Anupam Snigdha' via blink-dev < [email protected]> wrote: > *Contact emails* > *[email protected] <[email protected]>* > *[email protected] <[email protected]>* > > *Specification* > *https://w3c.github.io/clipboard-apis/#optional-data-types-x > <https://w3c.github.io/clipboard-apis/#optional-data-types-x>* > > *Design docs* > None. See summary. > > *Summary* > On Windows, popular native apps [1] use UTF-8 format to read/write SVG > images from/to clipboard. > > Proposal is to switch to UTF-8 on Windows while writing `image/svg+xml` > format to the clipboard. This is similar to the HTML format where we use > UTF-8 on Windows. When SVG image content is read from the clipboard, > Chromium converts it into UTF-16. > > In M124, support for `image/svg+xml` native format was shipped in async > clipboard APIs. In Chromium, SVG image is written to the clipboard in > UTF-16 format on Windows. Many popular apps [1] on Windows use UTF-8 > encoding to read/write SVG images from/to clipboard. Hence, when a user > tries to copy SVG images from Chromium and paste into one of these native > apps, the image will be parsed incorrectly and will not render after paste. > This can be reproduced by visiting *https://webdbg.com/test/svg/ > <https://webdbg.com/test/svg/>* or *https://heathered-spotty-fin.glitch.me/ > <https://heathered-spotty-fin.glitch.me/>* to copy `image/svg+xml` to the > clipboard and paste it into native Word. > The paste succeeds but the image doesn't render because of the invalid > encoding. > > Proposal is to switch to UTF-8 on Windows while writing `image/svg+xml` > format to the clipboard. This is similar to the HTML format where we use > UTF-8 on Windows too. [2] > > *Alternative considered* > It was attempted to add a BOM character to the UTF-16LE encoded SVG image > content, but the sampled native apps [1] were unable to parse the images > correctly. > > [1] Here is an inventory of all the sampled native apps that read/write > `image/svg+xml` format: > *https://docs.google.com/document/d/1ULlihA0FOJOqcyD9MgzLZrAbk0uTQPJqDPuPJ2aiuS4/edit?usp=sharing > <https://docs.google.com/document/d/1ULlihA0FOJOqcyD9MgzLZrAbk0uTQPJqDPuPJ2aiuS4/edit?usp=sharing>* > [2] > *https://learn.microsoft.com/en-us/windows/win32/dataxchg/html-clipboard-format#:~:text=The%20only%20character%20set%20supported%20by%20the%20clipboard%20is%20Unicode%20(UTF%2D8) > <https://learn.microsoft.com/en-us/windows/win32/dataxchg/html-clipboard-format#:~:text=The%20only%20character%20set%20supported%20by%20the%20clipboard%20is%20Unicode%20(UTF-8)>* > . > > *Blink component* > Blink>DataTransfer > <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EDataTransfer> > > *Search tags* > image/svg+xml <https://chromestatus.com/features#tags:image/svg+xml>, > AsyncClipboard > API <https://chromestatus.com/features#tags:AsyncClipboard%20API> > > *TAG review* > None > > *TAG review status* > Not applicable because it doesn’t change the API surface. > > *Risks* > > > *Interoperability and Compatibility* > If a native app expects the SVG image content to be in UTF-16 format in > the clipboard, then there is risk that paste might break in those apps > after this change. > > However, after testing against 30 *popular native Windows apps > <https://www.microsoft.com/en-us/store/most-popular/apps/pc>* that are > relevant to document editing, we’ve found no apps that relied on UTF-16. > All used UTF-8 encoding scheme to read/write SVG images from/to clipboard. > Therefore we evaluate that there is minimal compatibility risk associated > with this change. > > Currently, the SVG content is converted from UTF-8 to UTF-16 in Chromium > before writing to the clipboard. With this proposal, we are just removing > this conversion, so there is no negative impact to performance. > > > *Gecko*: No Signal. SVG format support is not implemented by Firefox, but > they have *plans to implement it in the future > <https://github.com/mozilla/standards-positions/issues/549>*. > > *WebKit*: No Signal. SVG format support is not implemented by Safari, but > they have *plans to implement it in the future > <https://lists.webkit.org/pipermail/webkit-dev/2021-August/031940.html>*. > > *Web developers*: Positive (https://issues.chromium.org/issues/338250106) > > *Other signals*: > > *Ergonomics* > Not applicable because it doesn’t change the API surface. > > > *Activation* > Not applicable because it doesn’t change the API surface. > > > *Security* > Not applicable because it doesn’t reveal any new information. > > > *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?* > None as this change only impacts Windows. > > > *Debuggability* > N/A as it is about writing UTF-8 encoded SVG image to the system > clipboard. There is already support for debugging async clipboard APIs in > DevTools. > > > Will this feature be supported on all six Blink platforms (Windows, Mac, > Linux, ChromeOS, Android, and Android WebView)? > This change is only on Windows to make it consistent with other native > apps that read/write UTF-8 encoded SVG images from/to the clipboard. > > > *Is this feature fully tested by web-platform-tests > <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?* > No,the behavior change is not testable on WPT tests because it requires an > interaction with a native app. > > > *Flag name on chrome://flags* > UseUtf8EncodingForSvgImage > > *Finch feature name* > UseUtf8EncodingForSvgImage > > *Non-finch justification* > None > > *Requires code in //chrome?* > False > > *Tracking bug* > https://issues.chromium.org/issues/338250106 > > *Estimated milestones* > Shipping on desktop > 127 > > > *Anticipated spec changes* > *Open questions about a feature may be a source of future web compat or > interop issues. Please list open issues (e.g. links to known github issues > in the project for the feature specification) whose resolution may > introduce web compat/interop risk (e.g., changing to naming or structure of > the API in a non-backward-compatible way).* > None > > *Link to entry on the Chrome Platform Status* > https://chromestatus.com/feature/5417299782926336 > > 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 [email protected]. > To view this discussion on the web visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/SJ0PR00MB0991689EFE2EB91B29BDFAE1CFC02%40SJ0PR00MB0991.namprd00.prod.outlook.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/SJ0PR00MB0991689EFE2EB91B29BDFAE1CFC02%40SJ0PR00MB0991.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 [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CANh-dXnotLnAbvb4vGA0XzyL%3DBSQpX2ST_9NnyqBRkTp9DU8dQ%40mail.gmail.com.
