Change the ClipboardItem constructor to take ClipboardItemData.
#126
Conversation
Right now, the spec refers to two things as "items": - A list of `ClipboardItem`s. - The individual data values inside a single `ClipboardItem`. This is rather confusing, so this PR proposes to rename the latter to "entries", where an entry conceptually corresponds to a data type (e.g. `"text/string"`) that maps to a value (e.g. a Blob). This: - Matches the JS naming convention (think of `Object.entries`). - Does not change any spec semantics, only the names of some identifiers. In addition, this PR also renames: - `ClipboardItemDataType` → `ClipboardItemValue`, and - `ClipboardItemData` → `ClipboardItemValuePromise`. This matches the "entry is a type type mapping to a value" convention, and makes it clear what is a Promise. The previous names may have caused a semantic typo (w3c#126).
Right now, the spec refers to two things as "items": - A list of `ClipboardItem`s. - The individual data values inside a single `ClipboardItem`. This is rather confusing, so this PR proposes to rename the latter to "entries", where an entry conceptually corresponds to a data type (e.g. `"text/string"`) that maps to a value (e.g. a Blob). This: - Matches the JS naming convention (think of `Object.entries`). - Does not change any spec semantics, only the names of some identifiers. In addition, this PR also renames: - `ClipboardItemDataType` → `ClipboardItemValue`, and - `ClipboardItemData` → `ClipboardItemValuePromise`. This matches the "entry is a type type mapping to a value" convention, and makes it clear what is a Promise. The previous names may have caused a semantic typo (w3c#126).
|
FYI: my W3C affiliation is set to GitHub, Inc., but this my participation in this repo should be considered under my Chromium affiliation. I don't know if there's a way to tell the CI this. |
lgarron
changed the title
ClipboardItemData.ClipboardItemData.
|
Hi @lgarron. Thanks for these pull requests, we really appreciate your contribution to the Clipboard API. Re the IRP issue, it'd be difficult for W3C to use Chromium as a sponsor for pull requests, since Chromium hasn't (and probably can't) make IPR commitments. We are wondering, as a GitHub employee (and thus a Microsoft employee), if your contribution could be covered by Microsoft participation to the WebApps WG? |
Hmm, I'm not contributing this on behalf of GitHub/Microsoft, though. (GitHub has a pretty generous moonlighting clause.) |
|
Hi @lgarron, the key question for IPR commitment purposes is who has rights to the IP in this contribution? For example, if your employer lets employees keep the rights to work done in their own time, and that were the case for work you contributed here, then unless you made another agreement assigning rights, say to chromium, you would be able to make an individual IPR commitment here, and @siusin can send you the link. Feel free to get in touch with me if you have questions. ([email protected]) Thanks! |
|
@lgarron I'm looking into this right now. Feel free to ping-me offline for questions in the meantime... |
|
@wseltzer, @siusin, to close the loop on this: Microsoft has no concerns with @lgarron's individual contribution here--it is approved for him to make this contribution as an individual. @siusin please send @lgarron the relevant link to do so. @lgarron if you plan on making more regular contributions to this group, please let me know, and I'll get you connected with the folks that help coordinate our activities here, we can get you added under Microsoft's contribution agreement. That will remove these speed bumps from your future contributions. ;) |
|
Thanks all! @lgarron we can consider #126 as a non-normative contribution but please at least sign the Non-Participant Licensing Commitment for #127 via |
|
Blocking on template actions. Editors, could you please make sure bugs are filed on the user agents and that there are corresponding tests. It seems @lgarron has identified some additional compat bugs, so would be great to have tests to help resolve those across UAs. |
Closes #????
The following tasks have been completed:
Implementation commitment:
Right now:
ClipboardItemDataTypeis astringor aBlob;ClipboardItemDatais a Promise of aClipboardItemDataType.There are definitely some compatibility issues in the wild. In particular, Chrome only accepts
Blobs, and throws an exception if you pass in a string or a Promise. Is it possible that the constructor is supposed to takeClipboardItemDataTypevalues? If not, should it accept any values that are eitherClipboardItemDataorClipboardItemDataType?FYI: my W3C affiliation is set to GitHub, Inc., but this my participation in this repo should be considered under my Chromium affiliation.
Preview | Diff