- From: Philip Jägenstedt <philipj@opera.com>
- Date: Mon, 20 Jul 2009 10:08:05 +0200
On Mon, 20 Jul 2009 07:06:32 +0200, Nils Dagsson Moskopp <nils-dagsson-moskopp at dieweltistgarnichtso.net> wrote: > Am Montag, den 20.07.2009, 05:46 +0100 schrieb David Wilson: >> 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). > > 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 (!). > > I believe the burden of writing another line should solely be on those > who want autobuffering, to prevent unneccessary bandwith consumption. > > Cheers Regardless of whether the spec mandates that the autobuffering attribute be set for new Audio(), browsers that want to be competitive on mobile will have to be conservative with bandwidth. autobuffering is only a hint and doesn't need to be obeyed where it doesn't make sense (in fact can't be obeyed because the disk cache is too small). -- Philip J?genstedt Core Developer Opera Software
Received on Monday, 20 July 2009 01:08:05 UTC