Prior Art:
In Flash, you could query which formats were available via a read-only array called `formats` on the clipboard object (equivalent of `clipboardData`):
    http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/desktop/Clipboard.html#formats

However, you already said that we should avoid putting it on `clipboardData`, to which I would agree.

The one caveat to keep in mind is that, even if some MIME type is not reported as being support by the clipboard object, it should still be possible to write that unsupported type to the clipboard in its own segment. This allows for consumption of custom data by other applications -- both web-based and not, e.g. copying a quote into the Skype clipboard style:
    https://code.google.com/p/skype-quote-generator/

Would it be weird to define window.ClipboardEvent.formats ? It would be an array listing the MIME types the implementation knows how to write to and read from the clipboard, for example:

window.ClipboardEvent.formats = ['text/plain', 'text/html', 'image/jpeg']

Though this raises fingerprinting concerns. Actually, maybe this should be pushed to HTML and defined as part of the DataTransfer stuff: http://www.whatwg.org/specs/web-apps/current-work/multipage/dnd.html#the-datatransfer-interface - implies it will only be available during event handling, but for general web usage that may be the best we can get..

I would agree that it could be valuable to have it available for the DND interfaces, too. My concern would be strictly from the API side, though: it may become quickly confusing to have both a `types` (http://www.whatwg.org/specs/web-apps/current-work/multipage/dnd.html#dom-datatransfer-types) and `formats` property on the object.

I don't think this should block V1

See also related discussion here: https://github.com/w3c/clipboard-apis/issues/9