[whatwg] autobuffer on "new Audio" objects

[Ian Hickson]

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 don't think the intent of creating Audio instances clearly always
> means playback will happen.

What other use cases do you have in mind?


> 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.


On Mon, 20 Jul 2009, Nils Dagsson Moskopp wrote:
> 
> I second that motion, not only as owner of a smartphone, but also as
> someone with webspace that has a volume cap. Automagic audio element
> buffering could deter web authors from dynamically putting more than one
> element on a page, thus reserving javascript playlist widgets to those
> who can afford more bandwith on an order of magnitude (!).

This doesn't apply to elements on the page, only to script-created 
elements.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'