Re: [mediacapture-handle] Should the handle be an object? (#68)

First, thank you for attempting to address concerns you thought I might have. I appreciate that, but it's not that simple.

It goes back to use cases. I found users having [nextslide](https://w3c.github.io/mediasession/#dom-mediasessionaction-nextslide) and [previousslide](https://w3c.github.io/mediasession/#dom-mediasessionaction-previousslide) on a loosely-coupled captured page compelling. But I'm fairly confident those may also end up becoming keyboard hardware hotkeys someday, which is a high bar.

But those also opened up a long tail of ideas that didn't make it ("firstslide", "lastslide", https://github.com/w3c/mediasession/issues/282) and maybe never should, because there's a risk and a cost to baking into the web platform forever what we think apps want today.

I don't find loosely-coupled pages advertising crop regions compelling enough to bake into the web platform now.
I don't find loosely-coupled pages advertising content hints compelling enough to bake into the web platform now.

It's not clear to me we're ready to say how this should work forever. App-controls also encroach on what's a fully user-controlled feature today, so there are risks they may sometimes undermine user choice if we're not careful.

Since this spec already enables apps to experiment in this space, I'd rather wait an see how they solve this.

> > we seem overdue for the third option IMHO... a rudimentary messaging API.
> 
> Do we agree on this?

I remain curious about an answer to this question.

-- 
GitHub Notification of comment by jan-ivar
Please view or discuss this issue at https://github.com/w3c/mediacapture-handle/issues/68#issuecomment-1286157031 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Thursday, 20 October 2022 21:11:23 UTC