Sorry Florian, but I don't see what that has to do with whether or not the
Clipboard Events spec mandates that web content can generate their own JPEG
or PNG and place it directly on the local system clipboard.
What is it that you're actually proposing?
On Thu, 25 Jun 2015 at 13:31 Florian Bösch
On Thu, Jun 25, 2015 at 3:13 PM, Wez w...@google.com wrote:
I think there's obvious value in support for arbitrary content-specific
formats, but IMO the spec should at least give guidance on how to present
the capability in a safe way.
Which is exactly the core of my question. If you intend
Or should we just place that into application/octet-stream and hope
whoever listens for the clipboard scans the magic bytes of an OpenEXR?
On Thu, Jun 25, 2015 at 2:56 PM, Florian Bösch pya...@gmail.com wrote:
Well let's say some webapp generates an OpenEXR and wants to put it into
the
And, again, I don't see what that has to do with whether the spec mandates
that user agents let apps place JPEG, PNG or GIF directly on the local
system clipboard. The spec doesn't currently mandate OpenEXR be supported,
so it's currently up to individual user agents to decide whether they can
Which user agents currently allow content to post OpenEXR to the local
clipboard?
On Wed, 24 Jun 2015 at 19:58 Florian Bösch pya...@gmail.com wrote:
No, but the specification doesn't require you to exclude it. So how're
applications going to swap OpenEXR if you only let em stick in jpegs, pngs
No idea. Also doesn't matter jack. There could be some now or in the
future. There's a variety of programs that support HDRi (photoshop,
lightroom, hdri-studio, etc.). It's fairly logical that at some point some
or another variant of HDR format will make its way into clipboards. The
same applies
On Thu, Jun 25, 2015 at 2:58 PM, Florian Bösch pya...@gmail.com wrote:
the magic bytes of an OpenEXR?
Which is 0x762f3101 btw.
On Thu, Jun 25, 2015 at 9:40 AM, Justin Novosad ju...@google.com wrote:
On Thu, Jun 25, 2015 at 5:56 AM, Ashley Gullen ash...@scirra.com wrote:
I see that OffscreenCanvas also specifies a close() method for
ImageBitmap. Perhaps browsers could use copy-on-write with the
toImageData()
Well let's say some webapp generates an OpenEXR and wants to put it into
the clipboard as image/x-exr which would make sense cause any eventual
program that'd support OpenEXR would probably look for that mime type.
You've said you're going to restrict image types to jpeg, png and gif, and
so my
On Thu, Jun 25, 2015 at 5:56 AM, Ashley Gullen ash...@scirra.com wrote:
I see that OffscreenCanvas also specifies a close() method for
ImageBitmap. Perhaps browsers could use copy-on-write with the
toImageData() method? Then you can efficiently either transfer or copy
depending on if you
I don't believe I've said any such thing re jpeg, png and gif... quite the
opposite, in fact.
The point of this thread is that the spec currently *requires* user agents
allow content to supply JPEG, PNG or GIF data directly *to the local
clipboard*, which is risky. We're therefore proposing to
I see that OffscreenCanvas also specifies a close() method for ImageBitmap.
Perhaps browsers could use copy-on-write with the toImageData() method?
Then you can efficiently either transfer or copy depending on if you close
the ImageBitmap you transferred to an ImageData.
Transfer:
On 6/24/15 1:28 PM, Ashley Gullen wrote:
I'm new to specs and WebIDL, my intent was to say those are new methods
on ImageBitmap. Is partial interface ImageBitmap the correct way to
say that?
Yes, it is.
The wording of undue latency in the ImageBitmap spec does not appear
to rule out
On Thu, Jun 25, 2015 at 1:57 PM, Boris Zbarsky bzbar...@mit.edu wrote:
The drawback of adding toBlob/toImageData to the various things ImageData
can be constructed from is that it's a bit more spec complexity, but I don't
see that as a showstopper, necessarily.
We should probably stick to the
Surely you realize that if the specification where to state to only
safely expose data to the clipboard, this can only be interpreted to deny
any formats but those a UA can interprete and deem well-formed. If such a
thing where to be done, that would leave any user of the clipboard no
recourse but
Browsers are very visible applications. Most other applications in
existence tend to work around their foibles in one fashion or another. If
Browsers where to sprout another such foible as to force people to discard
mime-type specification for content because browsers don't let them, it
would give
You've mentioned resorting to application/octet-stream several times in
the context of this discussion, where AFAICT the spec actually only
describes using it as a fall-back for cases of file references on the
clipboard for which the user agent is unable to determine the file type.
So IIUC you're
It's very simple. Applications need to know what's in the clipboard to know
what to do with it. There is also a vast variety of things that could find
itself in the clipboard in terms of formats, both formal and informal. Mime
types are one of these things that applications would use to do that.
Florian, you keep referring to using application/octet-stream - that's not
a format that all user agents support (although the spec says they should
;), nor is there any mention in the spec of what it means to place content
on the clipboard in that format (given that platform native clipboards
No, what I'm saying is that if you restrict mime types (or don't explicitly
prohibit such restriction), but require application/octet-stream, that
application/octet-stream becomes the undesirable mime-type dumping
ground. And that would be bad because that makes it much harder for
applications to
I'm pretty sure it can't be in the interest of this specification to force
application authors to bifurcate the mime-type into one that can't be used
reliably, and another informal one that's prepended to the octet-stream.
Relevant XKCD quote omitted.
On Thu, Jun 25, 2015 at 4:27 PM, Florian
It still sounds like you're advocating removing the requirement that UAs
support application/octet-stream (which makes sense, since its behaviour
doesn't seem to be specified anyway).
If you're suggesting something else, please elaborate on what that
something else is. :)
On Thu, 25 Jun 2015 at
Yet you restrict mime-types AND you support application/octet-stream?
On Thu, Jun 25, 2015 at 7:34 PM, Daniel Cheng dch...@google.com wrote:
For reasons I've already mentioned, this isn't going to happen because
there is no so-called dumping ground.
No one is going to risk their paste
For reasons I've already mentioned, this isn't going to happen because
there is no so-called dumping ground.
No one is going to risk their paste turning into thousands of lines of
gibberish because they tried to stuff binary data in text/plain.
Daniel
On Thu, Jun 25, 2015 at 8:23 AM Florian
No UA supports it today. No UA is likely to support it anytime soon.
Daniel
On Thu, Jun 25, 2015 at 10:38 AM Florian Bösch pya...@gmail.com wrote:
Yet you restrict mime-types AND you support application/octet-stream?
On Thu, Jun 25, 2015 at 7:34 PM, Daniel Cheng dch...@google.com wrote:
I'm sure you're aware that you can encode any binary blob as UTF-8
text/plain. If you don't support application/octet-stream, then that just
becomes the dumping ground.
On Thu, Jun 25, 2015 at 7:39 PM, Daniel Cheng dch...@google.com wrote:
No UA supports it today. No UA is likely to support it
My point is that if you leave no other way out, that is what will happen.
On Thu, Jun 25, 2015 at 7:57 PM, Daniel Cheng dch...@google.com wrote:
That's the case today already, and I haven't seen this happening.
Daniel
On Thu, Jun 25, 2015 at 10:48 AM Florian Bösch pya...@gmail.com wrote:
I think you're missing the point: there is already no other way out, and
that has not happened.
Daniel
On Thu, Jun 25, 2015 at 11:08 AM Florian Bösch pya...@gmail.com wrote:
My point is that if you leave no other way out, that is what will happen.
On Thu, Jun 25, 2015 at 7:57 PM, Daniel
That's the case today already, and I haven't seen this happening.
Daniel
On Thu, Jun 25, 2015 at 10:48 AM Florian Bösch pya...@gmail.com wrote:
I'm sure you're aware that you can encode any binary blob as UTF-8
text/plain. If you don't support application/octet-stream, then that just
becomes
I think you underestimate the integrative need that web-apps will acquire
and the lengths they will go to faced with a business need to make it work
once clipboard API becomes common developer knowledge.
I am thinking about migrating Custom Element bugs[1] to Web Components
GitHub Issues [2], as I did it for Shadow DOM a few weeks ago, for the
consistency.
Could someone turn off the automatic email to public-webapps for Custom
Elements Bugs in the bugzilla so that we won't receive the mass flood
31 matches
Mail list logo
