- From: Hallvord R. M. Steen <hallvord@opera.com>
- Date: Wed, 18 May 2011 12:44:34 +0900
- To: "Ryan Seddon" <seddon.ryan@gmail.com>, "Daniel Cheng" <dcheng@chromium.org>
- Cc: public-webapps@w3.org
On Wed, 18 May 2011 09:13:19 +0900, Daniel Cheng <dcheng@chromium.org> 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/
Received on Wednesday, 18 May 2011 03:45:12 UTC