If you have a page and an iframe in it, and the iframe viewport height changes, browser adds scrollbars to the iframe.
Sometimes it’s ok, but when you need your iframe to “expand” automatically on the host page, you have to change the iframe object height style property. And it’s dead easy when both iframe and the host page are from same origin – you just talk to parent window from the iframe and make it set the object height.
So the proper approach would be to use CDM with a fallback to location.hash – newer browsers (IE8+ and current Firefox, Opera, Safari and Chrome) support postMessage, older versions will fall back to setting parent page location.hash property and on the parent page – interval polling for changes.
Here’s a basic working sample implementing this approach and here’s the code for it:
Please note that in this sample no origin check is done for the message on the parent page and the message is sent from the client page to * origin. This might be a serious security breach since the parent page will process a message send from any page, but in my case it’s OK because the worst thing that can happen – the iframe height will change. Please don’t use this as a universal solution for cross-iframe communication – there’re plenty of plugins and libraries that do it properly. I built it this way just to fit my exact needs – i.e. change height of the iframe object on a parent page.
It’s interesting to see how popular
<audio> tags are getting now. Every browser tries to implement it as soon as it can and shout about it as loud as possible. And now people are even starting blaming IE for being old and not supporting inline video and audio.
The whole situation reminds me of AJAX where original concept was invented by Microsoft (actual ActiveX was shipped with IE5 in 1999), then it was standardised by W3C (in a different way), then implemented by other browsers, and then people started accusing IE for not supporting this new W3C standard.
The same thing is now happening with inline video/audio playback concept, which has been introduced in IE2 in 1995, almost 15 years ago. Yes, 15 years ago, when W3C has been just founded and was still asking MIT/CSAIL to join. And now this functionality is being spec’ed in HTML5 as
<audio> tags. Opera, Firefox, Safari and Google Chrome start supporting <video> and <audio> and are making a loud marketing message of it.
The original concept that was introduced in IE2 (and supported in following versions) was adding a
DYNSRC attribute to
<img src="cover.gif" dynsrc="clock.avi" controls>
When IE saw dynsrc attribute, it tried loading the movie and playing it. “Controls” attribute made IE show simple playback controls.
This is how it looked like in IE3:
However, in future versions the support for DYNSRC was limited to make developers to switch to other ways (
<embed>/SMIL video). In IE5 no controls were shown, in IE7
DYNSRC ceased at all.
World changes, and now the functionality that nobody’s been using for a decade seems really new and interesting. It’s great that WHATWG is spending time on defining clear standard on how this should work and it’s really cool that Chrome, Firefox, Opera and Safari already support this draft. Of course, Silverlight supports greater level of RIA, but giving that IE Team is now really focused on following public standards, I hope that in IE9 we’ll have native support for
<audio> as we had native support for XMLHttpRequest in IE7.
But my point is – credit for inline video playback functionality invention should be definitely given to IE2.