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
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
>
>
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.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"
mailto:hst...@mozilla.com>> wrote:
On Wed, Feb 11, 2015 at 3:34 PM, James M. Greene
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
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 > 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
>
Re: [clipboard API] platform integration stuff - in spec or out of scope?
On Wed, Feb 11, 2015 at 3:34 PM, James M. Greene
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
Re: [clipboard API] platform integration stuff - in spec or out of scope?
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
Sincerely,
James Greene
On Sat, Jan 31, 2015 at 5:31 PM, Hallvord Reiar Michaelsen Steen <
hst...@mozilla.com> wrote:
>
> I don't know what these "map to" on platforms that do not use MIME types
> to describe clipboard contents. Should this information be dug up and
> included?
>
>
>> First request: can we add the three MathML media-types?
>>
>
> I know you've brought this up before, I haven't done anything about it and
> it's partly because I'm not actually sure myself what an implementation
> would have to do to "support" a data type..
>
>
>> I think I could help dig the names out by looking at the following
>> documents:
>>
>>
> That would be absolutely terrific Paul - maybe make a wiki page or
> etherpad somewhere? It would really help me - coming more from the
> JavaScript side of things I can figure out and describe how all the
> JavaScript stuff works, but it's much harder to determine how the platform
> side needs to be specified.
>
>
>> -
>> http://developer.apple.com/mac/library/documentation/FileManagement/Conceptual/understanding_utis/
>> -
>> https://msdn.microsoft.com/en-us/library/system.windows.dataformats.aspx
>>
>> Also, some specs and media-type-registration RFCs indicate the names in
>> the native formats.
>> I think this would be the right place to hunt too (I know that MathML
>> and SVG do).
>> Probably it'll never be complete (e.g. I do not think
>> application/octet-stream can have a name on clipboards).
>>
>
> So.. If the most important platforms do not have a clipboard format or
> description for a specific MIME type, does that mean telling
> implementations to "support" it is meaningless? Sort of seems like it..
> -Hallvord
>
Re: [clipboard API] platform integration stuff - in spec or out of scope?
I don't know what these "map to" on platforms that do not use MIME types to describe clipboard contents. Should this information be dug up and included? > First request: can we add the three MathML media-types? > I know you've brought this up before, I haven't done anything about it and it's partly because I'm not actually sure myself what an implementation would have to do to "support" a data type.. > I think I could help dig the names out by looking at the following > documents: > > That would be absolutely terrific Paul - maybe make a wiki page or etherpad somewhere? It would really help me - coming more from the JavaScript side of things I can figure out and describe how all the JavaScript stuff works, but it's much harder to determine how the platform side needs to be specified. > - > http://developer.apple.com/mac/library/documentation/FileManagement/Conceptual/understanding_utis/ > - https://msdn.microsoft.com/en-us/library/system.windows.dataformats.aspx > > Also, some specs and media-type-registration RFCs indicate the names in > the native formats. > I think this would be the right place to hunt too (I know that MathML and > SVG do). > Probably it'll never be complete (e.g. I do not think > application/octet-stream can have a name on clipboards). > So.. If the most important platforms do not have a clipboard format or description for a specific MIME type, does that mean telling implementations to "support" it is meaningless? Sort of seems like it.. -Hallvord
Re: [clipboard API] platform integration stuff - in spec or out of scope?
On 31 janv. 2015, at 14:48, Hallvord Reiar Michaelsen Steen wrote: > If yes, do any of the other "mandatory" types have gotchas like Windows "HTML > Format" - on any platform? The mandatory types currently are: > text/plain > text/uri-list > text/csv > text/css > text/html > application/xhtml+xml > image/png > image/jpg, image/jpeg > image/gif > image/svg+xml > application/xml, text/xml > application/javascript > application/json > application/octet-stream > I don't know what these "map to" on platforms that do not use MIME types to > describe clipboard contents. Should this information be dug up and included? First request: can we add the three MathML media-types? (those are: "application/mathml-presentation+xml", "application/mathml-content+xml", "application/mathml+xml") I think I could help dig the names out by looking at the following documents: - http://developer.apple.com/mac/library/documentation/FileManagement/Conceptual/understanding_utis/ - https://msdn.microsoft.com/en-us/library/system.windows.dataformats.aspx Also, some specs and media-type-registration RFCs indicate the names in the native formats. I think this would be the right place to hunt too (I know that MathML and SVG do). Probably it'll never be complete (e.g. I do not think application/octet-stream can have a name on clipboards). Shall I just make the suggestions as a table per (html?) mail? paul
Re: [clipboard API] platform integration stuff - in spec or out of scope?
On Sat, Jan 31, 2015 at 2:48 PM, Hallvord Reiar Michaelsen Steen wrote: > Does the spec need to document such platform implementation details? I think it would be nice if details of various platforms were included. Considering all implementations have to deal with them to some extent. Feels similar to ARIA having to define how it maps to various platforms APIs. Knowing what to write to the clipboard and how to handle any input from the clipboard is sort of basic interoperability-wise. The main nuisance is that the clipboard sits above the browser in the stack and is different per platform. -- https://annevankesteren.nl/
