As part of a recent project, I needed to find a way to make self-hosted video (i.e. video files uploaded to client’s hosting server rather than YouTube or the like) responsive.  I.e. so they shrink down proportionally with screen size.




I decided to use the VideoJS plugin as a good way to support both HTML5 video (for those browsers that will display it) and a fallback flash version (for those browsers… namely older versions of IE… that won’t).




Making HTML5 video responsive is simple.  Making the flash fallback responsive is not simple.  It took me literally days.  Which is why I decided to post the solution here.



The Responsive Video Solution

NOTE: Please see update towards the bottom of this post; I have modified the original CSS to ensure VideoJS fullscreen functionality continues to function correctly.




Please see example here: http://skybolt.xssl.net/~hexagon2/responsive-video/ – try resizing your screen in an older version of IE, and the video should still resize.  In the example, I’m using WordPress & the WordPress VideoJS plugin, but I believe this should work with a non-WP site and the standard VideoJS script too.


The solution is entirely HTML/CSS based (i.e. no javascript in addition to that used by VideoJS), and is essentially a modified version of the technique described on A List Apart here: http://www.alistapart.com/articles/creating-intrinsic-ratios-for-video/.


The normal Video JS code is wrapped in a containing div as follows:



The CSS is what does the trick.  It does rely on having a videos of fixed proportion (hence the 41% value), but I wonder whether this could also be combined with a modification of the Fit Vids script (which currently just works with hosted video from YouTube etc) to take this constraint away.  For my purposes, fixed proportion was fine.



And there you have it – a responsive video – not only in browsers that support HTML5 but in those that don’t too.


I hope that helps someone!



Update 17th January 2012

Based on some of the comments received below, I thought it would be worth posting an update, covering two things:

 

1. A fix for the broken ‘full screen video’ problem

@Robert Roy kindly pointed out that the method outlined above appears to break the fullscreen functionality of VideoJS. I have therefore revised the CSS as follows. Note that you may also need to adjust the z-index property on other elements within your page, to ensure the fullscreen video always sits on top of other content. Different browsers seem to create different problems with this (even more so than usual!), so make sure you test appropriately.

 
2. Where the code goes

This is in response to a question posted by @Mark – where does the code above go?

The css can be added to standard styles.css file in your theme (wp-content/themes/your-theme-name/styles.css).

The containing

needs to be added around the result of the video js shortcode.  There are two ways of doing this: either use the HTML editor within a post, so you’d end up with something like this:

or alternatively (what I did when I originally worked this out for a client project), create a custom field for the video to be uploaded to, then in the relevant php file (this might be in page.php for example), you would have something like this:

(where $mp4 and $webm are variables containing the path to the relevant video files, grabbed from the custom fields).

Back in July (that long ago?!), I was talking about mobile websites.  As I’m in the midst of creating my third ‘Responsively Designed’ website, (for established Medical Communications agency Ashley Communications – link currently points to their soon-to-be-old website), I thought now would be an opportune time to update you on some of my findings.




It has been, and continues to be, an interesting journey.  If there’s one thing that’s for certain in this industry, it’s that it’s continually changing, and therefore you have to be continually learning.  At times this can seem scary, but to be honest, I’ve actually rather enjoyed the challenge of learning responsive design. (Or I should say, ‘am enjoying…’, I’m no-where near finished yet).




So, three discoveries so far…

 

Number 1: It’s more time intensive!

Perhaps partly down to the fact that it’s new.  But designing and building for desktop and mobile (as well as everything in between) necessarily introduces complexity and therefore requires more time.  To the point:

• Design – no longer a single design for a fixed width screen.  Rather, multiple variations of the design for various different resolutions.

 

• Build – calculations are more complex & fiddly – based on percentages, not fixed pixel widths.  It’s surprising how much maths you use as a web designer!  Consideration has to be taken for how the site will perform on mobile – for an image-heavy site, an approach has to be employed to minimise image download size on mobile, etc etc.

 

• Testing – whereas with a ‘traditional’ fixed-width design, we web-designers would be groaning over the need to test websites on multiple different browsers (and making particularly loud complaining noises when it came to Internet Explorer 6), in addition we now need to test for multiple different resolutions.

 

This is a pain, but also an opportunity.  Yes, it takes more time, but that means that each project is of higher value.  So far, clients seem prepared to pay for that additional value, but it does meant that the overall cost of getting a website is higher – if you want to treat your mobile users well.

 

Number 2: It requires creativity!

There are challenges inherent in building for a small screen size – mainly because space is so limited.  Imagine moving from a five bedroom country house to a studio flat, and having to work out where all that stuff is going to go.

If you’re a hoarder and have tonnes of stuff, the job is going to be that much harder.  My designs tend to be fairly clean and lightweight – which definitely helps, but there’s still ‘stuff’ that you have to either find room for or chuck out.




It’s a good exercise – it makes you think about what’s really necessary and of benefit to the user.  What do they need to see first?  (The 1.5 inch screen on my BlackBerry doesn’t give an awful lot of space in which to persuade the user to stay on the site.)

Menus are a good example.  For the Ashley Communications site, the menu just took up too much space on smaller screens, so we decided to display it as a dropdown from a single ‘Explore…’ link.  This makes for a far tidier user experience.

 

Number 3: There are always playoffs

Continuing with the example of menus, the approach we employed was to create two separate menus in WordPress – one for desktop and one for mobile.  This does have drawbacks – one of which is that there are two menus to maintain.  You are constantly facing these play-offs when creating a responsive design – there is no perfect solution.  In this case, because the menu is relatively simple & will be changing only infrequently, the benefits for the user outweighed the maintenance drawbacks.  In another situation, the case might be different, and another approach more suitable.




Each case has to be weighed up on its own merits, and the best fit solution applied.  And because new ideas and approaches are constantly being developed, coupled with this is the need to be continually on the lookout for the best solution, not only for this website, but for this particular moment!

 

In Summary

It’s been hard work, frustrating at times, lots of reading and learning… but it’s very satisfying too.  The mobile web is here to stay, and I’m grateful to many of the highly talented designers and developers out there who have helped me to learn.  These are certainly interesting times!!