- From: Sanket Joshi <notifications@github.com>
- Date: Tue, 21 Mar 2023 15:13:11 -0700
- To: w3c/editing <editing@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/editing/pull/420/review/1351451305@github.com>
@sanketj commented on this pull request. > @@ -0,0 +1,257 @@ +# Unsanitized HTML for Async Clipboard API + + +## Author: +* ansollan@microsoft.com +* snianu@microsoft.com + +## Introduction +Using DataTransfer object’s setData and async clipboard write method, we are seeing interop differences in how the HTML content is sanitized and written to the clipboard. In Chromium async clipboard write method clears the clipboard content first and then writes the payload which results in overwriting the previous HTML content that was inserted by authors using DataTransfer object’s setData API. It’d be beneficial for the web authors if async clipboard and setData APIs provide the same HTML content during copy operation so round tripping is possible without any interop differences. Should avoid usage for first person (ie. "we") in spec documents. > @@ -0,0 +1,257 @@ +# Unsanitized HTML for Async Clipboard API + + +## Author: +* ansollan@microsoft.com +* snianu@microsoft.com + +## Introduction +Using DataTransfer object’s setData and async clipboard write method, we are seeing interop differences in how the HTML content is sanitized and written to the clipboard. In Chromium async clipboard write method clears the clipboard content first and then writes the payload which results in overwriting the previous HTML content that was inserted by authors using DataTransfer object’s setData API. It’d be beneficial for the web authors if async clipboard and setData APIs provide the same HTML content during copy operation so round tripping is possible without any interop differences. Not sure it makes sense to specifically talk about the Chromium implementation of the async clipboard write API. We can talk about how the behavior is spec'ed or how the behavior differs between browsers, or it might even be fine to exclude that part. I think the introduction can be insightful enough without the implementation details. > +async () => { +try { + const html_text = new Blob([ + '<html><head><meta http-equiv=Content-Type content=\"text/html; charset=utf-8\"><meta name=ProgId content=Excel.Sheet><meta name=Generator content=\"Microsoft Excel 15\"><style>display:none</style></head></html>'], {type: 'text/html'}); +navigator.clipboard.write([ + new ClipboardItem({ + "text/html": html_text + }), +]); +} catch(e) { +} +} + +``` + +## Proposal We should change this to look more like a spec, ex. https://w3c.github.io/clipboard-apis/#async-clipboard-api. Proposal is fine for an explainer, but given that we can use this document as an effective spec to understand the Chromium behavior, we should structure it like a specification. -- Reply to this email directly or view it on GitHub: https://github.com/w3c/editing/pull/420#pullrequestreview-1351451305 You are receiving this because you are subscribed to this thread. Message ID: <w3c/editing/pull/420/review/1351451305@github.com>
Received on Tuesday, 21 March 2023 22:13:24 UTC