HTML and CSS Reference
In-Depth Information
Our previous example can be rewritten as:
<audio src=”hanson.mp3”>
<p>If you can read this, you can't enjoy the soothing
¬ sound of the Hansons.</p>
</audio>
<script>
function audioloaded() {
// setup the fancy-pants player
}
var audio = document.getElementsByTagName('audio')[0];
if (audio.readyState > 0) {
audioloaded.call(audio);
} else {
audio.addEventListener('loadedmetadata', audioloaded,
¬ false);
}
</script>
This way our code can sit nicely at the bottom of our document,
and if JavaScript is disabled, the audio is still available. All good
in my book.
Will this race condition ever be fixed?
Te c h n i c a l l y I c a n u n d e r s t a n d t h a t t h i s i s s u e h a s a l w a y s e x i s t e d
in the browser. Think of an image element: if the load event fires
before you can attach your load event handler, then nothing is
going to happen. You might see this if an image is cached and
loads too quickly, or perhaps when you're working in a develop-
ment environment and the delivery speed is like Superman on
crack—the event doesn't fire.
Images don't have ready states, but they do have a
complete
property. When the image is being loaded, complete is false.
Once the image is done loading (note this could also result in it
failing to load due to some error), the complete property is true.
So you could, before binding the load event, test the complete
property, and if it's true, fire the load event handler manually.
Since this logic has existed for a long time for images, I would
expect that this same logic is being applied to the media ele-
ment, and by that same reasoning, technically this isn't a bug,
as buggy as it may appear to you and me!
