By: Mat Marquis on May 15, 2012 at 01:44PM

Responsible responsive design demands responsive images—images whose dimensions and file size suit the viewport and bandwidth of the receiving device. As HTML provides no standard element to achieve this purpose, serving responsive images has meant using JavaScript trickery, and accepting that your solution will fail for some users.

Then a few months ago, in response to an article here, a W3C Responsive Images Community Group formed—and proposed a simple-to-understand HTML picture element capable of serving responsive images. The group even delivered picture functionality to older browsers via two polyfills: namely, Scott Jehl’s Picturefill and Abban Dunne’s jQuery Picture. The WHATWG has responded by ignoring the community’s work on the picture element, and proposing a more complicated img set element.

Which proposed standard is better, and for whom? Which will win? And what can you do to help avert an “us versus them” crisis that could hurt end-users and turn developers off to the standards process? ALA’s own Mat Marquis explains the ins and outs of responsive images and web standards at the turning point.

By: Jason Kottke on April 25, 2012 at 02:30PM

From PBS Off Book, a quick look at the thinking behind the opening titles for TV shows and movies, including Zombieland, Mad Men, and Se7en.

See also Art of the Title and A Brief History of Title Design. (via devour)

Tags: design   movies   video

By: Jason Kottke on May 14, 2012 at 02:34PM

From Steven Heller and Veronique Vienne, a book about 100 Ideas that Changed Graphic Design. Maria Popova has a preview at The Atlantic.

From how rub-on lettering democratized design by fueling the DIY movement and engaging people who knew nothing about typography to how the concept of the “teenager” was invented after World War II as a new market for advertisers, many of the ideas are mother-of-invention parables. Together, they converge into a cohesive meditation on the fundamental mechanism of graphic design — to draw a narrative with a point of view, and then construct that narrative through the design process and experience.

Tags: books   design   Maria Popova   Steven Heller   Veronique Vienne

By: (author unknown) on May 11, 2012 at 12:10PM

There are sound effects libraries that cost more than a small car, and they’re probably worth it to certain kinds of users — like movie studios or audio production houses — but not to me. In search of interesting, appropriately licensed sounds for personal amusement, some google searching led me to Freesound.org, which has many thousands of freely usable, user-contributed sound recordings, all Creative Commons licensed. Some of them are tiny snippets, the audio equivalent of the icons on a computer screen, and some are lengthy field recordings. (Many of the sounds here are purely synthetic, too, or remixes that the CC licensing facilitates.) Last Halloween, I set up a playlist for my family’s “haunted condo,” consisting of screams, clanks, and creepy laughter (but also repurposed sounds like foghorns and musical instruments I thought sounded ominious), with sounds drawn entirely from this site.

It’s also a good place to find ring-tone and computer alert sources, if you’re just looking for audio clip art, or (with headphones, especially) fascinating “you are there” audio experiences; being transported to an audio landscape inhabited by gentle waves, ships’ horns, and thunderstorms is a legal way to escape ordinary consciousness.

Freesound really is free, too, though donations are accepted; it started as a project of the Music Technology Group of the Universitat Pompeu Fabra. One (very small) catch: you can listen all you want just by visiting the site; downloading the files requires free registration.

— Timothy Lord

Freesound
http://www.freesound.org/
Free

By: Nathan Yau on May 09, 2012 at 01:25PM

Thanks to the Internet Archive and CNN, thirteen years of transcripts, about a gigabyte compressed, is available to download as one file.

For over a decade, CNN (Cable News Network) has been providing transcripts of shows, events and newscasts from its broadcasts. The archive has been maintained and the text transcripts have been dependably available at transcripts.cnn.com. This is a just-in-case grab of the years of transcripts for later study and historical research.

Changes in news coverage and CNN’s focus over the years, anyone?

[via @A_L]

Related

• 10 Largest Data Breaches Since 2000 – Millions Affected
• Transcript Analyzer for Republican Debate
• Afghanistan war logs revealed and mapped

By: Paul Irish on May 01, 2012 at 11:57AM

One of the things I recognize at Google is how productive developers surround themselves with powerful tools for iterative development and debugging. For us front-end developers, the ecosystem of tools has exploded in the past two years, as we have a lot more software and libraries beyond Firebug and jQuery to help us build webapps. In the talk below I walk through the current ecosystem of tools and how they can make your development experience a more enjoyable one.

My slides:

Because there are so many tools around, I wanted to break them down somehow. I think contextualizing the tools as to what phase of development that assist with works well:

(You could think of the Y-axis here as the amount of code in a project..)

Looking at our tools this way we end up with:

• Boilerplate
  • You likely start a project with more than a single blank text file.
• Authoring Abstractions
  • CSS preprocessors, Languages that transpile to JS, Templating
• Frameworks and Application Stack
  • Clientside MVC, UI Components, Widgets
• Iteration Workflow
  • Browser Devtools, Browser/Unit/Integration Testing
• Performance Tuning
  • Profiling, Memory mgmt, browser instrumentation
• Build & Optimization
  • Minifiers, Concat, Image compression…
• Deploy
  • Continuous Integration, Continuous deployment

I’ve been thinking a lot about workflow and integrating these tools together. Screencasts like Andrey Tarantsov’s Sublime Text Workflow really excite me and I’m eager to see more people exploring a robust development setup.

By: Jason Kottke on May 01, 2012 at 10:58AM

For Sight & Sound magazine, Roger Ebert came up with his picks for ten best films ever.

“Citizen Kane” speaks for itself. “2001: A Space Odyssey” is likewise a stand-along monument, a great visionary leap, unsurpassed in its vision of man and the universe. It was a statement that came at a time which now looks something like the peak of humanity’s technological optimism. Many would choose “Taxi Driver” as Scorsese’s greatest film, but I believe “Raging Bull” is his best and most personal, a film he says in some ways saved his life. It is the greatest cinematic expression of the torture of jealousy — his “Othello.”

(via df)

Tags: best of   lists   movies   Roger Ebert

By: Simon St. Laurent on May 10, 2012 at 02:05AM

Yahoo’s Mojito is a different kind of framework: all JavaScript, but running on both the client and the server. Code can run on the server, or on the client, depending on how the framework is tuned. It shook my web architecture assumptions by moving well beyond the convenience of a single language, taking advantage of that approach to process code where it seems most efficient. Programming this way will make it much easier to bridge the gap between developing code and running it efficiently.

I talked with Yahoo architect fellow and VP Bruno Fernandez-Ruiz (@olympum) about the possibilities Node opened and Mojito exploits.

Highlights from the full video interview include:

• “The browser loses the chrome.” Web applications no longer always look like they’ve come from the Web. [Discussed at the 02:11 mark]
• Basic “Hello World” in Mojito. How do you get started? [Discussed at the 05:05 mark]
• Exposing web services through YQL. Yahoo Query Language lets you work with web services without sweating the details. [Discussed at the 07:56 mark]
• Manhattan, a closed Platform as a Service. If you want a more complete hosting option for your Mojito applications, take a look. [Discussed at the 10:29 mark]
• Code should flow among devices. All of these devices speak HTML and JavaScript. Can we help them talk with each other? [Discussed at the 11:50 mark]

You can view the entire conversation in the following video:

Fluent Conference: JavaScript & Beyond — Explore the changing worlds of JavaScript & HTML5 at the O’Reilly Fluent Conference (May 29 – 31 in San Francisco, Calif.).

Save 20% on registration with the code RADAR20

Related:

• Subscribe to the free Code podcast through iTunes
• The vision behind Yahoo’s Cocktails platform and Livestand app

By: Cory Doctorow on May 08, 2012 at 09:08PM

The Guardian: Blueprint for Democratic Participation from The Guardian and The Paley Center for Media on FORA.tv

Here’s Yochai Benkler — author of Wealth of Networks, one of the most important books written about how the Internet changes society — describing the fight to stop SOPA with laser clarity and precision, cutting through the DC/media consensus that “Google killed SOPA” or “Wikipedia killed SOPA” and showing instead how the ecosystem of people who care about networks collaborated to do the unprecedented.

The Guardian: Blueprint for Democratic Participation

(via Michael Geist)

By: Mark Boas on May 08, 2012 at 09:00AM

This is a follow up to my 2009 article Native Audio in the Browser, which covers the basics of HTML5 audio. It may well be worth reading if you want to get a feel for the <audio> element and associated API.

Now, two and a half years later, it’s time to see how things are progressing. With many new advanced audio APIs being actively worked on and plenty of improvements to the existing native audio we all know and love, it’s certainly an exciting time to revisit the heady world of <audio>.

A good way of understanding how the land lies is by going through a few use cases. That’s what I’ll attempt to do in this post.

So how do we get started? Well, there are a few things we need to do to prepare the ground. Let’s tackle MIME types first.

MIME Types #

MIME types (also known as Internet Media Types) are a way of defining file formats so that your system knows how to handle them.

Server Side #

First things first: your media server should be configured to serve correct MIME types. In the case of the Apache web server, this means adding the following lines to your .htaccess file:

Tip: Do not apply gzip compression to your media files on the server. Most formats are already compressed, and there’s limited support for those that aren’t. Further, in the case of a fallback solution, Flash does not support gzipped media.

# AddType TYPE/SUBTYPE EXTENSION
AddType audio/mpeg mp3
AddType audio/mp4 m4a
AddType audio/ogg ogg
AddType audio/ogg oga
AddType audio/webm webma
AddType audio/wav wav

Client Side #

When defining sources in your code or markup, you can also specify the MIME type, which will help the browser identify the media correctly.

To set up HTML5 audio in the most robust manner, you could write something like this:

<audio>
   <source src="elvis.mp3" type='audio/mpeg; codecs="mp3"'>
   <source src="elvis.oga" type='audio/ogg; codecs="vorbis"'>
   <!-- add your fallback solution here -->
</audio>

Here we define the element and the sources to use. The browser will only pick one. It won’t play both. In this code, we also place a fallback solution after the <source> elements.

Note that you can omit the codecs portion of the type attribute, but for robustness and efficiency, I recommend you supply the browser with as much media information as possible.

Along with the source, we specify a type attribute. Although not strictly necessary, this attribute allows the browser to know the MIME type and the codecs of the supplied media before it downloads it. If not, supplied the browser will guess and take a trial-and-error approach to detecting the media type.

Cool. So now we know how to define our audio sources, and the browser will happily pick the first source that it supports. But what if we want to supply the correct source in a more dynamic manner?

Knowing in Advance: canPlayType Can Help, Probably #

Fortunately the audio API provides us with a way to find out whether a certain format is supported by the browser. But first, here’s a quick recap on how we manipulate the audio element via the API.

var audio = document.getElementByTagName('audio')[index];

// or, if you gave it an id attribute
var audio = document.getElementById('my-audio-id');

var audio = new Audio();

Once you have your audio element, you’re ready to access its methods and properties. To test format support, you can use the canPlayType method, which takes a MIME type as a parameter:

audio.canPlayType('audio/ogg');

You can even explicitly include the codec:

audio.canPlayType('audio/ogg; codecs="vorbis"');

canPlayType returns one of three values:

1. probably,
2. maybe, or
3. “” (the empty string).

Previously, canPlayType returned “no” instead of the empty string. Worth knowing for use with early audio enabled browsers such as Firefox 3.5, Chrome 4, and Safari 4, although these make up a very small percentage of active browsers.

The reason we have these odd return types is because of the general weirdness surrounding codecs. The browser can only guess at whether a certain codec is playable without actually trying to play it.

So to test for support, you could do this:

var audio = new Audio();
  var canPlayOgg = !!audio.canPlayType && audio.canPlayType('audio/ogg; codecs="vorbis"') != "";

All we’re doing here is checking that canPlayType is supported (!! effectively casts to a boolean) and then checking that canPlayType of our chosen format doesn’t return an empty string.

Current Browser Codec Support #

Let’s check the codec support in the current crop of modern browsers.

† WAV since Chrome 9

Fun fact: Android 2.2 supports the <video> element but not its <audio> counterpart. In order to play audio, you need to use the video element.

The good news is that at the time of writing, it’s estimated that around 80% of browsers now support HTML5 audio.

The bad news is that there is still no consensus on which codec to support, so you’ll need to provide both MP3 and Ogg Vorbis sources in order to take full advantage of HTML5 audio.

Containers, Formats, and File Extensions (oh, and MIME types again) #

Above, I’ve referred to the audio formats as they’re commonly known, but technically we should refer to their container format. (A container can contain more than one format — e.g., MP4 can contain AAC or AAC+.)

Tip: To check the codec support of your browser, you can visit the jPlayer audio support tester or, more comprehensively (for audio and video), baccano.com.

We have <audio> and we’re not afraid to use it! #

Okay, we’ve done the minimum amount of work to get our audio element set up and playable. What else can we do? At the moment, we’re relying on the browsers’ default audio players, each of which looks and works a little bit differently than the rest. Perhaps we’d like to customise the experience and create our own. To help us do that, the <audio> element supports several different properties exposing its current state.

Some of the more commonly used properties:

You may need to check the durationchange event as some durations could change while media downloads. Also, depending on whether metadata is available, you might need to wait until the audio starts playing to check its duration. In short, keep an eye on the durationchange event, and watch out for NaN values when the duration isn’t yet known!

Using these properties is pretty straightforward. For example:

var audio = new Audio();
var duration = audio.duration;

The variable duration now holds the duration (in seconds) of the audio clip.

Buffering, Seeking, and Time Ranges #

The situation is improving in this area, as browser makers start to implement key parts of the spec.

The API provides attributes called buffered and seekable that can be used in situations where we want to ascertain which part of the media has been buffered, preloaded, or is ready to be played without delay.

Let’s first take a look at the buffered and seekable attributes. Both return a TimeRanges object. The TimeRanges object is a list of time periods containing start and end times that can be referenced by their indexes.

The buffered Attribute #

The buffered attribute will return the time ranges that have been completely downloaded. A little bit of a code:

// returns TimeRanges object of buffered media
var buffered = audio.buffered;

// returns time in seconds of the last buffered TimeRange
var bufferedEnd = audio.buffered.end();

The TimeRanges Object #

The TimeRanges object contains data on the parts on buffered media in the form of one or more — you guessed it — time ranges. A TimeRanges object consists of these properties:

1. length — number of time ranges
2. start(index) — start time in seconds of a particular time range
3. end(index) — end time in seconds of a particular time range

Fun fact: The default unit of time used by the JavaScript Audio API is seconds, while many traditional JavaScript functions, such as setInterval, use milliseconds.

You may be wondering in what situation the TimeRanges object would contain more than one time range. Imagine the user clicks forward to a portion of unbuffered media. The idea is that the media would then start buffering from that point, and you’d have two time ranges:

------------------------------------------------------
|=============|                    |===========|     |
------------------------------------------------------
0             5                    15          19    21

So in this case:

• audio.buffered.length returns 2
• audio.buffered.start(0) returns 0
• audio.buffered.end(0) returns 5
• audio.buffered.start(1) returns 15
• audio.buffered.end(1) returns 19
• audio.buffered.end() returns 19

Tip: Most audio-capable browsers enable seeking to new file positions during a download. To allow this, you must enable range requests on your server. Although enabled by default on web servers such as Apache, you can verify by checking that your server responds with the Accept-Ranges header.

Note that if the user is actively seeking through the media throughout the buffering process, a contiguous buffered progress bar actually makes little sense. Also consider that some browsers will read part of the end of the file to establish duration and so create two time ranges almost immediately. Now you’re starting to appreciate why making an accurate buffered progress bar is a little tricky!

You can check out TimeRanges in real-time using this handy HTML5 Media Event Inspector.

Seeking and Seekable #

Seeking is the act of looking forward (or backward) in a media file. This usually happens when a section of media is requested before it’s finished loading.

The seeking attribute can be used to determine whether that part of the media is being actively “seeked”. When it returns true, the portion of the media the user requested is still being loaded.

Fun fact: All modern browsers, apart from Safari on Windows, enable the seekable attribute, which means the seeking event never seems to fire as the user can jump directly to the requested part. The seeked event does fire though, which annoys some people who think that seeking should always fire before seeked.

To recap a little, the buffered property tells us what’s been downloaded and is often used as an indication of what part of the media can be directly played. If the browser supports it, however, it may make more sense to use the seekable attribute to determine which parts of the media can be jumped to and played immediately.

seekable returns a TimeRanges object of time ranges that can be played immediately. This uses a technology known as byte-range requests, which allows part of the content to be requested over HTTP. In short, we don’t have to load all the data prior to the desired part in order to play it.

An example:

// Is the player currently seeking?
var isSeeking = audio.seeking;

// Is the media seekable?
var isSeekable = audio.seekable && audio.seekable.length > 0;

// Time in seconds within which the media is seekable.
var seekableEnd = audio.seekable.end();

Note that media being in a “seekable” state is different than media being in a “buffered” state. Media doesn’t have to be buffered to be seekable.

Fun fact: In practice only one seekable TimeRange object is created. Where browsers support range requests the TimeRange object spans zero to the media duration, where they don’t, the TimeRange object starts at zero and its end grows as the media downloads.

Buffered and seekable data can be useful information, but it would be too easy if there weren’t a few gotchas.

1. Preloading is not supported in all older audio-capable browsers (Opera 10/Firefox 3.6).
2. The buffered attribute is not always supported (Blackberry PlayBook).
3. Not all HTML5 browsers allow byte-range seeking — for example, Safari on Windows. In this case, you can still seek within the downloaded content. It downloads from the start until the end, as does Flash.

If you want to deliver the best possible solution to your users, you’ll need to feature test.

A Note about Preloading #

I mentioned the preload attribute in the previous article. This attribute accepts three possible values:

1. none — Do not preload any media. Wait for a play event before downloading anything.
2. metadata — Preload just the metadata. Grab the start and the end of the file via range-request and determine the duration.
3. auto — Preload the whole file. Grab the start and the end of the file to determine duration, then seek back to the start again for the preload proper.

Fun fact: Mobile Safari ignores the preload attribute, effectively always using preload="none".

When it comes to preloading, remember that it’s a request or hint to tell the browser how you’d like to preload the media. The browser is not under any obligation to fulfill that request. For this reason, certain browsers may handle these requests differently.

Well-Played #

Tip: If you loop through audio.played, sum the time ranges between starts and ends, and then compare it with the duration, you can determine the percentage of the audio that the user has listened to. This may be a useful metric.

It’s worth mentioning the played property in passing. This property tells us which time ranges have been played within the media. For example:

// returns a TimeRanges object
var played = audio.played;

Media Events #

Underpinning both the native audio and video APIs is a comprehensive set of events. A full list can be found at the WhatWG version of the spec.

Attaching handlers to media events allows you to easily react to changes in state. For example, it might be useful to update the time info in a custom-built player each time the timeupdate event occurs.

A quick summary of the more commonly used media events:

Tip: Android (at least 2.3) does not always fire the ended event. Well, it sometimes throws one out for good measure, but generally you need to create your own by capturing the pause event that is fired upon reaching the end of the media and comparing audio.currentTime with audio.duration. Alternatively, you can listen for the pause event and check that audio.currentTime is zero. To be absolutely certain, use a combination of both techniques.

Other useful events:

Again, the HTML5 Media Event Inspector is your friend.

Additionally, you can test browser support by using areweplayingyet.org. It’s worth checking out the code behind the tests to understand the goings-on under the hood.

Streaming #

Streaming audio is a common requirement. This is an area that until recently has been dominated by Adobe’s Flash technology. Proprietary server technologies and protocols are well-established. One of the leading examples of this is Adobe’s Real Time Messaging Protocol (RTMP). However, current browsers only support streaming over HTTP, and so something like Flash is required to process RTMP streams.

Currently, audio-enabled browsers only support SHOUTcast and Icecast servers that stream audio over HTTP. SHOUTcast is propriety and allows streaming of MP3 and AAC files only, while Icecast is non-propriety and supports Ogg Vorbis as well as MP3 and AAC.

An Evolving Spec (Or, “Whoa, this thing is moving!”) #

As the audio spec is still evolving, there are a couple of inconsistencies in browser implementations to watch out for. These generally affect older browsers.

The load Method #

Until fairly recently, the load method was required in order to tell the browser about a change in the media source and to get it to update appropriately. Now, media.load() causes the element to reset and to start selecting and loading a new media resource from scratch.

So for older browsers, such as Firefox 3.6, in order to change the media source, you’ll not only need to change the source value but also issue a load command:

var audio = new Audio();
audio.setAttribute("src","mynew.mp3");
audio.load(); // required for 'older' browsers

When Browsers Go Off-Spec #

When creating cross-browser solutions, it’s useful to know which browsers follow the W3C spec to what extent and how they deviate.

Autoplay and Volume #

iOS and Blackberry devices ignore the autoplay attribute and media element volume changes, whereas Android supports autoplay but not volume changes.

Effectively, on Blackberry and iOS devices, autoplay functionality is disabled as both require a user-initiated event to “kick it off”. This has the unfortunate side-effect that any audio suffers a delay between user interaction and playback.

To mitigate against these issues, you may want to take a look at Doctor Remy Sharp’s excellent article on Audio Sprites and fixes for iOS.

Simultaneous Playback of Multiple Audio Elements #

A particular annoyance for developers of anything but the most simple audio web apps: not all browsers will play multiple audio elements simultaneously. This is a particular problem for games developers. Again, we see this issue with iOS and Blackberry devices.

Operating System Dependence #

Although of limited use to developers, you could install other codecs such as Ogg Vorbis on the underlying operating system, and browsers that use OS codecs should be able to play them back.

Safari (5+) relies on Quicktime being installed. This is rarely a problem unless you are running it on Windows.

Internet Explorer (9+) relies on the codecs being present at the operating system level. As it only runs on Windows, this is fortunately almost always the case.

What’s New? #

There are a few new features and whole new APIs being specified for web-based audio, so let’s take a look at what’s around the corner.

A Change of Pace #

A couple of noteworthy upcoming features are playbackRate and defaultPlaybackRate. As you can probably imagine, these fellas let us alter the speed and direction of playback. This functionality could be used for fast-forward and rewind functions or perhaps to allow users to tweak the playback speed so they can fit more podcasts into their day.

• audio.playbackRate returns 1 at normal speed and acts as a multiple that is applied to the rate of playback. For example, setting playbackRate to 2 would double the speed, while setting it to -1 would play the media backwards.
• audio.defaultPlaybackRate is the rate at which the audio will play after you pause and restart the media (or issue any event for that matter).

Media Fragments #

Currently, if we wish to reference some part of a media file, we often first have to download at least some of the media we don’t actually need. The W3C Media Fragments proposal was created to address this issue and others, such as the retrieval of an area of video or just the associated text track. In the case of audio, it will allow us to specify which parts we want to download using parameters on the source URI.

Advanced Audio APIs: The Future Sound of Browsers #

When it comes to more advanced audio functionality, Mozilla was first to enter the fray with an early experimental Audio Data API for Firefox. This was intended to facilitate audio manipulation via JavaScript and created a platform for low-level tinkering.

Not to be outdone, Google released the Web Audio API for Chrome and put it forward as a W3C proposal. The Web Audio API is a higher-level implementation that takes an audio-node based approach and provides many useful functions.

Both implementations address the desire by developers to do more with audio — to create, manipulate, analyse, and mix audio on the fly. In effect, we may one day be able to do in a browser anything we can currently do with native applications.

So what if we want to play with advanced audio in the browser? Well, two separate implementations currently exist. If you want to write applications that use both APIs in any reasonable way, you need third-party bridging libraries to abstract away the differences.

Also fairly new on the scene is Mozilla’s MediaStream Processing API, which takes another approach to audio and video streams to allow us to manipulate at both high and low levels.

In fact, using advanced APIs and taking advantage of the speed of modern JavaScript engines, we can even write decoders for unsupported codecs. Currently, we have the JSMad MP3 decoder and the lossless Alac.js decoder. Apparently, FLAC and AAC are in the pipeline. There is hope, then, that in the future, we may not have to worry about which browsers are supporting which formats.

For those curious about advanced web audio, I wrote about the differences in approaches and the different libraries that allow us to write cross-browser solutions in HTML5 Audio APIs: How Low can we Go?

The good news is that all relevant parties are talking, and things seem to be buzzing on the W3C Audio Working Group. It looks like everyone is coming together to put their ideas into a unified Audio Processing API, which is rapidly approaching publication as a Web Standard.

Summary #

Although browser implementations of the current HTML5 audio spec are improving, there are still a few issues to watch out for when creating comprehensive cross-browser solutions. You certainly need to be aware of browser limitations on platforms like iOS. Hopefully, as support matures, these issues will disappear.

Positive news on the “advanced audio” front too: a new standard is being established, and we’re close to get a unified spec for browser makers to work from. In the meantime, JavaScript libraries are available to help bridge the gaps between existing implementations.

There are also signs that we may be seeing the end of the requirement for different browser-dependent codecs. Opera Mobile already supports MP3 where the underlying OS supports it, and Mozilla look like they may enable this too. If this option exists for mobile browsers, it’s not a huge stretch to imagine that desktop browsers will follow suit.

So lots happening and lots already achieved. The rough edges of existing browser implementations are being smoothed, consensus and standards are being forged, and we can see the foundations of some very exciting new technologies being established.

The future of web-based audio looks bright!

Further Reading #

• “Probably, Maybe, No”: The State of HTML5 Audio
• The State of HTML5 Audio
• Mastering the HTML5 <audio> tag
• Unlocking the power of HTML5 <audio>
• Everything you need to know about HTML5 video and audio

HTML5 Audio — The State of Play originally appeared on HTML5 Doctor on May 8, 2012.