On Apr 10, 2013, at 12:14 PM, Wesley Johnston wrote:
> Again, IMO 1.) The EVENTUAL default behavior here has to be to mute tabs in
> the background.
I disagree. The current default behavior (allowing to play in the
background) is working just fine for Safari. Maybe it isn't for Gecko, but
> No, plugins are not a bikeshed at all. They are part of the problem - in
> fact, I wouldn't be surprised if they're half the problem.
Yes, but I don't think they're solvable here, and its not worth holding up the
entire idea trying to fix them. The best solution I know of for plugins is
clic
No, plugins are not a bikeshed at all. They are part of the problem - in
fact, I wouldn't be surprised if they're half the problem (i.e. just as
many plugins playing audio as / elements). Bikeshedding
would be arguing over whether it should be named background or lowpriority.
"Web Audio is doabl
On Mar 15, 2013, at 10:57 AM, Wesley Johnston wrote:
> In most situations, when the user puts a webpage in the background, any media
> being played by the page should be paused. Any attempts to play audio by a
> background page should also be prevented. However, for some sites (music or
> rad
Browsers can already implement this - Chrome did, in fact. I don't think
it would be part of the spec.
Changing the default behavior of media elements today seems problematic;
all current elements, under this proposal, would start pausing when
you switched away from the tab. Additionally, this
On 4/10/13 2:12 AM, Simon Pieters wrote:
I'm not aware of such a list.
We should solve this problem. At this point we have some interface and
prototype objects that should only appear on Window, some that should
only appear in Workers and some that should appear both places I
wonder wh
