Firstly, I didn't think HN would allow ▶ in the title, so congrats on the "new Rickroll" effort. Hope it doesn't get banned tomorrow :). (Google in fact strips the fun characters from SERP titles.)

[Edit - and it's already gone in the time it took to write this]

I've been using this pattern on http://player.fm for some time now. I agree it's best to just "use the force" of the DOM and base the title symbol on the actual media element's state. Some additional points to consider:

* Another option is to also show a paused or stop state. I did that for a while using a black square character (■), but it looks ugly when people bookmark the page. The same thing happens when bookmarking pages with the play symbol, but that's rarer and at least people have a way to turn it off (ie pause the track).

* Instead of using the title, you could also use a favicon. Although I've been promoting dynamic favicons since I discovered the technique [1], I actually think title is better for this purpose. Why? It lets you retain the actual favicon, it's more portable, it's become more standard. Favicon can be good for more dynamic properties like Scott Schiller's graphic equalizer favicon demo (which I can't find now).

* It works fine with Flash if you use a Flash-compatible JS library like SoundManager or jPlayer.

* It should absolutely be a standard browser feature, but the reason it wasn't is because of the Flash runtime. It presented a black box to browsers so they couldn't actually determine if playback was happening. It's been documented in these bug [2] [3]. It's become less critical as HTML5 media has become more dominant, and I think Chrome and Adobe teams have managed the detection more feasible with Flash.

1. http://softwareas.com/dynamic-favicons

2. https://bugzilla.mozilla.org/show_bug.cgi?id=486262

3. https://code.google.com/p/chromium/issues/detail?id=3541

I've been playing around with getUserMedia today (via RecorderJS), and in Chrome, it will display a pulsating red button over the favicon whenever it is streaming the data. Pretty neat.

I'm still going to do a lot of messaging around the recording state in the page itself, though, because, I'm not actually recording the whole time that the media stream is connected - I just have it connected the whole time so that I don't need to re-request permission to record.

I use a custom JavaScript template, that loses this when the new hash URL is generated. So I used it like so...

    $('a').bind("mousemove", function(event){
            document.title = document.title.replace("\u25B6","")
            $("audio").each(function(index) {
                if(!this.paused) {
                    document.title = "\u25B6 " + document.title.replace("\u25B6 ","")
                    return false;
                }
            })
    });

This was mentioned when YouTube started doing this but some of the comments here don't seem to be aware of it.

Chrome will indicate when sound is playing right now if you add "–enable-audible-notifications" to the commandline (easier done on Windows than MacOSX) and even works for sound coming from Flash plug-ins. Of course since it requires a commandline to work, there are likely some issues associated with it (but it has worked fine for me.)

Once this feature no longer requires a commandline, this idea will still be useful for people who use other browsers.

Er, this doesn't seem to be working on herdingcode.com.

Still a great idea, though animating it (there are a few unicode music symbols you could probably cycle through) would make it even better.

Which browser? I tested w/ Chrome stable and IE11, but I'm surprised if it doesn't work in any modern browser.

For me, the audio player is largely broken until every asset on the page has loaded. If you press play before all those facebook buttons do their thing, then the page reloads. I am running the latest chrome stable.

The audio player appears almost immediately, but doesn't actually work correctly for ~15 seconds.

If audio detection is based on the <audio> tag, the browser is in a much better position to build a solution, since it would instantly work on all HTML5 audio websites and not be constrained to only using the browser title. Regardless, this is a awesome, simple solution for now.

Is it ironic that this article is misusing the very pattern it's trying to promote? If placing ▶ in the title is supposed to signal that audio is playing, then maybe it shouldn't be used by pages that aren't playing any audio...

Why isn't there a browser with a mute button on every tab?

I seem to remember reading something about how this was coming down the line for Chrome.

Yep, I linked to that at the end of the post. It's been in Chrome Canary for a long time but hasn't made it into stable.

How does this impact screen readers?