So, I am slightly obsessive compulsive.
I worked a little more tonight on this jAUs thing to add support for start and stop time attributes in the HTML5 <audio> tag.
Video should work, too, with a little work, but I don't care about that right now.
What I did tonight was make it so that if a "stopTime" attribute is used, then after that point is reached the player will move the scrubber back to the original "startTime" value though at that point the playback is already paused.
If there is no "stopTime" attribute, then after the file's played itself to the end, the scrubber will move back to the "startTime" value. Again, playback is already paused at that point.
I've tested this with Firefox 9.01, Internet Explorer 9, Safari 4.0.5, Opera 11.60, and Chrome 16.0.912.75 on my Windows 7 (32-bit) laptop.
Running everything from my desktop, I had no problems except that I should mention that if I used the "autoplay" attribute and set it to "true", Chrome didn't start the playback as it should, but it seems that maybe that's a Chrome problem that others are having, too.
Testing with the files uploaded to my hosted account was a different story. Opera seemed to need a page refresh before the scrubber would locate itself at the proper positions – though adding a pesky alert() at the beginning seemed to make Opera happy. Chrome and Safari seemed to take a few seconds to get situated, although they seemed to generally need a restart to move the scrubber to the right place for the last audio player. I didn't test the alert() thing for these two. Firefox did well although I hate the way Firefox moves the audio players around depending on whether the audio has been played or not. And that leaves IE9 … which, hands down, did the best. Maybe that's because of the exception I'd added for it as I mentioned in an earlier post.
So, there's still work to do and things to investigate.
Also, I haven't tested this with really long files or anything so I don't know how that would go. But then again, as I've heard others say, HTML5 media elements aren't really for long-form media anyway.
Oh yeah, one more thing. I did in fact change to "data-startTime" and "data-stopTime" to make the HTML legal HTML5.
And, yes, I care much more about the name/acronym than the script itself.
Update, January 15, 2012: OK, this is interesting. If, for the source of the audio file, I actually use the audio files on the Archive.org site for the LibriVox recordings like so …
<audio class="jAUs" controls data-startTime="10" data-stopTime="13"> <source src="http://www.archive.org/download/sonnet_130_librivox/sonnet130_shakespeare_njm_64kb.mp3" type="audio/mp3" /> <source src="http://www.archive.org/download/sonnet_130_librivox/sonnet130_shakespeare_njm.ogg" type="audio/ogg" /> Your browser does not support the audio element. </audio>
… then this seems to be working OK in all the browsers. Chrome seems, per casual observation, the slowest in terms of getting the scrubber moved to the appropriate points, but I guess this is progress.
Related to all this stuff I've been messing with, I found this: Consistent event firing with HTML5 video – Dev.Opera. But here, too, they use an alert() to notify the user that metadata is loaded using "onloadedmetadata", but in my tests it seems like the alert() function itself was what was fixing the inability of some browsers to set the current time as my script was instructing.--------------