On Mon, 20 Jul 2009 07:06:32 +0200, Nils Dagsson Moskopp
<nils-dagsson-mosk...@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
