Re: [w3c/clipboard-apis] Arbitrary clipboard types (Issue #165)

> Your "web" keyword indicates that a mime-type is to be read from the platform-specific location named in the [Web Custom Format Map](https://github.com/w3c/editing/blob/gh-pages/docs/clipboard-pickling/explainer.md#on-windows). True?

Yes.

> The absence of the keyword means that it is read from the well-known location (assuming we're dealing with a well-known mime-type like "text/html"). True?

Yes, in particular this should continue to behave as it does today.

> It is assumed that the content returned is always unsanitized whether the "web" keyword is used or not. True?

This proposal does not attempt to change the processing model for non-"web" types. (I suspect we need to allow manipulation of non-"web" as Safari does that today for privacy reasons and other browsers might want to as well. Open a new issue for this perhaps?)

> Say on Windows, if the clipboard contained a Web Custom Format Map entry for "text/html" in "Web Custom Format 1", and the clipboard also contained the "HTML Format", you would expect at least two entries in ClipboardItem.types: "web text/html" and "text/html". True?

Yes.

> Stating the above more generally, ClipboardItem.types lists all the strings that an author can supply to ClipboardItem.getType to access all of the content from the Web Custom Format Map and all of the well-known types present on the clipboard. True?

This is hard to answer as `ClipboardItem.prototype.types` (which I think is what you mean) does not have a definition today.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/clipboard-apis/issues/165#issuecomment-1031465990
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/clipboard-apis/issues/165/1031465990@github.com>

Received on Monday, 7 February 2022 13:24:38 UTC