Remove MIME types from mandatory data list that are not supported by all browsers.

[snianu]

Closes w3c/editing#305

For normative changes, the following tasks have been completed:

• Modified Web platform tests (link to pull request)

Implementation commitment:

• Already implemented by WebKit, Chromium & Gecko.

---

Preview | Diff

[annevk]

I would prefer to only land the MUST lists as those seem to have agreement. Optional support for types doesn't seem like a great thing to allow and wasn't discussed in the referenced issue.

[snianu]

@annevk
Chromium, Safari & FF have support for types that are not in the list, but they are exposed via DataTransfer & async clipboard APIs.
e.g. Safari has support for text/uri-list, Chrome has support for image/svg+xml etc.
I think it's fine to add the mime types that are supported in all browsers in the MUST support list, but we should at least mention the types that are supported by a particular browser so the web authors are aware of it. This type may not be available in other browsers so I added those "optional" types to the MAY support list. It also leaves room for future improvements to support more standard well known types defined by the OS (this is different than custom formats support).

[annevk]

That's not entirely clear to me. For the types that only some browser supports the right answer might well be that the browser removes support for that type. If all browsers are to implement it, it shouldn't be optional. This isn't a guide for web developers, this is what we want browsers to converge on.

[snianu]

@annevk OK, removed the optional types. PTAL.

[annevk]

This looks to be in line with the discussion, however, shouldn't JPEG and GIF be supported as well?

This would benefit from at least one other set of eyes.

[snianu]

Added @mkruisselbrink to the review as well.

[snianu]

shouldn't JPEG and GIF be supported as well

I think in Chromium, we convert these into PNG and write it to the clipboard. @a-sully made changes in this space so maybe he can confirm the behavior here.

[a-sully]

I'm not familiar with the details of how non-PNG images are written to the clipboard, but I can confirm that PNG is the only image format supported on the Chromium clipboard. That being said, JPEGs and GIFs are typically copied to and read from the clipboard as files using the text/uri-list mime type anyways.

[snianu]

@a-sully

That being said, JPEGs and GIFs are typically copied to and read from the clipboard as files using the text/uri-list mime type anyways

At least on Windows, I don't see Chromium reading GIF, JPEGs files. In this method, I see only PNG and BMP formats being read from the clipboard. However, on Windows, when I copy a GIF file, the location of the file is present in the clipboard under CFSTR_FILEDESCRIPTORA format. So looks like this is only supported via DnD/DataTransfer APIs, but not in async clipboard APIs. Is my understanding correct?

[a-sully]

They're read as files using the ReadFilenames() code path. Though it seems that Windows (CFSTR_FILENAMEW) and Mac (NSFilenamesPboardType) actually use custom types rather than text/uri-list (which is used on Linux + Android), so I take that back. Should've confirmed in the code first.

I realized I wasn't very clear on this above. Yes, you are correct. Reading files is not yet supported for the Async Clipboard API, though we'd like to at some point (see the tracking bug).

[snianu]

Thank you for confirming! Since Safari already supports text/uri-list MIME type and Chrome has plans to add support for this MIME type in the future, should we add this format to the mandatory data types?

[snianu]

Gentle ping.. I'd like to merge this PR and work on improving other parts of the spec.

[snianu]

Adding @mbrodesser as well. Gentle ping for review....

[mbrodesser]

Looks OK to me, given the previous discussion at w3c/editing#305.
Only the title of the PR should be adapted to reflect the current change.

[snianu]

Adding @whsieh as well for sign-off

[whsieh]

Looks good to me!