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 to resort to "application/octett-stream" and ignore any other metadata as the merry magic header guessing game gets underway. For all you'd have achieved was to muddle any meaning of the mime-type and forced applications to work around an unenforceable restriction. On Thu, Jun 25, 2015 at 3:21 PM, Wez <wez@google.com> wrote: > 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 > support that format safely. > > On Thu, 25 Jun 2015 at 14:16 Florian Bösch <pyalot@gmail.com> wrote: > >> On Thu, Jun 25, 2015 at 3:13 PM, Wez <wez@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 to make it say, >> safe to put OpenEXR into the clipboard (as opposed to letting an app just >> put any bytes there), the UA has to understand OpenEXR. Since I don't see >> how the UA can understand every conceivable format in existence both future >> and past, I don't see how that should work. >> >
Received on Thursday, 25 June 2015 14:28:10 UTC