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> wrote:

> On Wed, Feb 11, 2015 at 3:34 PM, James M. Greene <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
>