RE: [clipboard API] platform integration stuff - in spec or out of scope?

I agree with James. The reason to have it in the list is to have a normalized name for it (instead of worrying about platform specific clipboard types). As long as the browser isn’t required to handle it or prevented from handling it, it can included to make it both readable and writable by script. I haven’t seen vender pushback, but I haven’t been involved for as long as some.

From: James M. Greene [mailto:james.m.greene@gmail.com]
Sent: Wednesday, February 11, 2015 6:59 PM
To: Hallvord Steen
Cc: public-webapps; Paul Libbrecht
Subject: Re: [clipboard API] platform integration stuff - in spec or out of scope?


Allow me to clarify my position.

My expectation is NOT for the browsers' default action on "copy"/"cut" to convert HTML into RTF. I do not see any such implication of that behavior in the spec language [1].

Rather, I just want to ensure that browsers will honor/maintain that clipboard format/segment if it is set during a custom "copy" event handler using the `event.clipboardData.setData` method. The current language of the spec [2] leaves the possibility open for an implementor to choose to ignore/discard any data formats that are not on the mandatory data types list [1], and I find that worrysome.

Is the problem that spec may be implying that the browser must know what to do with the data when PASTING from a clipboard segment associated with a mandatory data type? I could see that as more of a sticking point for implementors... but again, I really just want to ensure that the "application/rtf" clipboard segment is simply left intact bi-directionally. If the spec were to be updated to generally ensure that type of maintained/untouched transfer for data types that are NOT on the mandatory data types list (i.e. "custom data types"), then I would be fine leaving "application/rtf" OFF the mandatory data types list.

Can we get some clarification on the vendor pushback reasoning in this regard?

Thanks!

[1]: http://dev.w3.org/2006/webapi/clipops/clipops.html#mandatory-data-types

[2]: http://dev.w3.org/2006/webapi/clipops/clipops.html#writing-contents-to-the-clipboard


Sincerely,
   James M. Greene
On Feb 11, 2015 3:15 PM, "Hallvord Reiar Michaelsen Steen" <hsteen@mozilla.com<mailto:hsteen@mozilla.com>> wrote:
On Wed, Feb 11, 2015 at 3:34 PM, James M. Greene <james.m.greene@gmail.com<mailto:james.m.greene@gmail.com>> wrote:
We never really came to a decision on if RTF ("application/rtf") should be listed as a mandatory MIME type but the general consensus seemed to be leaning toward "yes":
   https://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0197.html


There was some pushback from vendors - and I think their arguments were reasonable. Why should a web browser have to include code to generate RTF documents to write them to the clipboard? It's going to be a non-trivial amount of code, it will be rarely executed and could easily come with exploitable security vulnerabilities. It only makes sense to require this if there is a significant amount of software out there that supports pasting RTF data but does *NOT* support pasting HTML data - so that if we mandate support for writing HTML to the clipboard but leave RTF out, many users will have problems pasting text with formatting into another application. How many applications would have this issue on the various platforms? How widely are they used? Would users even expect to be able to preserve formatting on pasting into or copying from these applications?

A reply from you in the earlier discussion of these questions is here:
https://lists.w3.org/Archives/Public/public-webapps/2014JulSep/0325.html


-Hallvord, wearing an invisible clipboard spec editor hat