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 DOCTYPE.
For the time being, I’m not using any of the new structural elements like section, article or 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
audioelement. User agents should not show this content to the user; it is intended for older Web browsers which do not supportaudio, 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.
There appears to be no way of stopping this through the DOM. There’s a whole slew of properties that can be specified in the markup or manipulated with JavaScript:
- autoplay
- start
- loopstart
- loopend
- end
- playcount
- controls
…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.