search

w3c / editing

Specs and explainers maintained by the editing task force
http://w3c.github.io/editing/
Other
191 stars 40 forks source link

The Web Custom formats specification does not appropriately use the macOS API #412

Closed avidrissman closed 1 year ago

avidrissman commented 1 year ago

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, 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. [Edit: This aspect of the proposal turns out to not be viable; see my followup below.] 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.

snianu commented 1 year ago

The second issue is the existence of a custom format map.

The custom format map is an implementation detail. We don't expose it to the web. It is only useful on platforms where the atom table could be exhausted by registering new clipboard formats. When the atom table is exhausted, the system goes into an irrecoverable state. To address this issue, we came up with the mapping idea so we can have a hard limit on how many formats you could write to the clipboard on those platforms.

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, 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.

@whsieh @annevk Thoughts?

avidrissman commented 1 year ago

Right. I have no issue with the web-exposed side of this proposal. I only have issues with the Mac platform integration side.

avidrissman commented 1 year ago

The custom format map is an implementation detail. We don't expose it to the web.

From the web perspective, yes, the custom format map and the native types used are an implementation detail. Web sites don’t see those things. From the native app perspective, the custom format map and the native types used are not implementation details.

In a more general sense, when we write web specs, we want to be careful how we specify new DOM features and attributes, to make sure they fit in with other existing features. We want them to be elegant and straightforward, and as idiomatic-feeling as we can achieve. When we specify the native integration aspects of web specs, we want to take the same care in attempting to achieve the same goals. Native apps are going to be interacting with this spec just as much as web sites are going to be interacting with this spec. We should offer those native apps the most elegant, straightforward, and idiomatic spec as possible.

That’s why I want to clean this up now, while (AFAICT) there are no Mac apps yet using this feature.

annevk commented 1 year ago

We haven't really had time to evaluate this API in full detail as-of-yet, but this might be a case where changes to the platform API make sense.

avidrissman commented 1 year ago

Note that I dug into removing the mapping on the Mac. Unfortunately, there’s no good way to map MIME types down to UTType identifiers in a reversible way that’s human comprehensible. If we have to have a map anyway, we might as well reuse the one for other platforms.

I submitted a PR for the spec, #416, and posted a CL implementing that change at https://crrev.com/c/4108170. PTAL at both.