Any follow-up on this?
Sincerely,
James Greene
On Fri, Feb 13, 2015 at 1:46 PM, Ben Peters ben.pet...@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.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 wrote:
On Wed, Feb 11, 2015 at 3:34 PM, James M. Greene
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
