Additional ShareData types?

[plinss]

From the TAG review:

We accept this is likely limited by existing OS APIs, but during the review we thought about sharing other common data types, such as vCard, vCalendar, other structured data types, etc.

While those can be encoded into Blobs, it may be useful to allow sharing other data types, like a byte array, data which would be JSON serialized, or a raw string, accompanied by a content-type, without requiring the author to do the Blob encoding. If the OS share API doesn't support those types directly, the UA may auto-convert some common cases into files as necessary.

As the ShareData dictionary is inherently extensible, we don't feel this is required for V1, but just wanted to raise the issue.

[ewilligers]

If we adopt #181, users will be able to share any blobs.

I see limited value in inventing a new input format for (data + content-type), when the web platform already has Blob's constructor.

[marcoscaceres]

In the future, it might be nice to share HTMLImageElement, HTMLAudioElement, HTMLVideoElement, etc. that would take a lot of pain out of using the API.

[saschanaz]

In the future, it might be nice to share HTMLImageElement, HTMLAudioElement, HTMLVideoElement, etc. that would take a lot of pain out of using the API.

What would happen when the sources were MediaStream or just multiple <source>? 👀

[marcoscaceres]

I guess we will figure those out if we ever add them. Even HTMLImageElement is annoying because there is no direct way to get to the image data.

[marcoscaceres]

Closing as there is nothing actionable here.

[marcoscaceres]

Sent request to TAG to remove label https://lists.w3.org/Archives/Public/www-tag/2022Aug/0000.html