Add supports API for async clipboard.

[snianu]

Closes #170

For normative changes, the following tasks have been completed:

• Modified Web platform tests (link to pull request)

Implementation commitment:

• WebKit (https://bugs.webkit.org/show_bug.cgi?id=)
• Chromium (https://bugs.chromium.org/p/chromium/issues/detail?id=1483026)
• Gecko (https://bugzilla.mozilla.org/show_bug.cgi?id=)

---

Preview | Diff

[evanstade]

@garykac could you ptal?

[sanketj]

In addition to the mandatory data types, should this API also return true for correctly-prefixed custom formats?

[snianu]

@sanketj Yes, I'm planning to add that in PR #175

[snianu]

@evanstade @garykac Note that this feature (including the API shape) was approved by EditingWG already.

[evanstade]

I think the exact wording and behavior here still warrant discussion even though the EditingWG approved the general idea of it (?) 1.5 years ago.

Specifically, which of the following should return true if web custom formats are supported, and why?

ClipboardItem.supports('web');  // 1
ClipboardItem.supports('web ');  // 2
ClipboardItem.supports('web image/jpeg');  // 3
ClipboardItem.supports('web text/plain');  // 4
ClipboardItem.supports('web txt/plain');  // 5
ClipboardItem.supports('web application/foobar');  // 6

1. (and 2) These are not valid types per se, just a part of a type. But if a site just wants to know if web custom formats are supported, then one of these is probably sufficient. That is, the browser only needs to return true for the exact string web or web .
2. see above
3. see above
4. Is there a point in supporting this? Is it equivalent to text/plain alone, or not?
5. This is not a real MIME type. Should it be "supported"?
6. This is a real MIME type.

[snianu]

@evanstade Per the web custom format proposal, web custom formats are arbitrary types that are denoted by the prefix "web " ("web" followed by U+0020 SPACE) to distinguish them from built-in types, so we only need to check for the web prefix. The custom MIME type is specified by the web author at the time of ClipboardItem object creation which is when we validate the type/subtype format. See step 5 in the constructor where this validation is done.
So, in your example we will return true for all cases except 1.

[evanstade]

In the original request for supports, the exact opposite is suggested: #165 (comment)

And I think that makes more sense. What is the purpose of any of the text after "web"? It has no bearing on the returned value.

[snianu]

I didn't notice that the proposal doesn't have a space after web prefix. It's essential as it differentiates between web custom formats and other valid MIME type formats that browsers may not have support for in the async clipboard write method. e.g. web text/html is supported but webtext/html is not.

[evanstade]

I don't think that webtext/html is actually a valid MIME type (apparently now renamed "media types"). There are only 8 valid content types (that is, the part before the slash).

Either way, the proposal is for an exact string match on web.

[snianu]

I was referring to this definition of MIME type which is what we use in the clipboard spec. webtext/html passes the parsing check of the MIME types, so from a clipboard perspective, it's a valid MIME type. It's just that we don't have support for it in the clipboard.

IMO removing the space from the web prefix would create confusion among web authors, and since it's part of how we parse the web custom format during the construction of the ClipboardItem, our preference is to match with the web prefix ("web" followed by U+0020 SPACE).

Anyways, I don't have a strong opinion on this so I'm adding Agenda+ label to discuss with the EditingWG members.

[snianu]

Note that currently web authors already use startsWith and web to check if there is any web custom format after read operation: https://developer.chrome.com/blog/web-custom-formats-for-the-async-clipboard-api/#reading-web-custom-formats-from-the-clipboard.
So, the current proposal of checking for web aligns with this approach as well.

[evanstade]

If you are given a string and you have to figure out whether it represents a web custom type, then sure, use startsWith and web . But what we are discussing is: what is the best argument to represent the concept of "web custom formats in general"? We're talking about a string only because the argument is also used to reference specific built-in types, for which a string is obviously the most appropriate type. But the concept of "web custom formats", relative to, say, "built in formats", is best represented by an enum. A hard-coded string is sort of conceptually the same thing as an enum.

I'd be interested in hearing opinions from folks with long-term spec-writing experience such as @inexorabletash

[inexorabletash]

I don't have strong feelings here, but my intuition for how developers would try to use supports() for custom types in practice is either:

• ClipboardItem.supports('web valid/type'); // where we'd return true for 'web' + space prefix and valid mime type suffix suffix
• ClipboardItem.supports('web'); // true

The former aligns with the concept of supports() being a way of testing what the ClipboardItem constructor would do without wasting time, but accepting 'web' on its own seems like a nice to have.

'web ' (web + space, with no suffix) on its own isn't accepted by https://w3c.github.io/clipboard-apis/#dom-clipboarditem-clipboarditem so far as I can tell (maybe I'm wrong?), and it's not intuitive to me that a developer would try it.

But maybe I'm missing the point of the discussion. What are the alternatives we're considering?

[snianu]

ClipboardItem.supports('web valid/type'); // where we'd return true for 'web' + space prefix and valid mime type suffix suffix

I like this proposal as it also matches with how we parse the web custom format during the ClipboardItem construction. This also eliminates confusion between web text/html and webtext/html.
Tagging few other people who were involved in the initial discussion of this proposal for feedback. @annevk @whsieh @EdgarChen @tomayac

[tomayac]

I'm happy with #192 (comment), it extends #170 (comment) in a very logical way.

[evanstade]

• ClipboardItem.supports('web valid/type'); // where we'd return true for 'web' + space prefix and valid mime type suffix suffix

I suppose it is the case that the part after 'web ' has to be a valid MIME type. I missed that detail because it's not mentioned under optional data types. Perhaps that section should be updated to indicate that the prefix alone is not sufficient, and there are requirements for the rest of the string/type?

But maybe I'm missing the point of the discussion. What are the alternatives we're considering?

Which of these should return true?

The reason I questioned the utility of supports('web image/foo') is because, as far as I understood, everything after the 'web' prefix didn't matter. If the API accepts full custom types like web text/richtext, that suggests a user agent might return a different value for one full custom type vs another, but if the implementation is "just check the first 4 characters" then that's a false impression. Given that the suffix does at least have to be a valid MIME type ('web foo/bar' should return false), it does matter a little bit so it does make more sense to me that the API can take full custom types.

[css-meeting-bot]

The Web Editing Working Group just discussed Add supports API for async clipboard., and agreed to the following:

• RESOLVED: make the change that authors have to provide the full custom format with 'web ' (with space) prefix, and MIME type suffix.

The full IRC log of that discussion

<dandclark> topic: Add supports API for async clipboard.
<dandclark> github: https://github.com//pull/192
<dandclark> snianu: Supports API that was proposed some years ago, was proposed to feature detect in async clipboard API. So can determine if format is supported or not.
<dandclark> snianu: We had consensus in the WG that it's a good addition. Had stated need from web devs too. Need to know if given format is supported. Custom formats can be expensive to produce.
<dandclark> snianu: Leads to unnecessary work otherwise, to generate unsupported formts.
<dandclark> snianu: In this issue, proposal is for web custom formats, instead of just providing web prefix the author has to provide entire MIME type, web prefix and suffix.
<dandclark> snianu: If it's a valid format with 'web ' prefix, return true, else false.
<dandclark> snianu: Was some confusion with web custom formats we require the 'web ' prefix. Without the space it's invalid MIME type.
<dandclark> snianu: We strip out the 'web ' prefix and parse the MIME type to see if it's valid MIME type. Proposal is to let authors provide the entire format with the 'web ' prefix
<dandclark> snianu: 'web' and 'web ' (witth space) might be convenient to authors, but if they provide invalid MIME that it fails. So is better to require entire name, as 'web MIMEtype'. Ensures that format is valid and write will succeed.
<dandclark> johanneswilm: No comments from other implementers, what's this mean?
<dandclark> whsieh: Seems fine to me
<dandclark> johanneswilm: Can we resolve or is this controversial?
<dandclark> snianu: It's straightforward. We will make the change that authors have to provide the full custom format with 'web ' (with space) prefix, and MIME type suffix.
<dandclark> RESOLVED: make the change that authors have to provide the full custom format with 'web ' (with space) prefix, and MIME type suffix.

[snianu]

The PR for the resolution is #195