[w3c/clipboard-apis] Topic: ‘unsanitized’ option to allow developers to opt-out of UA-provided sanitization (Issue #206)

All three browsers have separate sanitization behaviors for the async clipboard API.

Safari generates both sanitized and unsanitized markup, returning unsanitized markup for same-domain copy-pastes and a sanitized version for cross-domain [Link](https://github.com/w3c/clipboard-apis/issues/150#issuecomment-885931960). Safari has expressed that they [do not wish to standardize sanitization behavior](https://github.com/w3c/clipboard-apis/issues/150#issuecomment-974594001) and also [do not want to provide developers the ability to control sanitization behavior](https://github.com/w3c/editing/issues/334#issuecomment-918621385).

Firefox only produces unsanitized HTML markup with the DataTransfer API and [very recently expressed](https://github.com/mozilla/standards-positions/issues/769#issuecomment-1852250385) that they intend to do the same for the async clipboard API. Given that they will always produce unsanitized HTML, such a developer control doesn’t make sense for Firefox.

Chromium performs sanitization of HTML markup by default for the async clipboard API, but provides authors with an option to opt-out of sanitization (ie. the `unsanitized` option).

Chromium’s behavior requires an API change that other browsers are unlikely to need given differences in behaviors. Is there a way that Chromium’s behavior can be reflected in the spec, while still allowing all browsers to be spec-compliant? Our proposal is to add an optional dictionary to `navigator.clipboard.read()` that allows the `unsanitized` value to be set but have the spec mention that UAs might (not must) support this dictionary.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/clipboard-apis/issues/206
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/clipboard-apis/issues/206@github.com>