[whatwg] autobuffer on "new Audio" objects
ian at hixie.ch
Thu Jul 30 17:26:03 PDT 2009
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
> 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
> who can afford more bandwith on an order of magnitude (!).
This doesn't apply to elements on the page, only to script-created
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg