24 comments

[ 2.8 ms ] story [ 69.9 ms ] thread
Nice and lightweight. I'll give it a try on my site when I find the extra time ;)
Can I suggest that the IDs be something a bit less generic if you're going to hardcode them? People might already have 'next' and 'prev' as IDs for other things. (Not that they'd be in the right, either.)
Totally valid. I'll change that and push it on the next nightly. Thanks!
Only 2 things missing, Turbo Bass button and a "This is not a toy" warning label.
>Get a modern browser

>First things first—make sure you’re running a modern browser. My favorite is Chrome but Safari will also do. This app currently only supports webkit. More browsers coming soon.

What is Opera or IE9 then? Chopped liver? Am I the only one hating this new version of "Best viewed with IE5" and browser specific tag soup whose behavior changes even with the versions of the specified browsers?

What else is the author supposed to do? HTML5 is still in its infancy and browser support varies quite a bit. I have written several HTML5 experiments that work in some browsers and not in others (most notably for me is Chrome and Firefox support the FileReader API while Safari does not), there isn't much else that can be done at this point.
I haven't done research into which (if any) html5 audio formats that IE9 supports. I fully plan to add feature detection to serve the correct audio format to the correct browser—IE9 included.
This is now working in ALL modern browsers: Firefox Chrome Safari (OSX/iOS) Opera and yes IE9 :-]
Geez. What's up with the "write 20 lines of trivial javascript, put it on github, put more effort into making a webpage than the actual code, post it on HN".
I don't mind that it's trivial if it saves me from doing some tedious stuff, but after reading the code it's unusable the way it's written right now.

Some of the things that need to change are:

1) DOM selectors must be defined by user, not the plugin itself.

2) Needs to actually work on more than just Webkit based browsers.

3) Don't use $(document).ready() in the plugin, find another way or design the API differently.

Can you elaborate why $(document).ready() should not be used?
It's a matter of best practices.

In particular how it's done in this code, where it's outside the definition of the plugin and binding events.

Plugins should be built in a way where it is explicitly invoked by the programmers using them, and the 'proper' way is to invoke them from within a $(document).ready() function that is specified by the user in the order that the user wants.

Lets pretend, for example, that this plugin is invoked from within another $(document).ready(), in which case the document.ready call from within the plugin is completely redundant and useless.

Your points are all valid and I'll consider each one in refactoring the code. Thanks!
I love how this works on the iphone!
How is this superior to jplayer (http://www.jplayer.org/) ? Jplayer is implemented in HTML5, but has a fall-back flash implementation for backwards compatibility, and like this is open-source (GPL/MIT).
I wasn't aware of this project. Thanks for bringing it to my attention.

Boombox.js has more features in the works. Please check back later for updates. Thanks!

I think it's awesome, thanks! I found it really easy to incorporate.
This is a good start, but it needs some significant additional features. If it's gonna work in jQuery, it needs more control, specifically JS control. It would be nice to do anything I can do from the buttons from JS, and possibly more. Also playlist support would be nice.

I'll give you a scenario, if I have this autoplaying on a website, and I have an embeded Vimeo video, I'm gonna want to automatically stop the music when a user starts playing the video.