minutes, call 2025-08-14

[17:06] <johanneswilm> https://github.com/w3c/clipboard-apis/issues/240
[17:06] <ragoulik> All items for today's discussion are from Clipboard APIs
[17:07] <ragoulik> Ashish(Microsoft) presented Selective Clipboard Format
Read for async clipboard read api
[17:09] <ragoulik> Motivation: Reading all clipboard format can be
inefficient when web dev is already aware of MIME type they want. Rename
optional argument to read() to ClipboardReadOptions and extend this object
to include a new types property which is a list of mime types to be
retrieved.
[17:09] --> Tanu (~Tanu@9cd7628a.publics.cloak) has joined this channel.
[17:09] --> whsieh (~whsieh@9cd7628a.publics.cloak) has joined this channel.
[17:11] <ragoulik> Olli: Do we need this optimization - given getTypes that
is done at a later time is probably the expensive operation.
[17:14] <ragoulik> Ashish: There is an alternate approach mentioned in
explainer - which had its own concerns.
[17:14] <ragoulik> Anne: Special read method that takes a type and returns
data of that type.
[17:15] <ragoulik> Anne: suggest an alternate like:
clipboard.readType(MIMEType)
[17:18] <ragoulik> Anne questions how dev would be communicated of the perf
optimization, johannes: In wholesomeness of a large webapp devs try to
optimize for performance
[17:19] <-- whsieh (~whsieh@9cd7628a.publics.cloak) has left this server.
[17:20] <ragoulik> Johannes tried to conclude that only concern is the
messiness of the API signature, Anne responded with even that is not a
major concern.
[17:22] <johanneswilm> https://github.com/w3c/clipboard-apis/pull/239
[17:22] <ragoulik> overall no opposition to the concept of Selective
Clipboard Format Read.
[17:25] <ragoulik> Rohan: Request for review of Pullrequest for spec change
for ClipboardChangeEvent API proposal that was discussed and was agreed
upon in principal.
[17:29] <ragoulik> Wenson; Asked details of hero use cases, Rakesh and
Rohan explained the paste context menu options, web remote desktop apps
clipboard usecases. Also explained why standard mime types(not data) were
part of the event.
[17:29] --> whsieh (~whsieh@9cd7628a.publics.cloak) has joined this channel.
[17:30] <ragoulik> Olli: What happens when a document that was not in focus
during clipboard change but comes into focus at a later time.
[17:31] <ragoulik> Rohan: If clipboard changes, the even is fired upon
focus regain once - even if there were multiple changes to clipboard.
[17:31] <ragoulik> Anne: Spec should say something about cross origin
iframes.
[17:33] <ragoulik> Anne: what if user has not interacted with page at all.
Rohan: Focus is needed for event to fire.
[17:35] <ragoulik> Wenson: Are we looking for useractivation - that is if
user ever interacted with page. Transient or sticky activation. If this
should be mentioned in some form in the spec. And this shouldn't be problem
for the usecases that were discussed.
[17:36] <ragoulik> Olli: focus + stickyactivation is recommended
[17:36] <dandclark> Looks like this is the spec term you can link to:
https://html.spec.whatwg.org/multipage/interaction.html#sticky-activation
[17:37] <ragoulik> Wenson: In case where webpage itself is writing to
clipboard. Rohan: Yes a changeevent will be notified.
[17:38] <johanneswilm> https://github.com/w3c/clipboard-apis/issues/232
[17:41] <ragoulik> Luke: Reopened issue#232 and mentioned mutiple tab
scenario that would need an identifier to uniquely identify a
cliboardchange event
[17:42] <ragoulik> Rohan: Is it possible webdevs can hash the clipboard
data to address the multiple table scenario.
[17:43] <ragoulik> Luke: Yes, devs may already be using it, but that is
computationally intensive.
[17:43] <whsieh> q+
[17:45] <ragoulik> Wenson: Providing clipboard hash has privacy concerns:
Luke(zgroza), mentioned that Rohan actually questioned if webdevs can hash
it at their end and proposal is not to provide an hash.
[17:46] <ragoulik> Anne considers it is reasonable to include a unique
identifier for an event.
[17:48] <ragoulik> Wenson: ChangeCount is computationally cheap to get that
can be used somehow
[17:48] <-- Tanu (~Tanu@9cd7628a.publics.cloak) has left this server.
[17:48] <-- annevk (~annevk@9cd7628a.publics.cloak) has left this server.
[17:51] <ragoulik> Rohan: No strong opinions, as long as there is no
fingerprinting or correlation with data
[17:52] <ragoulik> Johannes: Do we prescribe in the spec how the
clipboardchange unique identifier is created.
[17:53] <ragoulik> Olli: Its important to mention if it will be random or
incrementally increasing.
[17:54] <ragoulik> Rakesh: User discernable pattern to this identifier may
be opening for fingerprinting.
[17:54] <ragoulik> Anne: proposes uuid as a safe option.
[17:55] <ragoulik> Anne: for a single origin when does this identifer get
reset (for incremental scenario).
[17:56] <ragoulik> uuids may be a safe idea
[17:58] <ragoulik> Luke: you would have to make it unique per partition
[18:00] <-- whsieh (~whsieh@9cd7628a.publics.cloak) has left this server.
[18:00] <johanneswilm>
https://lists.w3.org/Archives/Public/public-editing-tf/
[18:01] <ragoulik> Johannes: We can continue to discuss the unique
identifier approach for the next meeting.

-- 
Johannes Wilm, PhD
tel +46766922220
https://www.johanneswilm.org