-
Notifications
You must be signed in to change notification settings - Fork 37
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
New terminology: ClipboardItem "entry" as data type → value. #127
base: main
Are you sure you want to change the base?
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).
|
||
[Exposed=Window] interface ClipboardItem { | ||
constructor(record<DOMString, ClipboardItemData> items, | ||
constructor(record<DOMString, ClipboardEntryValue> entries, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This change assumes that #126 is correct (e.g. matching Chrome's current behaviour). If this should accept Promise
s, then either:
- the record values should be
ClipboardEntryValuePromise
and Chrome's implementation should be changed, or - the record values should be allowed to be either
ClipboardEntryValue
orClipboardEntryValuePromise
.
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 the IPR issue has been fixed by @travisleithead and our Systeam. It will no longer be a blocker for future contributions. |
@lgarron: are you still working on this PR? The change itself is desirable, it just requires slight adaptation to match the current base. |
Yeah, I'd be glad to do that! Please give me a few days! 🙏 |
@lgarron: just to be sure, do you still intend adapting this patch soon? It would be valuable. |
@lgarron: can you please give an update if you still intend to adapt this patch? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These IDL changes don't impact any behavior, and they make sense to me.
Right now, the spec refers to two things as "items":
ClipboardItem
s.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:Object.entries()
).In addition, this PR also renames:
ClipboardItemDataType
→ClipboardItemValue
, andClipboardItemData
→ClipboardItemValuePromise
.This matches the "entry is a type mapping to a value" convention,
and makes it clear what is a Promise. The previous names may have caused
a semantic typo (#126).
Closes #????
The following tasks have been completed:
Implementation commitment:
Preview | Diff