[whatwg] autobuffer on "new Audio" objects

David Wilson dw at botanicus.net
Fri Jul 31 05:20:10 PDT 2009

2009/7/31 Ian Hickson <ian at hixie.ch>:
> On Mon, 20 Jul 2009, David Wilson wrote:
>> 2009/7/19 Ian Hickson <ian at hixie.ch>:
>> > On Mon, 6 Jul 2009, Robert O'Callahan wrote:
>> >>
>> >> When script creates an audio element using the "new Audio" constructor,
>> >> the 'autobuffer' attribute should be automatically set on that element.
>> >> Presumably scripts will only create audio elements that they actually
>> >> intend to play.
>> >
>> > Done.
>> This seems like surprising behaviour (and a nasty asymmetry between
>> markup and JS): for the savings of a single line of code, creating a
>> new element will automatically result in (high bandwidth) network IO.
> Only if the user agent honours the autobuffer attribute. It doesn't have
> to.

I still don't understand the 'why' of this, whereas the 'why not'
seems clear. It might be useful (in a "saving an extra line of code"
kind of way), but the fact it implicitly causes potentially high
bandwidth IO seems more wasteful than convenient.

What about adding an autobuffer parameter to the constructor which
defaults to false?

>> I don't think the intent of creating Audio instances clearly always
>> means playback will happen.
> What other use cases do you have in mind?

The playlist example given doesn't seem that unreasonable, it's
something an unsuspecting developer might do in a hurry.

It's a good idea to make types as general as possible, particularly
for browsers where libraries like jQuery make it convenient to treat
DOM nodes as data structures. Forcing a user to type extra
("document.createElement('audio')") in order to avoid surprising
functionality doesn't seem right.

>> It's easy to see how some naively implemented JS audio widget could
>> fetch 200mb over an expensive 3G connection, simply by navigating to
>> some site in a background tab (say, by creating an array of elements to
>> represent their playlist - something I'd have thought was perfectly
>> valid behaviour).
> A mobile phone would not autobuffer in a background tab

3G doesn't mean mobile phone. I barely use my phone's browser, but use
net via Bluetooth all the time, various Dell laptops come with 3G
available as an option built in, for many in Africa its the only
available network, etc.


Reality is that which, when you stop believing in it, doesn't go away.
  — Philip K. Dick

More information about the whatwg mailing list