[invokers] Copy action

[lukewarlow]

While thinking on common patterns that might benefit from an invokeaction the topic of clipboard actions came to mind.

I'm thinking at least a "copy" action would be useful for copying the text contents of an element, be it a textarea, input or just a general html element displaying text.

This should require a user gesture to work (and follow any existing permission policy restrictions)

A paste or cut event could also be useful but (especially paste) may require further thought from a security POV.

---

Examples

• https://cloudscape.design/components/copy-to-clipboard/
• https://shoelace.style/components/copy-button/
• https://github.com/github/clipboard-copy-element

[lukewarlow]

I think this should initially only work for text data. But potentially if it points to an it should copy that image data? Happy to discuss further.

[keithamus]

Oh yeah this would be an amazing addition! GitHub maintains https://github.com/github/clipboard-copy-element which allows the following patterns:

<clipboard-copy for="blob-path">
  Copy path
</clipboard-copy>
<div id="blob-path">src/index.js</div> <!-- `src/index.js` gets copied -->

<clipboard-copy for="blob-path">Copy</clipboard-copy>
<input id="blob-path" value="src/index.js"> <!-- `src/index.js` gets copied -->

<clipboard-copy for="blob-path">Copy full URL</clipboard-copy>
<a id="blob-path" href="/path/to#my-blob">Link text will not be copied</a>

<clipboard-copy value="src/index.js">Copy</clipboard-copy> <!-- `src/index.js` gets copied -->

I'd happily sacrifice the last one if we could retain the others. Or perhaps we can leverage mime types to copy the plain text in the text/plain mime and the outerHTML of an element in the text/html mime?

[lukewarlow]

https://codepen.io/lukewarlow/pen/dyaZJjj

Here's a naive implementation (Chrome Canary or Firefox nightly will be needed) that uses JS to achieve this.

I think the main questions here are around the exact specifics of copying when it's more than just copy the innerText of an element.

[lukewarlow]

@keithamus I think your top two for sure are possible. I think the third one is interesting and might require some research of various copy button implementations to see what should happen. The fourth one as you say wouldn't work.

...unless and this might be an awful idea, what if the invoketarget was the invoker itself...

[keithamus]

...unless and this might be an awful idea, what if the invoketarget was the invoker itself...

If the heuristic was "for form control elements, the value is copied, for everything else the textContent is copied" then this would make the last option possible by adding a value to the invoker button, and as you say, have it target itself. A bit weird but I dig it.

[lukewarlow]

We may be onto something here...

[lukewarlow]

See https://shoelace.style/components/copy-button/#properties

To copy an attribute, append the attribute name wrapped in square brackets, e.g. from="el[value]". To copy a property, append a dot and the property name, e.g. from="el.value".

This is a neat solution to choosing the behaviour. Idk if we'd get away with doing it for the defaults but cool nonetheless.

[css-meeting-bot]

The Open UI Community Group just discussed [invokers] Clipboard `invokeaction` defaults, and agreed to the following:

• RESOLVED: Pursue copy invoke action but not as part of initial landing of invokers.
• RESOLVED: Invokers v1 will be popover and dialog invoking.

The full IRC log of that discussion

<keithamus> q+
<hdv> Luke: copy to clipboard button I've come across in a lot of different system… it feels like something that could fit into the invoker paradigm
<hdv> Luke: there are some specifics that need further working out
<brecht_dr> q+
<gregwhitworth> q+
<masonf> q+
<hdv> Luke: is that something we think is a good idea?
<gregwhitworth> ack keithamus
<scotto_> q+
<hdv> keithamus: on the one hand it elimates an entire custom element from our code base, so +1
<hdv> keithamus: on the other hand it doesn't rhyme with the purpose of invokers, which is declarative dispatch
<hdv> keithamus: that's probably the line we should draw for these things
<gregwhitworth> ack brecht_dr
<gregwhitworth> ack gregwhitworth
<gregwhitworth> q+
<hdv> brecht_dr: I love the idea of making something like this possible
<hdv> brecht_dr: do wonder if it could lead to security issues?
<hdv> Luke: I think it follows the same logic as the full screen action, we have permission policy for clipboard
<hdv> Luke: in which case that woulnd't work
<hdv> keithamus: and you could already do it today with scripting… and it's a push rather than polling user data
<gregwhitworth> ack masonf
<hdv> Luke: was some discussion re we need more than copy button (not sure if, say, a paste button is useful)
<hdv> masonf: similar comments to keith, I have seen these buttons, it seems handy
<hdv> masonf: the intention that this calls methods on an element… there is maybe some grey area? we could propose an api called copy to clipboard… in other words… not sure if the restriction would apply
<hdv> masonf: I would want to avoid this proposal to become too large for it to block it from landing… if we have invoker everything starts to look like a invoker
<hdv> Luke: we could probably land popover and dialog first, then land other features… though might become an issue to find what's supported
<hdv> keithamus: there are probably ways to use feature detection
<hdv> masonf: probably a great approach, there will be a lot of learnings anyway landing this, so the smaller it can be the better
<gregwhitworth> Zakim, close the queue
<Zakim> ok, gregwhitworth, the speaker queue is closed
<hdv> Luke: there's probably a lot of ironing out… I think they wanted us to put it all in one PR
<hdv> scotto_: largely what everyone said… it's almost like we need a temporary state button… something like 'click to copy' and typically the text changes to 'copied', but you don't want the accessible name to actually change… so maybe you need a notification API too (which is being worked on)
<hdv> scotto_: looks like a lot more work than invokers. Let's do this but later
<Luke> Proposed Resolution: Pursue copy invoke action but not as part of initial landing of invokers.
<gregwhitworth> ack scotto_
<gregwhitworth> ack gregwhitworth
<keithamus> +1
<masonf> +1
<hdv> +100
<gregwhitworth> +1
<scotto_> +1
<Luke> RESOLVED: Pursue copy invoke action but not as part of initial landing of invokers.
<scotto_> +100 by not including details as part of initial proposal ;)
<Luke> Proposed Resolution: Invokers v1 will be popover and dialog invoking.
<masonf> +1
<brecht_dr> +1
<scotto_> +1
<hdv> +1
<keithamus> +1
<hdv> +1 (unless there is some very low hanging fruits?)
<Luke> RESOLVED: Invokers v1 will be popover and dialog invoking.
<gregwhitworth> Zakim, end meeting