Flash and HTML layers: still a problem

Posted: January 7th, 2009 | Author: msh | Filed under: The Craft | Tags: bugs, design, flash, informationarchitecture, jquery | 2 Comments »

Update, April 2009: Change.gov seems to have changed their video player size, so the working example in this entry no longer has a strict correlation between the video player and the image replacement.  The principle still holds, though, and it would be an easy fix to create a new replacement image using the naming conventions below. — msh

Happy 2009!  OK, back to work.

Note to developers and designers: you still can’t layer HTML over Flash, and you still need to design around it.  Sad, but true.  For instance, this page on change.gov has the classic problem: a Flash video player at the top of the page, and a menu that draws a layer on rollover.  The two are not friends.

In its natural state:

On mouse over — whoops!  The video’s “play” icon shows through the menu:

It’s a problem on standards-compliant browsers and elsewhere.  There are two ways around it: hide the Flash player when the menu layer appears, or design around it.  We recommend the latter, as it enables you to avoid hacks or sleight-of-hand.

If you need the video right there, though, you’ll have to figure out a better way.  And if you have to resort to trickery, you might as well entertain yourself.

Fixing change.gov’s problem

This page uses the uber-popular Media Player from Jeroen Wijering, which unlike the QuickTime player is fairly scriptable.  But instead of making any calls on the Flash player or its helper scripts, we’re just going to destroy it entirely.

The goal is to replace the video player with some kind of flat HTML whenever the mouse is over the menu.  Then we can guarantee that the menu layers will always layer properly over boring HTML elements instead of being invaded by underlying Flash goobers.  When the mouse leaves the menu, we can restore the original video player.

You’ll need two main entities: a listener, to respond to the menu rollover event; and a Flash player handler, to hide and show (or destroy and re-create) the player.  Luckily, change.gov already has the former; it’s in this JavaScript file.  Our modified version, available here, has two additional method calls at lines 95 and 106.  These refer to a nav handler object defined in this additional JS file.

I made one substantial change to change.gov’s original HTML: I gave a class of “wrapper-video” to the div that contains the video player.  The nav handler will work on the assumption that every video player that might be affected is classed with “wrapper-video”.

When the handler’s setOver() method is invoked, it loops through “wrapper-video” divs.  For each div, it caches the original HTML and the calculated width and height.  Next, it sets the div’s background to an image: in this case, an exact still of the video player.  E.g.:

Looks convincing.  The image file name contains the dimensions, and setOver() takes advantage of this by constructing the file name dynamically.  This way, if you had more than one video player size, you’d be covered.  For good measure, we also explicitly set the div’s width and height, so it doesn’t collapse when we erase its contents.

Once all of this is done, we call jQuery.html(”") on the div, erasing its contents.  Now it just shows the background image, and will play nicely with the menu layers.

When the mouse leaves the menu area, navHandler.setOut() restores the original HTML contents of each video wrapper div.

You can see a working example here.

The files are also available for downoad as a ZIP.

The better solution clearly would be to design around this issue, but all too often we don’t have a lot of choice.  If video is the featured page content, there’s rarely a good way to push it safely towards the fold.

(Caveats: browser testing, your mileage may vary, etc.)

---