[w3c/editing] The Web Custom formats specification does not appropriately use the macOS API (Issue #412)

I encountered the code implementing https://github.com/w3c/editing/blob/gh-pages/docs/clipboard-pickling/explainer.md#detailed-design-discussion inside of Chromium and was pointed here. This specification does not use the macOS clipboard API appropriately and this should be fixed before shipping.

The first issue is naming. The custom format map is specified to have the format type `com.web.custom.format.map`, and the various formats are specified to have the format names `com.web.custom.format[\d+]`. This specification is not the work of [web.com](http://web.com/), and thus using the `com.web.*` prefix is inappropriate. If this is a W3C specification, a prefix of `org.w3.*` is probably the most appropriate.

The second issue is the existence of a custom format map. On platforms for which there is a limit on the number of formats, this might make sense. But on the Mac, types are just reverse-domain strings, and so keeping a map strikes me as a waste. Would there be an issue in not having a map type on the Mac, and instead just doing a mapping of, say, the `text/html` type to `org.w3.web-custom-format.text-html`, `my/wackytype` to `org.w3.web-custom-format.my-wackytype`, etc? There’s no reason that the native interface must look identical on all platforms, and since we already have to accomodate for their differences, we should take the opportunity to play to their strengths.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/editing/issues/412

You are receiving this because you are subscribed to this thread.

Message ID: <w3c/editing/issues/412@github.com>

Received on Tuesday, 6 December 2022 04:43:35 UTC