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

Any follow-up on this?

Sincerely,
    James Greene


On Fri, Feb 13, 2015 at 1:46 PM, Ben Peters <Ben.Peters@microsoft.com>
wrote:

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