W3C home > Mailing lists > Public > whatwg@whatwg.org > July 2009

[whatwg] autobuffer on "new Audio" objects

From: David Wilson <dw@botanicus.net>
Date: Fri, 31 Jul 2009 13:20:10 +0100
Message-ID: <98edab2e0907310520i53a882f5s6bd787aa5c8e4068@mail.gmail.com>
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.


David

-- 
Reality is that which, when you stop believing in it, doesn't go away.
  ? Philip K. Dick
Received on Friday, 31 July 2009 05:20:10 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:14 UTC