Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Support 'preload' attribute for Video Block #7929
This PR adds the preload attribute to the video block.
The design is the same as the preload in Audio, see #7590
referenced this pull request
Jul 12, 2018
@tofumatt May I ask you more info regarding the decision of disabling the player controls?
While working on #8055 I got used to play the audio file to make sure it was uploaded correctly, so now it feels a bit weird that the player controls don't work anymore.
As it is right now, there are no visual clues that those controls don't work (e.g. they are not "grayed out"), and so the player feels broken even if it isn't.
Right now clicking on the block in any way activates the controls, which is very jarring when the user just means to click on the block to edit it. I ran into this while testing the block in this branch, and we've used a similar pattern elsewhere for things like server-side rendered blocks with HTML comments that, when clicked, will activate a link: https://github.com/WordPress/gutenberg/blob/master/packages/block-library/src/latest-comments/edit.js
I can see the argument for testing the content, though if it was uploaded and working you'll see a preview frame and length the in the players. I think testing the content is better done in the preview screen, leaving the editing screen to edit/interact with the content in an editing context.
If we were to add controls I think they'd be better in the inspector or the toolbar anyway so they're:
If you wanted to see that implemented–feel free to file a bug and we could discuss it further.
EDIT: Oh, and please cc me on the bug.
@tofumatt Thanks for the answer!
I guess disabled controls are ok per se, but I'd like to know that they are disabled (for example with some disabled style) before clicking on them, panicking, and eventually maybe realize they are just for show.
That's fair! The