Topic: ‘unsanitized’ option to allow developers to opt-out of UA-provided sanitization

[snianu]

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. Safari has expressed that they do not wish to standardize sanitization behavior and also do not want to provide developers the ability to control sanitization behavior.

Firefox only produces unsanitized HTML markup with the DataTransfer API and very recently expressed 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.

[snianu]

RESOLUTION: Document all the behaviors in a way that makes all browsers compliant with the spec. Use non-normative notes for browser specific quirks and options

Minutes: 6:27 PM snianu: sanitization behavior is different in browsers 6:28 PM unsanitized would let authors to opt-out 6:29 PM dandclark: since the behavior varies already so much, seems reasonable 6:30 PM snianu: we've been asked to have unsanitized option 6:31 PM snianu: would like to have something in the spec which would be compatible with all the browsers

edgar: Gecko probably won't implement that, since we want the align with the old API 6:32 PM but with enhanced privacy mode we could sanitize FWIW, WebKit has the same stance as FF — same behavior as DT (which sanitizes in WK), so we won't support this optional property snianu: we'd like to have flexibility in browser implementations 6:35 PM whsieh: we want to align with our legacy API. 6:36 PM whsieh: this sounds reasonable, but we don't need option to let authors to know if sanitization is supported — •dandclark "pleaseUnsanitizeIfYouWant" smaug: It is confusing if the property name hints about unsanitization and that doesn't happen edgar: problem is the inconsistency with the legacy API whsieh: author shouldn't ever expect certain markup 6:43 PM snianu: want to make sure all the behaviors are documented 6:44 PM snianu: we can add non-normative note 6:45 PM johanneswilm: ...so that you cover web authors who are not on mac/safari 6:46 PM smaug: we're ok with this 6:46 PM whsieh: we as well