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

[whatwg] autobuffer on "new Audio" objects

From: Nils Dagsson Moskopp <nils-dagsson-moskopp@dieweltistgarnichtso.net>
Date: Wed, 12 Aug 2009 02:12:30 +0200
Message-ID: <1250035950.4330.144.camel@desudesudesu>
Am Mittwoch, den 12.08.2009, 00:05 +0000 schrieb Ian Hickson:
> On Fri, 31 Jul 2009, Nils Dagsson Moskopp wrote:
> > Am Freitag, den 31.07.2009, 00:26 +0000 schrieb Ian Hickson:
> > > 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.
> > 
> > I was referring to exactly that. Creating an <audio> element for every 
> > audible file in a directory isn't something one would necessarily do on 
> > the server side.
> > 
> > But as long as there is a possibility to not trigger buffering when 
> > creating media objects, all may be well.
> 
> The idea of the attribute is to ensure the UA has the final say on this 
> stuff, rather than having scripts that force buffering by seeking to a 
> bunch of places in the file or something equally asinine.

Oh, now I get the similarity to the autoplay attribute. No further
questions, your honor and thanks for taking your time to explain this.


Cheers
-- 
Nils Dagsson Moskopp
<http://dieweltistgarnichtso.net>
Received on Tuesday, 11 August 2009 17:12:30 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:08:51 UTC