Re: Filtering clipboard MIME types (was: Re: clipboard events)
On Wed, May 18, 2011 at 17:41, João Eiras wrote:
> On , Paul Libbrecht wrote:
>
>
>> Le 17 mai 2011 à 06:23, Hallvord R. M. Steen a écrit :
>>
>> To get a table started in the spec, could you give me a small list of
>>> (MIME) types one should mandate the UA to be aware of and be able to
>>> "roundtrip" to/from native clipboard types? Just off the top of your head?
>>> The typical Web MIME types would of course be something along the lines of
>>>
>>> text/plain
>>> text/html
>>> image/jpg
>>> image/gif
>>> image/png
>>> application/xhtml+xml
>>> image/svg+xml
>>>
>>
>> I would like to add all of the 3 MathML flavors:
>>
>> - application/mathml-presentation+xml
>> - application/mathml-content+xml
>> - application/mathml+xml
>>
>>
> More generic
> - text/* (I've see in too many places mime-types like text/x-c-src, and
> text is text.)
> - application/*+xml
> - application/*script (ecmascript, javascript)
>
>
e.clipboardData.setData('text/x-c-src', 'Foo');
e.clipboardData.setData('text/plain', 'Bar');
e.clipboardData.setData('text/xml', 'Baz');
e.clipboardData.setData('application/xhtml+xml', 'Blah');
Which one should get placed into the native plain text type? Which one gets
to be the definitive XML on the native clipboard?
Daniel
Re: Filtering clipboard MIME types (was: Re: clipboard events)
On Wed, May 18, 2011 at 5:41 PM, João Eiras wrote: > More generic > - text/* (I've see in too many places mime-types like text/x-c-src, and > text is text.) > - application/*+xml > - application/*script (ecmascript, javascript) > How do we know that these types don't contain invisible sensitive data? - Ryosuke
Re: Filtering clipboard MIME types (was: Re: clipboard events)
On Wed, May 18, 2011 at 8:41 PM, João Eiras wrote: > More generic > - text/* (I've see in too many places mime-types like text/x-c-src, and > text is text.) > - application/*+xml +1 > - application/*script (ecmascript, javascript) Well, unlike the two above, there's no guarantee that all (future) matching media types will be text based scripting languages. Mark.
Re: Filtering clipboard MIME types (was: Re: clipboard events)
On , Paul Libbrecht wrote: Le 17 mai 2011 à 06:23, Hallvord R. M. Steen a écrit : To get a table started in the spec, could you give me a small list of (MIME) types one should mandate the UA to be aware of and be able to "roundtrip" to/from native clipboard types? Just off the top of your head? The typical Web MIME types would of course be something along the lines of text/plain text/html image/jpg image/gif image/png application/xhtml+xml image/svg+xml I would like to add all of the 3 MathML flavors: - application/mathml-presentation+xml - application/mathml-content+xml - application/mathml+xml More generic - text/* (I've see in too many places mime-types like text/x-c-src, and text is text.) - application/*+xml - application/*script (ecmascript, javascript)
Re: Filtering clipboard MIME types (was: Re: clipboard events)
On Tue, 17 May 2011 16:12:50 +0900, Paul Libbrecht wrote: I would like to add all of the 3 MathML flavors: - application/mathml-presentation+xml - application/mathml-content+xml - application/mathml+xml Would any special processing be required for any of them? If not, if we have a section that covers "any XML-based format", that should be enough - right? Relevant for this thread (though not to MathML specifically), here's a link on what Flash supports: http://help.adobe.com/en_US/as3/dev/WS0579B9EE-CF1E-434e-A386-A04DC7786FC9.html -- Hallvord R. M. Steen, Core Tester, Opera Software http://www.opera.com http://my.opera.com/hallvors/
Re: Filtering clipboard MIME types (was: Re: clipboard events)
On Tue, May 17, 2011 at 20:44, Hallvord R. M. Steen wrote: > Do native OS clipboards generally tend to have a data type saying "this is > some random binary data"? That's more or less what I think > application/octet-stream indicates on the web. If there isn't a common > format to map it to on the OS clipboard side, I don't understand what's > being proposed either. (If I had to define "common" I guess I really mean > that the same concept exists in Desktop Win/Mac/*nix clipboard > implementations.) > -- > Hallvord R. M. Steen, Core Tester, Opera Software > http://www.opera.com http://my.opera.com/hallvors/ > If I had to map it to something, it'd represent a native file in a clipboard/drag-and-drop operation. Daniel
Re: Filtering clipboard MIME types (was: Re: clipboard events)
On Wed, 18 May 2011 09:13:19 +0900, Daniel Cheng wrote: I'd suggest that if we want to support image formats in the spec, we should try to support the same set that Canvas::toDataURL() does. I'll have a look at image formats, thanks for pointing me to toDataURL() :) +1 for being able to copy/paste binary data either through application/octet-stream or perhaps using blobs with the BlobBuilder API? I don't understand what problem you're trying to solve with application/octet-stream. Do native OS clipboards generally tend to have a data type saying "this is some random binary data"? That's more or less what I think application/octet-stream indicates on the web. If there isn't a common format to map it to on the OS clipboard side, I don't understand what's being proposed either. (If I had to define "common" I guess I really mean that the same concept exists in Desktop Win/Mac/*nix clipboard implementations.) My bigger concern is that this list of things to support seems to be growing quite rapidly. It'd be nice if we had some sort of criteria to run proposals by, though I have no idea what they'd be. Is it a good idea at this point to let the spec say "these types are mandatory, those are optional"? Or just proceed carefully and try to avoid the feature creep? ;-) -- Hallvord R. M. Steen, Core Tester, Opera Software http://www.opera.com http://my.opera.com/hallvors/
Re: Filtering clipboard MIME types (was: Re: clipboard events)
On Tue, May 17, 2011 at 16:26, Ryan Seddon wrote: > What about image/webp? > I'd suggest that if we want to support image formats in the spec, we should try to support the same set that Canvas::toDataURL() does. > +1 for being able to copy/paste binary data either through > application/octet-stream or perhaps using blobs with the BlobBuilder API? > > -Ryan Seddon > I don't understand what problem you're trying to solve with application/octet-stream. My bigger concern is that this list of things to support seems to be growing quite rapidly. It'd be nice if we had some sort of criteria to run proposals by, though I have no idea what they'd be. Daniel
Re: Filtering clipboard MIME types (was: Re: clipboard events)
On Tue, May 17, 2011 at 2:23 PM, Hallvord R. M. Steen wrote: > text/plain > text/html > image/jpg > image/gif > image/png > application/xhtml+xml > image/svg+xml What about image/webp? +1 for being able to copy/paste binary data either through application/octet-stream or perhaps using blobs with the BlobBuilder API? -Ryan Seddon
Re: Filtering clipboard MIME types (was: Re: clipboard events)
Le 17 mai 2011 à 19:06, Daniel Cheng a écrit : > I would like to add all of the 3 MathML flavors: > > - application/mathml-presentation+xml > - application/mathml-content+xml > - application/mathml+xml > > paul > > I don't think we need all 3. Why not just application/mathml+xml? Daniel, you do mean all three MathML flavors, right? The reason they are each useful is that: some applications can do MathML-presentation and not content (example: MS Word) some applications can do MathML-content and would loose information by receiving presentation (example: Maple, with a limit expression, I think a spreadsheet could also) some applications just do not know or care, for them the generic flavor is ok some applications will do a conversion content-to-presentation in a way better than others, in particular if the language context is properly considered (e.g. considering the varying numbers' syntax) paul
Re: Filtering clipboard MIME types (was: Re: clipboard events)
On Tue, May 17, 2011 at 00:12, Paul Libbrecht wrote: > > Le 17 mai 2011 à 06:23, Hallvord R. M. Steen a écrit : > > > To get a table started in the spec, could you give me a small list of > (MIME) types one should mandate the UA to be aware of and be able to > "roundtrip" to/from native clipboard types? Just off the top of your head? > The typical Web MIME types would of course be something along the lines of > > > > text/plain > > text/html > > image/jpg > > image/gif > > image/png > > application/xhtml+xml > > image/svg+xml > > I would like to add all of the 3 MathML flavors: > > - application/mathml-presentation+xml > - application/mathml-content+xml > - application/mathml+xml > > > What about e.g. RTF? > > I feel it fits. > > paul I don't think we need all 3. Why not just application/mathml+xml? On Tue, May 17, 2011 at 07:03, timeless wrote: > On Tue, May 17, 2011 at 7:23 AM, Hallvord R. M. Steen > wrote: > > to/from native clipboard types? Just off the top of your head? The > typical > > Web MIME types would of course be something along the lines of > > > > text/plain > > text/html > > image/jpg > > image/gif > > image/png > > application/xhtml+xml > > image/svg+xml > > i'd suggest ATOM [application/atom+xml] as a type to support. Browsers > generally support it. This is somewhat to the exclusion of RDF and > RSS. This provides a way to serve listings and enclosures and > things > > Should application/octet-stream be supported for cases when authors > want to pass along binary data? > This really doesn't have corresponding native equivalent other than files. The problem with files is the MIME type doesn't really mean anything when you're transferring data out of the browser, so it's difficult to guarantee round tripping. Also, what about vCard? Daniel
Re: Filtering clipboard MIME types (was: Re: clipboard events)
On Tue, May 17, 2011 at 7:23 AM, Hallvord R. M. Steen wrote: > to/from native clipboard types? Just off the top of your head? The typical > Web MIME types would of course be something along the lines of > > text/plain > text/html > image/jpg > image/gif > image/png > application/xhtml+xml > image/svg+xml i'd suggest ATOM [application/atom+xml] as a type to support. Browsers generally support it. This is somewhat to the exclusion of RDF and RSS. This provides a way to serve listings and enclosures and things Should application/octet-stream be supported for cases when authors want to pass along binary data?
Re: Filtering clipboard MIME types (was: Re: clipboard events)
Le 17 mai 2011 à 06:23, Hallvord R. M. Steen a écrit : > To get a table started in the spec, could you give me a small list of (MIME) > types one should mandate the UA to be aware of and be able to "roundtrip" > to/from native clipboard types? Just off the top of your head? The typical > Web MIME types would of course be something along the lines of > > text/plain > text/html > image/jpg > image/gif > image/png > application/xhtml+xml > image/svg+xml I would like to add all of the 3 MathML flavors: - application/mathml-presentation+xml - application/mathml-content+xml - application/mathml+xml > What about e.g. RTF? I feel it fits. paul
Re: Filtering clipboard MIME types (was: Re: clipboard events)
On Mon, May 16, 2011 at 21:23, Hallvord R. M. Steen wrote: > On Mon, 31 Jan 2011 19:39:13 +0900, Daniel Cheng > wrote: > > I'd go one step further and say that there should be some agreement on >> what >> MIME types ought to be supported to try to insure somewhat consistent >> behavior across different platforms. >> > > To get a table started in the spec, could you give me a small list of > (MIME) types one should mandate the UA to be aware of and be able to > "roundtrip" to/from native clipboard types? Just off the top of your head? > The typical Web MIME types would of course be something along the lines of > > text/plain > text/html > image/jpg > image/gif > image/png > application/xhtml+xml > image/svg+xml > > What about e.g. RTF? > > The way I'm working on implementing it >> (for drag and drop, though it applies to copy and paste as well), >> arbitrary >> strings would not be accessible from a non-DOM application, e.g. a native >> app like Word or Photoshop. Only a set of known MIME types would be >> automatically converted to the corresponding native type. >> > > That's dragging from UA to another app, right? So the way to spec it would > be "during copy/cut processing, the UA should support placing content of > these MIME types on the clipboard and translate the type to the OS native > equivalent where applicable" or something like that? > > When pulling data from the clipboard >>> >> > >> I'm choosing >> to restrict the number of native types to a smaller, defined set that are >> visible to webpages. Any paths in this set can be filtered as necessary >> when a file drag is detected. >> > > Again the specific list of types for this would be great :-) > > -- > Hallvord R. M. Steen, Core Tester, Opera Software > http://www.opera.com http://my.opera.com/hallvors/ > http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-October/028926.htmlis a set of types I proposed originally. I omitted GIF/JPG because platform support for GIFs/JPGs isn't as strong, nor is it widely used. Daniel
Filtering clipboard MIME types (was: Re: clipboard events)
On Mon, 31 Jan 2011 19:39:13 +0900, Daniel Cheng wrote: I'd go one step further and say that there should be some agreement on what MIME types ought to be supported to try to insure somewhat consistent behavior across different platforms. To get a table started in the spec, could you give me a small list of (MIME) types one should mandate the UA to be aware of and be able to "roundtrip" to/from native clipboard types? Just off the top of your head? The typical Web MIME types would of course be something along the lines of text/plain text/html image/jpg image/gif image/png application/xhtml+xml image/svg+xml What about e.g. RTF? The way I'm working on implementing it (for drag and drop, though it applies to copy and paste as well), arbitrary strings would not be accessible from a non-DOM application, e.g. a native app like Word or Photoshop. Only a set of known MIME types would be automatically converted to the corresponding native type. That's dragging from UA to another app, right? So the way to spec it would be "during copy/cut processing, the UA should support placing content of these MIME types on the clipboard and translate the type to the OS native equivalent where applicable" or something like that? When pulling data from the clipboard I'm choosing to restrict the number of native types to a smaller, defined set that are visible to webpages. Any paths in this set can be filtered as necessary when a file drag is detected. Again the specific list of types for this would be great :-) -- Hallvord R. M. Steen, Core Tester, Opera Software http://www.opera.com http://my.opera.com/hallvors/
