- From: CSS Meeting Bot <notifications@github.com>
- Date: Fri, 14 Jan 2022 09:49:06 -0800
- To: w3c/clipboard-apis <clipboard-apis@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/clipboard-apis/pull/162/c1013331141@github.com>
The Web Editing Working Group just discussed `Add Custom Clipboard format`.
<details><summary>The full IRC log of that discussion</summary>
<Travis> Topic: Add Custom Clipboard format<br>
<Travis> github: https://github.com/w3c/clipboard-apis/pull/162<br>
<Travis> BoCupp: Context: Folks weren't interested in unsanitized option (that would require a sanitization library).<br>
<Travis> .. Chromium-based browsers still wanted to move forward... one proposal was that a "browser may do X or Y". To specify whether they want unsanitized content or not.<br>
<Travis> .. another options was not to add anything to the spec; but to fork the spec into another CG or separate doc. (The latter was what we did.)<br>
<Travis> .. If we look at Anupam's PR, we see it will be a big maintenance headache ;(<br>
<Travis> .. Therefore, I would like us to reconsider.<br>
<Travis> .. I believe AnneVK chimed in showing their interest in this feature?<br>
<Travis> .. Finally, why would we not add language in the primary spec? Might create pressure on Apple ("not spec compliant").<br>
<Travis> .. I think we'd still have web.dev posts (and other blog posts when it launches).<br>
<Travis> .. So... the absense of this (in the spec) may not justify not adding it to the spec.<br>
<Travis> .. So, will listen to others' reactions?<br>
<Travis> Anne: I'm not sure about unsantizied either.<br>
<Travis> .. mainly was expressing support for custom formats (in the spec).<br>
<Travis> .. I think that is something worth having in the spec (incl. Apple)<br>
<Travis> .. Want to preserve that we would have a specification for custom formats.<br>
<Travis> .. Separately, we need to consider the unsanitized option. I'm *less* favorable on that one.<br>
<Travis> .. It's weird that the legacy API and new API do different things...I think we should try to unify them.<br>
<Travis> BoCupp: For custom formats, I think we agree that there isn't a sanitization algorithm that we'd apply to custom formats (unknown structure)<br>
<Travis> .. Wanted to be sure that together with unsanitized keyword, that the format would be listed.<br>
<Travis> .. Do you think it's useful in that context?<br>
<Travis> Anne: Interesting. I might be ammenable to that.<br>
<Travis> BoCupp: To be fair, we doubled-up the purpose here... we wanted to provide this to the HTML format.<br>
<whsieh_> sorry, not sure why my mic isn't working :( what I recall agreeing on last was that sanitization should be a feature of the browser, not something that sites should be able to opt out of. so blink would always unsanitize, and WebKit can continue sanitizing<br>
<Travis> .. (details for legacy API vs new API)<br>
<Travis> .. Don't really want to touch the legacy API behavior.<br>
<Travis> BoCupp: Yes, that matches what I recall.<br>
<whsieh_> I think there are ways to ensure backwards compatibility even without the sanitize option<br>
<Travis> .. I think that's Apple's position.<br>
<Travis> .. I think Chromium's position is different... want to focus on the mechanics (assuming we won't come to an agreement).<br>
<Travis> .. And what's the most appropriate way to document it.<br>
<whsieh_> right, but this is about whether or not we should build the concept of 'sanitize' into the spec right?<br>
<whsieh_> (the sanitize option, that is)<br>
<Travis> snianu: Domenic's last comment on my PR was that we don't have to define all the details, but add ref to the sanitizer API (and how its configured).<br>
<Travis> .. per Domenic, we should just call algorithms that have undefined (up to the UA) behavior.<br>
<Travis> .. We should be sure it's specified and deterministic.<br>
<Travis> .. This is now blocking the PR.<br>
<Travis> Anne: Historically, I would see failure of standardization process if we can't get agreement.<br>
<Travis> .. We don't have many API in this sort of deadlock...<br>
<Travis> BoCupp: Why I think it may be OK in this circumstance.<br>
<Travis> .. The clipboard shape is unknown--someone could have written santizied content to the clipboard originally--how would one know?<br>
<Travis> .. Today, you can get a loss of fidelity when clipboard transfer occurs.<br>
<whsieh> we're okay with offering platform API to support unsanitized transport of information from native apps to the web<br>
<Travis> .. I think it's OK if a UA wants to be more cautious (or not) in sanitizing at their discretion.<br>
<Travis> .. So that web devs don't have to write unique code.<br>
<BoCupp> q?<br>
<Travis> johanneswilm: Devs do have to write different code if they get sanitized from one browser and unsanitized from another.<br>
<Travis> .. might have provide an upload mechanism to help understand the data.<br>
<Travis> .. (as an alternative)<br>
<Travis> snianu: Most websites that parse HTML string.. they use getData/setData.<br>
<Travis> .. in Firefox and all Chromium browser we get unsanitized content.<br>
<whsieh> we only sanitize cross-origin<br>
<Travis> .. this is not so for Safari (not sure if there's special code paths for Safari)<br>
<Travis> Anne: Why even have a sanitize (if most are not sanitizing today)?<br>
<Travis> snianu: I believe whsieh mentioned they only wanted to provide unsanitized content between same origin...<br>
<whsieh> right. the only reason is compat<br>
<Travis> Anne: I don't think we need the sanitized option then... if this is already something that is there? Why provide it? Wondering if there's a compat thing?<br>
<whsieh> (but there are ways to fix compatibility issues without baking it into the spec)<br>
<Travis> BoCupp: If you Ctrl+V and don't prevent the default, the browser needs it's own santiized logic (style adjustment, JS stripping, etc.) prep logic for "merge ready" HTML.<br>
<Travis> .. There's a way for authors to do this too.<br>
<whsieh> would it be useful to provide API to sanitize markup in the style of the clipboard?<br>
<Travis> .. It would be more ergonomic to allow authors to leverage this "merge-ready" logic... thought having an option to choose would be good (for well-known formats).<br>
<Travis> johanneswilm: On "is it a failure of the standardization process" is there another way we can move forward?<br>
<BoCupp> q?<br>
<Travis> .. On Bo's last comment: this can be problematic for editor creators--if they rely on the browser sanitization, it can lead to incompatible paste content in their editor--so they have to sanitize anyway.<br>
<Travis> BoCupp: For moving forward, I'd like to see language that is a delta to the existing spec (rather than an entire clone of the spec).<br>
<Travis> .. (assuming can't get to an agreement)<br>
<Travis> .. but would like to have something like this (either or option) in the spec.<br>
<snianu> https://github.com/w3c/editing/pull/383<br>
<Travis> 👆 the forked PR<br>
<Travis> snianu: The presentation style attribute is not supported in Chrome/Firefox. Also multiple clipboard formats are only supported on Apple platforms. So there is some precident already that is Safari-specific.<br>
<Travis> .. (can this be another instance of that?)<br>
<Travis> Anne: Specific to Safari for Apple platforms!<br>
<Travis> whsieh: but does it need to be in the spec?<br>
<Travis> Anne: only argument that's persuasive to me is Ctrl+V, and I'm not sure its that specific...<br>
<Travis> BoCupp: Hmm, there are some potentially risky unsanitized content on the pickled formats.<br>
<Travis> Anne: potentially different accessor for pickled formats versus built-in formats?<br>
<Travis> .. Wouldn't say "unsanitized"... might have "unsafe" prefix or something similar. (Have used 'unsafe' in other APIs in the past.<br>
<Travis> .. Could work for HTML and/or image formats?<br>
<Travis> BoCupp: If we look at separate accessors... it's possible that an unknown format (today) could become a built-in format (future). Would it migrate?<br>
<Travis> .. (thinking on the lfy here...)<br>
<Travis> Anne: Could access some format through a pickled format and also not (through separate APIs)<br>
<Travis> .. In that case security is up to website/native apps.<br>
<Travis> whsieh: If the website writes pickled formats... we wouldn't want to expose that raw content to native app (they' need an opt-in)<br>
<Travis> Anne: The native app would need to opt-in also, correct?<br>
<Travis> .. native app can get to normal html/png directly, but if you wrote pickled html/png, they wouldn't get it.<br>
<Travis> whsieh: and if they asked for regular html they'd get the sanitized version...<br>
<Travis> .. could lead to issues if the website authors use pickled versions for the clipboard.<br>
<Travis> .. today the browser writes a safe AND unsafe version to the clipboard...<br>
<Travis> .. so that Apps can decide which to use. (If they don't opt-in they get sanitized version.)<br>
<Travis> .. Important point: we should push websites to write both versions (or ensure the browser has a way to do that).<br>
<Travis> BoCupp: Taking a moment to point out our implementation status...<br>
<Travis> .. Don't think we'll get agreement on how all our implementations will align.<br>
<Travis> .. Happy to change chromium implementation if we can get agreement.<br>
<Travis> .. But assuming (based on history) that we won't.<br>
<Travis> .. In Edge, we have shipped something to allow native apps to exchange content...<br>
<Travis> .. In the chromium process, the hold-up is where we are going to write the behavior down.<br>
<Travis> .. There are many options here. Looking for what the right approach is that minimized disruption/impact on the WG?<br>
<Travis> Anne: felt like we were pretty close to an agreement!<br>
<Travis> whsieh: We agree that the behaviors can be different.<br>
<Travis> .. We don't agree that writing the unsanitized option into the spec is OK.<br>
<Travis> .. last time, we talked about ways of configuring this (that are different from the unsanitized flag)<br>
<Travis> .. mentioned a <meta> tag for this purpose...<br>
<Travis> .. could solve the compat issue.<br>
<Travis> BoCupp: Wouldn't be my preference...<br>
<Travis> johanneswilm: Wondering if we could move this out... or have another meeting?<br>
<Travis> .. moving to the time-zones meeting?<br>
<Travis> BoCupp: To conclude... I'll try to setup a meeting over email. By default, Anne, whsieh, me... smaug, johanneswilm....<br>
<Travis> .. +megan<br>
<Travis> .. I will follow-up on the public-editing-tf list.<br>
</details>
--
Reply to this email directly or view it on GitHub:
https://github.com/w3c/clipboard-apis/pull/162#issuecomment-1013331141
You are receiving this because you are subscribed to this thread.
Message ID: <w3c/clipboard-apis/pull/162/c1013331141@github.com>
Received on Friday, 14 January 2022 17:49:20 UTC