Audio and Video controls should look disabled

[tofumatt]

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.

[Copons]

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]

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

[afercia]

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]

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]

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.

[maddisondesigns]

@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]

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]

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]

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

[tomdevisser]

@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]

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