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

Audio and Video controls should look disabled #9252

Closed
tofumatt opened this issue Aug 22, 2018 · 11 comments
Closed

Audio and Video controls should look disabled #9252

tofumatt opened this issue Aug 22, 2018 · 11 comments
Labels
[Block] Video Affects the Video Block [Feature] Blocks Overall functionality of blocks [Type] Enhancement A suggestion for improvement.

Comments

@tofumatt
Copy link
Member

Right now the Audio and Video blocks allow the user to show/hide the controls for them, but they are wrapped in a <Disabled> tag inside the editor (so the user won't accidentally activate them when clicking on the block, see:
#7929 (comment))

We should at least dim/imply visually the controls are disabled in the editor but still show them somewhat to let the user know they're on.

See:
#7929 (comment) for more context.

@tofumatt tofumatt added [Type] Enhancement A suggestion for improvement. Good First Issue An issue that's suitable for someone looking to contribute for the first time labels Aug 22, 2018
@designsimply designsimply added the [Feature] Blocks Overall functionality of blocks label Aug 22, 2018
@Copons Copons self-assigned this Aug 23, 2018
@Copons
Copy link
Contributor

Copons commented Aug 23, 2018

Fun fact: there are no straightforward ways to style HTML media controls, because the HTML media player is built into the browser.
The only thing I've tried is lower the opacity to make it look "discoloured", but then it might look odd on non-white backgrounds.

@tofumatt
Copy link
Member Author

Yeah, it might be the case that adding "fake" controls over the tag is the trick, just to indicate the controls are there. 🤷‍♂️

@afercia
Copy link
Contributor

afercia commented Aug 26, 2018

Not sure why users shouldn't be able to play a video or audio in the editor. Maybe I've missed something but what's the reasoning behind that? Also, it's a bit inconsistent with embeds: for example, an embedded video (youtube, vimeo, etc.) can be played.

The editor should be a real preview of what users are going to have in the front-end. I'd consider to allow video-audio playing and pass the props (e.g. autoPlay, muted, loop) also when editing.

@maddisondesigns
Copy link

Was actually just about to raise a new issue about not being able to play audio files when I found this issue. If users can play videos in the editor, then they're going to expect to be able to play audio files as well. It makes no sense to allow one, but not the other, and it's also incredibly confusing and inconsistent for the user as well.

@tofumatt
Copy link
Member Author

tofumatt commented Oct 3, 2018

The issue with playing them (right now) is that audio/video blocks can be clicked to focus them and start editing, but this will also start playback (which is very jarring when it wasn't the intended effect).

I would be fine if playback started on the second click. But right now it is jarring to start playback, especially one that starts audio, on a click that usually just focuses a block.

Maybe when the block isn't focused we should disable playback controls no matter what; I'm not sure if blocks can toggle behaviour based on focus state but that's what would work best here.

@Copons Copons removed their assignment Oct 3, 2018
@maddisondesigns
Copy link

@tofumatt I can understand that, and it's a good point you make about the video block. I find it annoying that it starts playing when you click it, when most of the time you simply want to select it. Having them both different though, is still inconsistent. I would rather see them both (video & audio blocks) not play, than have one play and one not.

Is it possible to make separate controls for them both? i.e. Stop both of them playing when they're clicked, but instead, have a Play and Pause button in their respective toolbar that allows you to play/pause the video/audio if you really want to.

@tofumatt
Copy link
Member Author

tofumatt commented Oct 4, 2018

Having them both different though, is still inconsistent. I would rather see them both (video & audio blocks) not play, than have one play and one not.

Agreed 💯

Is it possible to make separate controls for them both? i.e. Stop both of them playing when they're clicked, but instead, have a Play and Pause button in their respective toolbar that allows you to play/pause the video/audio if you really want to.

You can control playback using JS as I understand it; I think it needs to be done inside a click event but in our case it should be fine. I'd be happy with that solution. Not sure if it should go in the toolbar or maybe somewhere else. What would make the most sense to me is custom playback controls (play/pause) that is only visible on :focus, or block focus being what enables playback controls on the HTML element.

@maddisondesigns
Copy link

The main reason I suggested the toolbar is because I realise how little real-estate there is available in the audio block as the player isn't very tall. But with that said, if separate controls can be added elsewhere, that would work too

@jorgefilipecosta
Copy link
Member

Removing Good first issue label as in accordance with what @Copons referred given browser limitations this issue may be complex.

@tomdevisser
Copy link
Member

@tofumatt I see this has issue has been stale and inactive for a long time. Is the issue still relevant or can this be closed?

@carolinan
Copy link
Contributor

Neither the video or audio controls are disabled in the editor anymore.

@carolinan carolinan closed this as not planned Won't fix, can't repro, duplicate, stale Apr 28, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Block] Video Affects the Video Block [Feature] Blocks Overall functionality of blocks [Type] Enhancement A suggestion for improvement.
Projects
None yet
Development

No branches or pull requests

9 participants