Huffduffer is written in HTML5. For the most part, this is no different to writing in any other flavour of HTML, just with a simpler
For the time being, I’m not using any of the new structural elements like
footer. I am, however, making use of the
audio element. Browsers that don’t understand this element—that would be most of them—aren’t left with nothing. Between the opening and closing
audio tags, I’ve included an old-fashioned Flash movie for streaming the audio. This is exactly what is envisioned in the spec:
Content may be provided inside the
audio element. User agents should not show this content to the user; it is intended for older Web browsers which do not support
audio, so that legacy audio plugins can be tried.
Right now, Safari is about the only browser that includes support for
audio. Alas, the way it implements that support is flawed. Safari pre-loads the file referenced in the
src attribute. That works fine as long as there’s only one or two
audio elements on a page but as soon as you get above that—as you do on Huffduffer—then everything starts to drag and your internet connection takes a hammering as the browser tries to suck down every file.
…but none of them can be used to instruct the browser not to pre-load audio (as far as I can tell). After trying to read the spec I’m still not sure if Safari is implementing the “correct” behaviour. It might well be. But in this case, the correct behaviour is certainly not the desired behaviour. I downloaded the nightly build of Webkit and the behaviour hasn’t changed there.
Support for the
audio element is on its way in Firefox 3.1, albeit in a crippled Ogg-only way. I sincerely hope it doesn’t follow Safari’s precedent with pre-loading.