Skip to content
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

Invoker HTML buttons #12

Open
tomByrer opened this issue Oct 3, 2023 · 2 comments
Open

Invoker HTML buttons #12

tomByrer opened this issue Oct 3, 2023 · 2 comments

Comments

@tomByrer
Copy link

tomByrer commented Oct 3, 2023

Directly assigning HTML controls to video player controls:

<input type="checkbox" invoketarget="my-video" invokeaction="playpause" >Play/Pause</button>
<input type="checkbox" invoketarget="my-video" invokeaction="mute">Mute</button>

<video id="my-video"></video>

https://github.com/keithamus/invoker-buttons-proposal#customizing-videoaudio-controls
https://github.com/keithamus/invoker-buttons-proposal/issues/28
https://github.com/keithamus/invoker-buttons-proposal/issues/14#issuecomment-1744204920

While this proposal is not adding capabilities to <video>, it can directly affect that element, & I hope you can give feedback.

@cjpillsbury
Copy link
Collaborator

Hey @tomByrer sorry for the extremely delayed response! This project has unfortunately gone into a bit of a holding pattern due to resourcing constraints/priorities at Mux for the time being (the primary maintainers + contributors all being Mux employees at the moment). Overall this is not a bad idea. At least for the time being, this is probably out of scope for the goals of this project, which are to extend the HTMLMediaElement's API for properties that are not (reliably) derivable from its primary state/API. That said, I get why you see its relevance, and I agree with that. Currently, Media Chrome and the related web component-based extended media elements is the primary testbed for applying the APIs defined here (at least as far as I know. I would love to know of/see other examples!). There, we use an abstraction to translate "state change requests" to side effects on, e.g. an HTMLVideoElement (or web component), which doesn't quite fit with this convention as it sits. However, I could see conforming to this as a potential re-architecture.

This is a long-winded way of saying I'm not sure if there will be any significant movement of this issue here and now, but I'd like to keep this alive and at least do some crowd sharing on this with, e.g. the Media Chrome team and others. For example, establishing well-defined "invokeaction" hints may not be a bad idea for the larger goals of this initiative.

Thanks for the engagement and again apologies for the delay!

@heff
Copy link
Member

heff commented Feb 6, 2024

I agree this is outside the scope of this specific repo, but thanks for pointing us to it @tomByrer! I'll check out the issues you linked and see if I have anything to add.

If the invoketarget API is getting somewhere, I could see us adding that as an optional pattern on the media chrome side

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants