Recently I've been working a lot with mediaelement.js, much more than I'd hoped to have to have done with a module that promises so much.

The biggest issue I faced was changing the video src in the Flash fallback player as when you change the source the new video isn't loaded until it is played. I've cursed this player for a whole day, but I can't rule out that the Flash implementation is to blame.

Possible workarounds were to have the videos autoplay or to replace the fallback whenever the src was changed. The final workaround was to change the source, call play, and then pause the video after a timeout so the user doesn't see it playing. And that works, but it relies upon a timeout that is unconnected to anything happening in the page.

Fortunately there are events raised by the HTML5 player and the fallback that we can use to bind onto to improve the flow of our somewhat shitty workaround.

(You might wonder why these events couldn't solve our setSrc problem anyway, but as the video isn't loaded at all until play is called, not even when .load() is called, then they're a red herring)

     //watch for the canplay event, bound above the video element. At this point the video is in a play state
     videoContainer.on('canplay', function (event, mediaElement) {
          //paused the video
          mediaElement.pause();
     });

In my full code it's a little more complex, as sometimes we actually want it to play, but that is the basic hook.

Update: Firefox is firing the canplay event in some situations as the events true purpose is to track when there is enough of a video for it to play. Our workaround is only required for the fallback, so we can add the canplay event to that only.

Web development is a weird specialty. There are reams of excellent articles and references by writers often evangelical about how the web should be built, from the tools you use, through the way you code it to the servers it's sits on.

There can be no profession more open than web development, literally everything you need to know is out in the open

But (and there is always a but) this work comes at a price. The bean-counters and bosses need to believe that what we're doing has benefits outside of giving us a warm fuzzy glow. So we gave them terms that neatly packaged up bits of best practice with handy benefits. The problem is that these terms got adopted and resold as solutions, here are some examples;

Agile

Agile software development is a beautifully collaborative process, ruined by poor understanding of what it is.

To many people Agile is like Waterfall, but with things running in parallel and where changes can be made throughout. They also conveniently misses out all the iteration and packages of functionality that give us the flexibility.

Agile has stopped being useful as a term because there are too many people who use it incorrectly. What they mean is agile with a lower case 'a', they mean that you're going to be jumping around avoiding bullets.

Responsive / Adaptive

Responsive design can save you money and make you irresistible to the opposite sex. We could have packaged this term with Viagra but given the boners that the industry now has for this it wouldn't be necessary.

I have a huge about of faith in these three areas, but unfortunately the term responsive has gone rogue and has gained a duel meaning.

To us a responsive layout flexes with the size of the screen through which is it s presented. Adaptive is similar but is controlled more through breakpoints. By adapting to the viewport we can improve the user experience on smaller screens.

To the rest of the world responsive and adaptive are the same. Both mean that we can tailor the mobile and tablet experience of the website, saving money on creating specific sites for those device types.

At first glance that seems fine, but the key word is tailor. It implies a level of control that whilst possible can be labour intensive and sometimes not what the technology was designed for.

Responsive and adaptive layouts should not have icons positioned in space that require breakpoints to position them.

Mobile first

Doesn't mean that you make your desktop site look like your mobile. Google it, there is some hilarity out there on this one.

HTML5

The king of all recent terms, meaning completely different things to the business and to the developers. HTML5 is both the extra syntactic markup and a group of technologies promising to kill Flash and tell you when someone looking at a billboard.

At least it let us sneak in progressive enhancement. Somehow that never caught on.

Session and local storage have made the storage of data on a clients machine respectable, gone are the big cookies and window.name, partnered with the ability to define manifest files developers can now exert control over how resources and data are cached to a level that makes Apache and IIS look embarrassing.

However, with every new feature, some things get easier and some things get harder.

Session storage is held only in a particular tab or window, allocated to the domain and lasting as long as that window persists. Opening the same domain in another tab will create a new session. Local storage is also allocated to a domain but persists between sessions, tabs and windows.

Web storage does not cater for different users, domains and windows are all it knows.

There are additional complications if users on your site are able to login, if your web storage includes data individual to the user you need to take care to clear and refresh data whenever the state changes

How to maintain state between web storage and server sessions

It might be a bit old-school, but Cookies are still the way that most back-end systems track user sessions. The simplest thing to do is to store the value of the session cookie in your web storage and to compare those values when the page loads and if the values differ clear the session of user specific data.

	sLocalKey = 'StoredIdentity',
	sCookieKey = 'CookieKey',
	storedIdent = window.localStorage.getItem(sLocalKey);
	sCookieValue = readCookie(CookieKey);

	if (sCookieValue === storedIdent) {
		return true; //same cookie value
	}
	else {
		return sCookieValue; //different value, new session
	}

Another case to watch for is a login/logout events, it's unlikely the cookie value will change (the session existed before login) but either you can watch for a query-string value or particular pages like login/logout success.