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.gre...@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" 
<hst...@mozilla.com<mailto:hst...@mozilla.com>> wrote:
On Wed, Feb 11, 2015 at 3:34 PM, James M. Greene 
<james.m.gre...@gmail.com<mailto:james.m.gre...@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

Reply via email to