I hate supporting old versions of Internet Explorer as much as the next person, but Iâ€™ve learned a lot while doing it. The problem I run into now is being able to convince the stakeholders for a project to accept that websites do not need to look (and act!) the same in every browser. I work for a company whose standard browser is IE8. Weâ€™re in the process of transitioning over to Chrome, but weâ€™ve been in that process for months and months. Eventually, itâ€™ll happen. But itâ€™s very difficult right now to convince a stakeholder that Iâ€™d like to make this site for them, but in IE8 it wonâ€™t function the same as it will in Chrome.
Right now weâ€™re working on making a very simple podcast player for people to primarily use on their mobile devices on the go. The premise is very simple: itâ€™s one podcast, and new episodes appear bimonthly. It just started, so right now there are only four episodes. The layout is basic: thereâ€™s a audio player, a list of all episodes, and an RSS link that one can use to download and play episodes in a podcast app instead of using the website. Now, immediately I wanted to use native HTML5 audio. Thatâ€™s great, but of course the company standard doesnâ€™t support HTML5 audio. Now, I could provide a Flash fallback (and thatâ€™s currently what weâ€™re doing), but ideally Iâ€™d want to not rely on a plugin and instead use progressive enhancement here.
A proposed progressive enhancement approach
Letâ€™s start from the bottom up.
It could happen. I believe in having clean markup and a separation of concerns, so the HTML should be as concise and semantic as possible. Thereâ€™s the logo and title at the top, in an
h1. Then, an
audio tag with a fallback message. After that, an
ol with the list of podcast episodes, containing the title and a link to download the mp3. At the bottom is a link to subscribe to the RSS. With only HTML, this page still works. Users canâ€™t stream the podcast, but they can still download the episodes and play them on their computer.
<h1> <img src="logo.png" alt="A Descriptive Alt Tag for the Logo" /> The Name of the Podcast Player</h1> <audio controls> <source src="episode2.mp3" type="audio/mpeg" /> <source src="episode2.ogg" type="audio/ogg" /> <p>Sorry, your browser does not support HTML5 audio. Please download the episodes below.</p> </audio> <ol> <li><a href="episode2.mp3">Episode 2</a></li> <li><a href="episode1.mp3">Episode 1</a></li> </ol> <a href="thissite.com/rss">Subscribe to the RSS feed</a>
Similar to the previous, except this time thereâ€™s some styling to the site. With no support for HTML5 audio, the message stays the same. And with no Flash fallback, users still get the option to download whichever episodes they choose.
Well, arenâ€™t we lucky. With a modern browser, we can actually listen to the most recent episode since it is conveniently placed in the
source element for the audio. This means the user can stream the most recent episode. Now, they wonâ€™t be able to choose any other episodes to stream on the page, but they can either choose to download older episodes or open them in a new tab/window in their browser and stream them there.
audio tag and create a custom audio player interface to match the siteâ€™s style. Plus, users will now be able to click on any episode in the list to have that start playing in our audio player. Weâ€™ll even add specific download buttons for people that just want to download the MP3s to their device instead of streaming on the page.
If Only It Were That Simple
As I mentioned above, this is the ideal situation. Itâ€™s very hard to convince stakeholders that you donâ€™t think the site should use Flash and therefore people using the current company-standard browser wonâ€™t be able to stream the podcast on the page. After all, they can go to Youtube or Soundcloud and watch videos and listen to podcasts in IE8 no problem.