[wp-trac] [WordPress Trac] #38172: Enable Video Headers in Custom Headers

[WordPress Trac]

#38172: Enable Video Headers in Custom Headers
-------------------------------------+-------------------------------------
 Reporter:  davidakennedy            |       Owner:  joemcgill
     Type:  task (blessed)           |      Status:  accepted
 Priority:  normal                   |   Milestone:  4.7
Component:  Themes                   |     Version:  trunk
 Severity:  normal                   |  Resolution:
 Keywords:  has-patch ui-feedback    |     Focuses:  ui, accessibility,
  ux-feedback dev-feedback has-      |  javascript
  screenshots                        |
-------------------------------------+-------------------------------------

Comment (by bradyvercher):

 Thanks for taking the time to review this, @joemcgill!

 > Setting a size limit on videos to 8MB is helpful, but I think it's
 wasteful to load the header image only to immediately swap it for the
 video HTML once the document loads. I would rather see us lazy load either
 the video or the image, depending on context and browser support, not
 both.

 This is pretty much how the native `<video>` element with a `poster`
 attribute works. If you load that up in a browser and take a look at the
 Network tab in DevTools, you'll see requests for each.

 The image should display when the video can't play, which includes
 environments without JavaScript support. A theme could use CSS to hide the
 image for browsers with JS support, which should prevent it from loading,
 then the script here could make it visible if the video can't be embedded,
 but that complicates the implementation a bit.

 > Related, it looks like this loads both the header image and video
 regardless of screen size. I know that trying to assume much about
 someone's connection based on screen size can be problematic, but I'm
 curious if there is a way to set a minimum width for loading the video.

 I added a `supportsVideo()` method with a comment in `wp-custom-header.js`
 that the environment could be inspected before deciding to load the video,
 but I haven't seen any discussion about which environments this should be
 restricted to. Is there a certain breakpoint that would be preferable?

 Aside from screen width, Android and iOS (prior to 10) won't automatically
 play videos without user interaction, so checking the user agent for those
 devices would probably make for a good test. Here's some more information
 about [https://webkit.org/blog/6784/new-video-policies-for-ios/ new video
 policies in iOS 10].

 In any case, adding tests should be fairly easy if the requirements can be
 defined.

 > In TwentySeventeen, video headers seem to only work if you also have an
 image header set. This does not a requirement in TwentyFourteen. Not sure
 which is the intended functionality...

 I don't believe that's the intended behavior, so the Twenty Seventeen
 implementation likely needs to be adjusted.

 > When switching from a local video header to an external video, I had to
 first remove the local video and save my settings before setting the
 external URL, otherwise the validation callback still sees the ID for the
 local video and returns an error.

 I've run into a few weird quirks with validation as well. Consolidating
 those two controls would be ideal from a UX perspective, but it would
 likely require a new, unique control.

 > In my testing, YouTube URLs don't automatically loop, so you see the YT
 play button once the video ends, which is kind of odd.

 The `loop` setting is set to true for those, but we could also just play
 the video again when the `ended` event is triggered. I can add that if
 necessary.

 > Additionally, YouTube videos don't autoplay on mobile devices and click
 events don't seem to reach the iframe in order to start them (in
 TwentySeventeen at least).

 Not autoplaying is likely related to the restrictions I mentioned earlier
 in Android and iOS.

 Click events seem to work fine for me on desktop, but the site title and
 description do cover the bottom portion of the video, so those would catch
 click events. Adding the play/pause control mentioned by @davidakennedy
 and @celloexpressions would help, too.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/38172#comment:60>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform