Subscribe to my space and sci-fi newsletter

When you sign up for my newsletter, you'll get a free sci-fi short story: Starfarer, monthly updates on space science and sci-fi, and updates on my writing projects!

    I won't send you spam or share your email with anyone. Unsubscribe at any time.


    Popular blog posts

  • Total Share: Personal Computer Market Share 1975-2010
  • Celebration
  • Monarch Thing-A-Day Challenge!
  • I love Korean Starcraft
  • Why HTML 5 sucks!
  • Recent forum posts

  • Micro History Episode 2 is up!
  • My article on the history of public messaging is up on Ars Technica!
  • Micro History Episode 0 is up!
  • How to find the best fiction ghostwriter?
  • Jeremyreimer.com is live on a new server!
  • Discussion Forum

    Discussion forum

    Why HTML 5 sucks!


    Post #: 81
    Post type: Blog post
    Date: 2011-03-11 16:29:26.000
    Author: Jeremy Reimer
    Tags: Software

    The idea behind HTML 5 was a good one: make sound and video clips a part of standard HTML code that anyone can use on any platform without having to use Adobe’s proprietary Flash plug-in. Great! Long overdue, in my opinion.

    Then, sadly, everything went wrong.

    I already knew that the video tag in HTML 5 was a complete train-wreck. Some browser manufacturers had decided to support H.264, others Ogg Theora, and then Google came along and started pushing WebM. But that’s video, something where new codecs are still being created and the state of the art is still very much in flux. I could forgive things for not being all sorted out.

    Audio, I thought, would be trivial. So when it came time to include a podcast playback control in my Monarch blog engine (you’re reading through it right now!) I decided to test out HTML 5’s audio support to see how well it would work.

    The answer is worse than not at all.

    Internet Explorer 8, of course, ignores the tag and displays nothing, but that’s forgivable because honestly, who uses IE any more? Only dinosaurs and old people who really like things to be extra-slow. IE9 will supposedly support it, assuming the sun hasn’t become a red giant and consumed all life on Earth by the time it is released.

    Firefox, on the other hand, commits an even more unforgivable sin: it CLAIMS to support it, but then won’t play MP3 files! Ogg Vorbis only! Look, Mozilla people, I understand this Noble Crusade For No Patents in Codecs, but MP3 is supported by every other sound playback system in the entire history of time. Five dollar portable music players support it. I think my breakfast cereal supports it. This is ridiculous!

    Now, we get to Chrome. Great browser, Chrome. Supports HTML 5 audio tags and plays back MP3s. Great, right?

    Yeah, until you put more than one on a single page. Then it tries to play them all at once, ignoring the autoplay settings, and freezes the entire web page. (EDIT: It's worse than that, actually. It freezes the ENTIRE BROWSER! Not even sandboxing can save it!) Great, Chrome. Nice job.

    I downloaded a Flash audio player (the same one that the audio module in my old blog running Drupal used) and everything ran fine. Multiple instances, no problem. Runs on every browser, too, except the iPhone/iPad, which don’t support Flash.

    The idea of replacing Flash is a good one. It was neat seeing the Knotty Geeks podcasts load up on my iPad in a web page and being able to play them. But freezing Chrome and not working on Firefox is a complete deal-breaker, and this doesn’t show any signs of improving any time soon.

    Flash is here to stay for the time being, folks.


    OscarWilde on 2011-03-12 17:28:01.000

    What about Safari? Where did Safari sit in your audio tests? Did it play all of the audio at once as well?

    Jeremy Reimer on 2011-03-13 23:24:33.000

    Safari worked perfectly with everything, both on my Mac and my iPhone/iPad.

    Which just makes the tragedy on other browsers even more shameful and unfortunate.

    OscarWilde on 2011-03-14 23:09:33.000

    Really? I did not expect that. I assumed if anything Safari and Chrome would be equal since both are based on WebKit. Unless I'm mistaken...

    /rushes to do quick wikisearch...

    Yeah, I was right. Interesting. Why would two WebKit browsers work differently?

    Jeremy Reimer on 2011-03-17 00:14:38.000

    It's because the part of Safari that actually renders the audio player controls is the part of Safari that isn't Webkit. The actual display of the controls is handled by the browser itself, which sets up the graphics for the control, then plays back the file.

    In Safari's case, it embeds a QuickTime control, which it can totally do since you have to install QuickTime in order to install Safari on Windows (and of course QT is already there on the Mac)

    For Chrome, it renders its own controls and plays the music file using its own UI code.

    IE9 probably embeds Windows Media Player, etc.

    Riso on 2011-03-27 07:54:33.000

    In my opinion the browsers should use the available system codecs to play videos and if you lack the codec throw an error and tell you what you need.

    There's no reason why the browsers themselves should ship with codecs.

    View this post in the forums

    Views: 20893