First let’s look at few examples of how to use the JMVC convenience methods:

//get all controllers for an element
$(".someclass").controllers()
 
//get all controllers of type MyController
$(".someclass").controllers(MyController);
 
//get the first controller
$(".someclass").controller();
 
//call the MyWidget.prototype.doSomething function with an argument
$(".someclass").myWidget("doSomething", "HELLO!");
 
//get the model for an element
$(".someclass").model();


Here’s where the $0 token comes into play. The Chrome Developer Tools $0 token is simply a reference to an inspected node (the highlighted element in the “Elements” tab.) If, for example, you wanted to see a map of the custom data- attributes of an element you would do the following:

1. Right-click on an element and choose “Inspect Element”
2. Type “Command + [" to switch to the Console tab
3. Type $0.dataset in the Console tab

After following the steps above, the console will return a DOMStringMap of the data- attributes on the element you inspected. It's pretty obvious how the $0 token simplifies calling the JavaScriptMVC convenience methods on elements (especially in situations where your Model/Controller elements don't have IDs.) When you have a Model/Controller element selected, you can simply replace the class selectors in the examples above with the token as such:

//get all controllers for an element
$($0).controllers()
 
//get all controllers of type MyController
$($0).controllers(MyController);
 
//get the first controller
$($0).controller();
 
//call the MyWidget.prototype.doSomething function with an argument
$($0).myWidget("doSomething", "HELLO!");
 
//get the model for an element
$($0).model();

Assuming you inspected an element with either a Controller or Model associated, you should see something similar to this.

If you want to try this out on a live JavaScriptMVC application, head over to the JMVC sample Todos application, add a few todos and inspect away!

The post Easy JavaScriptMVC Model and Controller Access from the Chrome Dev Tools Console appeared first on Brian Hadaway.

JavaScriptMVC is a great MV* framework that comes pre-rolled with a lot of the solutions developers need in order to build complex JavaScript applications. Among the problems JavaScriptMVC solves are dependency management, templates, unit tests, build scripts, and documentation. The framework allows developers to focus on building an application instead of assembling a frontend stack or writing yet another MVC-esque JavaScript framework.

While working with JavaScriptMVC for the better part of 18 months, I identified some anti-patterns that can wreak havoc on application development. In order to take full advantage of JavaScriptMVC, you should avoid these patterns.

Using JavaScriptMVC when you don’t really need it
Before discussing anti-patterns in a JavaScriptMVC application, let’s consider whether an application needs an MVC framework at all. Are you building a single-page web application in which the frontend only communicates to the server to retrieve data? If so, you should consider a frontend framework. However, if your application is built around a page-based architecture in which the backend is serving views in addition to data, then it is unlikely that you will benefit from a frontend MV* framework. You should also steer clear of frontend frameworks if you aren’t familiar with an MV* design pattern (such as MVC, MVVM or MVP) and you are unsure of how to separate the concerns of an application into models, views and controllers. Now, on to the actual anti-patterns.

Manually binding event handlers
JavaScriptMVC has a built-in way of binding event handlers that should always be used instead of manual binding. For example in JavaScriptMVC, instead of doing this:

$.Controller('MyExample', {}, {
    init : function() { $("#myElement").click(function(){...})}
});

You should bind event handlers using the method prescribed by the framework:

$.Controller('MyExample', {}, {
    '#myElement click' : function() {...}
});

There are numerous advantages to binding handlers the JavaScriptMVC way. One advantage is that the Controller will automatically delegate event handling to the controller’s element. This results in a smaller memory footprint and better performance. Controllers will also automatically unbind correctly-bound handlers when the destroy method is called. This will free memory when the Controller’s element is removed from the DOM and the Garbage Collector runs. Lastly, bound handlers are automatically scoped to the Controller’s DOM element which serves to encapsulate Controller logic.

Declaring markup in Controllers
Generating markup in Controllers is another anti-pattern that undermines efficiencies gained by using JavaScriptMVC. If you’ve used JavaScript (or jQuery) to add basic interactivity to a website you are probably guilty of using the following pattern:

$("#myElement").html(["<p>", myVar, "</p>"].join(""));

This may seem innocent enough, but imagine using this anti-pattern when more complex markup is required (like a datagrid). You would quickly create a nightmarish array of tags that would be impossible to maintain. If I inherit code like this from you, I will hunt you down and make you pay! But more importantly, if you inject markup into the DOM this way you’re not taking advantage “V” part of JavaScriptMVC. Here’s the JavaScriptMVC way of getting markup into the DOM:

/* Controller */
$("#myElement").html($.View("myView.ejs", {myVar: myVar});

/* Template */
<p><%= myVar %></p>

The above example is a bit simplistic but it’s important to understand how JavaScriptMVC Views improve your application. The View class abstracts the frontend templates from the Controller allowing an application to make use of one or more JavaScript templating languages (EmbeddedJS, JAML, Micro and jQuery.Tmpl by default.) Extending the View class will allow you to use additional template languages as well. Also, by stealing views (i.e. including them via JavaScriptMVC’s dependency loader) you are adding them to the list of assets subject to concatenation and caching by the JavaScriptMVC build script. This will reduce HTTP requests and ultimately produce a faster application. Using frontend templates helps you write readable, easy to maintain and reusable markup.

Replacing node contents instead of using $.View
Another View-related anti-pattern involves replacing individual node contents from the Controller instead of using the View like this:

$.Controller('DataGrid', {}, {
  "{model} data" : function(DataGrid, ev, data) {
    for(var i = 0, ilen = datagrid.rows.length; i < ilen; i++){
      $("tr").eq(i).html(["<td>", data.rows[i].column1, "</td>"].join(""));
    }
  }
});

In the above example, we are accessing the DOM multiple times in an effort to replace part of the markup of the DataGrid. A better pattern is to let the View work automagically update the DOM like this:

$.Controller('DataGrid', {}, {
  "{model} data" : function(DataGrid, ev, data) {
    $("table").html($.View("table.ejs", {rows: data.rows});
  }
});

This reduces the number of times the DOM is accessed and once again keeps the Controller free of markup.

Failure to call _super() when overriding destroy
The life of a page in a single-page web application is much longer than the life of a page in a traditional web application. This means that small memory leaks can add-up over time resulting in a sluggish, possibly unusable application. Luckily JavaScriptMVC provides a clear pattern for avoiding such memory leaks through the Controller’s destroy method. This is one of my favorite features of the framework – memory leak prevention via automatically unbound and undelegated event handlers.

The $.Controller.destroy() method is automatically called when the related element is removed from the DOM. But it’s common for objects that extend $.Controller to perform teardown operations before destroy runs. In this case, a controller would override the destroy method like this:

$.Controller('DataGrid', {}, {
  destroy : function() {
    //perform controller-specific teardown tasks
    this.element.html("You destroyed me");
    //if you forget the next function call, bad things will happen
    this._super();
    }});

Calling this._super() triggers the $.Controller to perform it’s default teardown operations such as unbinding and undelegating event handlers. If you don’t call this._super() when overriding the destroy method, your controller’s handlers remain bound and delegated which keeps a reference to the controller in memory. Objects remain in memory as long as they are referenced, so call this._super() when overriding destroy to prevent memory leaks in JavaScriptMVC applications.

Using DOM node attributes instead of model attributes.
I often use HTML5 custom data attributes to store information that isn’t of immediate importance to the user but may be relevant in the future. Like this

<ul>
    <li id="brian" data-kingdom="animalia" data-phylum="chordata" data-clazz="mammalia" data-order="primata">BRIAN</li>
</ul>

This is ugly, but it’s convenient if you want to alert the user of the biological classification of an organism on click like this:

var brian = document.getElementById("brian"),
            clickHandler = function(event){
                var el = event.target;
                alert( [el.innerHTML, "is a", el.dataset.kingdom, el.dataset.phylum, el.dataset.clazz, el.dataset.order].join(" ") );
            };
brian.addEventListener("click", clickHandler, true);

However, in JavaScriptMVC creating a model to store the organism details would be much cleaner. To refactor the above code, we would first create an organism View:

<li <%= this %> ><%= this.name %></li>

Then an organism Controller:

$.Controller('Organism', {listensTo: ['click']}, {
  init : function() {
    var model = $.Model.extend({},{name: "Brian", kingdom: "animalia", phylum: "chordata", clazz: "mammalia", order: "primata"});
    this.element.html($.View('organism.ejs', model);
    },
  click : function(el, ev) { alert( [el.model().name, "is a", el.model().kingdom, el.model().phylum, el.model().clazz, el.model().order].join(" ") };
});

This pattern keeps the markup clean as the complexity of the organism object increases.

There are a few additional anti-patterns that don’t warrant a lengthy explanation like the ones above:
Manipulating data in the View
If you need to manipulate the data being rendered in your View, do that in your Model, not the template.

Accessing DOM from a Model
Your Models should have no knowledge of the DOM, so if your model queries the DOM you’ve done something wrong. If your model needs external data, pass it to the Model via the attr method.

Using OpenAjax(global pub/sub) instead of events. (<3.1)
If your application uses multiple instances of the same controller at once, global pub/sub is a terrible way to notify your views of changes in the model. Use model attribute binding instead.

Failure to use JSLint as you go
The JavaScriptMVC build script opens your JavaScript files in Rhino, which has little tolerance for seemingly-innocuous problems in your files (like trailing commas in object literals.) You should use JSLint as you go or run steal.clean before your build. (Note: If you use TextMate, check out the JavaScript Tools bundle which notifies you warnings/errors as you save)

These are just a few of the anti-patterns that can plague single-page JavaScript application development. By avoiding these anti-patterns and using best practices, you can appreciate the power of JavaScriptMVC.

The post JavaScriptMVC Anti-Patterns appeared first on Brian Hadaway.

UbaPlayer is free and open source (GPL/MIT). Download UbaPlayer 1.0.0.

Live Examples

0800 Studio
MySongbook.com
TrumpetMoments.com
LoveAurell.com

Browser Compatibility

UbaPlayer is tested to work in the following browsers:
Mac (Chrome 10+, Safari 4+, Firefox 3.5+, Opera)
PC (Chrome 10+, Safari 4+, Firefox3.5+, Opera, IE6+)
iOS 3+ (Safari Mobile)
Android 2.2+ (Chrome, Firefox 4, Opera 11)

Audio Formats

Since UbaPlayer is a simple player, it only supports two codecs by default – OGG and MP3. These two formats are all you really need to play audio natively in modern browsers and via Flash in antiquated browsers. If you need to transcode audio it’s quick an painless if you have the right tool. Audacity is a good free tool for Mac (I’m not aware of a tool for PC.) If the task of transcoding audio seems daunting, you may want to reconsider whether you have the technical aptitude to be a web developer. If you want to add support for other codecs read on and I’ll show you how.

Basic Usage

Fork or Download UbaPlayer and place the contents of the deploy directory in your web server. Launch ubaplayer.html in your browser of choice. Verify that the demo works before making any customizations to the code.

UbaPlayer requires at least one <ul> with a class of ‘controls’ that contains one or more <li> with the class of ‘audioButton’ and an href attribute with the path of the corresponding media file (with no file extension). In the example file, the markup looks like this:

UbaPlayer can be instantiated on any DOM element. I’ll instantiate the div with the id of ‘ubaPlayer’ in the markup above like this:

At this point UbaPlayer has been instantiated and is ready to play. But what if you want to configure UbaPlayer? Below are some simple configurations:

Setting Volume
Note that setting the volume only works on desktop devices. Media volume on mobile devices is managed by the user and can’t be set via JavaScript.

Auto Play
Just pass the element that corresponds to the audio you want to play.

Auto Play example

Set Codec Preferences/Add Additional Codecs
UbaPlayer supports OGG and MP3 by default. You can add additional codecs or set the order of preference as such:

Limit Codecs
If UbaPlayer is unable to play any provided codecs natively, it uses Flash to play. The following code with tell UbaPlayer to attempt to play MP3 files natively then use Flash instead of attempting to play OGG files.

External Controls
If you want to provide a way for users to control playback outside of the single button, you can provide external controls. The code below assumes you have a button in the DOM that toggles playback of the current track.

Download UbaPlayer – The jQuery HTML5 Audio Player with Flash Fallback

The post UbaPlayer – The jQuery HTML5 Audio Player with Flash Fallback appeared first on Brian Hadaway.

Given the simplicity of the player, I was surprised when I recently received an email from someone asking me to help determine why my HTML5 Audio Player wouldn’t work for him in Firefox. He had seemingly configured everything correctly and the player worked in every other popular browser, but he still couldn’t get the player to work in Firefox. As it turns out most servers (including those used by GoDaddy) by default don’t serve the appropriate MIME Types for OGG files. That being the case, you’ll need set the appropriate MIME Types for OGG files if you want HTML5 audio players to work correctly in Firefox. So for an Apache server, you would need to add the following to your .htaccess file:

AddType audio/ogg .oga
AddType video/ogg .ogv
AddType application/ogg .ogg

Evidently, other browsers will guess the MIME Type based on file extension if a MIME Type isn’t served. I had just been lucky that all the servers I used up until this point were already configured to serve the right MIME Types.

If you want more info about this, check this page on the Mozilla Developer Network.

The post OGG Files Causing Errors in HTML5 Audio Player in Firefox appeared first on Brian Hadaway.

Front-end developers are often called on to build UI elements that aren’t entirely original. Whether the cause of this phenomenon is a lack of creativity on the part of designers or a particular affinity for certain UI elements among the web-browsing public, ripping-off drawing inspiration from others’ ideas is common in web design. One of the most prominent sources of such “inspiration” over the past few years is Apple’s Aqua interface. Thanks to this glossy, semi-transparent, gradient-laden design, front-end and Flash developers have spent several years worth of billable hours creating simulated reflections and configuring cover flow components for clients insistent upon having sites that “look more web 2.0″.

Thanks to the advent of iOS devices, there’s a new set of Apple-designed UI elements that designers are using as inspiration. In fact, there’s already an open source project, iUI, that aims to provide “a more ‘iPhone-like’ experience in your WebApps” using HTML, CSS and Javascript. The iUI project not only imitates the look of the iOS interface, but it also seeks to emulate the subtleties of the experience of using an iPhone, iPad or iPod. One such subtlety, that I haven’t seen successfully recreated in HTML, CSS and JavaScript is the alphabetical lists seen in Contacts and Music (among other places) in the iPhone, iPad and iPod. To test my mettle, I set out to recreate that seemingly-simple UI component.

One of the most prominent places alphabetical lists are used is in Music and Contacts. In case you aren’t familiar, here’s what it looks like in Music:

The heading for the current list section (A) remains stationary as the user scrolls through the section.

As the adjacent section (B) approaches the top of the list container, the current section (A) and header scroll off screen.

Once the header for the new section (B) reaches the top of the list container, its position becomes fixed and it remains in place until the user scrolls to a new section.

The Concept

The main challenge to overcome is the need to reposition the current section’s header every time the list’s scroll event fires. For instance, while A is the current section, its header must appear to remain fixed at the top of the list until it “collides” with the next section’s header (B). Once A’s header “collides” with B’s header, A’s header becomes fixed to the bottom of its section where it remains until the bottom of the section A exceeds the height of its header. Performing these calculations as the scroll event fires (inconsistently across browsers) is taxing and on users’ machines and results in the header flickering as the list scrolls.

Given this challenge, it is necessary to resort to some sleight of hand. I can create a “fake header” that will remain fixed at the top of the list. This header will remain visible until I need to show headers A and B collide at which time I will hide the fake header, show the animation then update the text in the fake header and unhide it. This alleviates the need to reposition the current section’s header every time the list’s scroll event fires resulting in a better-performing, flicker-free iPhone-style contact list.

(1) Fake Header visible (2) Fake Header hidden, 'A' header positioned to bottom of its parent, (3) Fake Header visible with text updated to 'B'

The Markup

This is the perfect use of the under-appreciated definition list element (DL). By using a DL, I can use its child element DT as the header and DD as the list item. There’s only one issue with this approach. I need to keep the elements associated with a certain heading grouped so I can measure groups’ height and position. I could wrap each group in a DIV, but that would be semantically incorrect (DL should only have DT and DD as children), so I’ll use individual DL elements for each group. I wrap my DL elements in a DIV with the ID of “list1” and the class of “listContainer”. This will be the scrolling container and will allow multiple list instances in one page.

The JavaScript

The logic in the JavaScript for this component is quite simple. I’ve already discussed the logic to some extent in “The Concept” above, so let’s talk about optimizing the script.

When using jQuery, developers often fall into the trap of repeatedly accessing the same DOM element. Without exercising care performance will tank so I want to call methods that access the DOM as infrequently as possible. The obvious way of doing this is by caching elements and wrapped sets. Another way I reduce DOM access method calls is by operating on cached element properties instead of repeatedly retrieving those properties from the DOM. For instance, every time the scroll event fires I need to determine which element is at the top of the list and which element and its previous sibling. To do this efficiently, I reference cached element properties stored in an array instead of accessing the DOM elements’ properties. This drastically increases performance.

The CSS

Much of the list’s CSS is used to adhere (loosely) to a visual design but some of the styles are instrumental to the functionality. View the source of the sample to see what’s going on with the CSS. It’s pretty simple.

Download the Demo and Source or fork it on GitHub

The post iPhone-Style Alphabetical Contact List with HTML, CSS and JavaScript (jQuery) appeared first on Brian Hadaway.

There has been a lot of recent debate about whether responsive web designs are a valid alternative to dedicated mobile sites and/or native applications. Some call the practice “fools gold” while others think responsive web design finally lets developers achieve the code-once-for-all-platforms-nirvana we’ve been seeking for so long. In reality, it’s likely neither of the above. But the fact remains that I want my site to look good and be easy to use on mobile devices without having to create a dedicated mobile site. For me, CSS3 media queries are the answer.

The “media” part of media queries isn’t new to CSS. Prior to CSS3 you could limit the scope of stylesheets, but we were confined to a set of media types like print, screen and projection. This was a serviceable solution back when all screens were similarly-sized. But now, since screens vary so greatly in size, it is necessary to further-inspect the media on which a user is viewing a site to determine how best to display the site. Thankfully, the CSS3 specification expands media type-dependent stylesheet support by allowing the use of expressions to further limit the scope of stylesheets. Using CSS3 media queries, we can inspect characteristics of users’ devices, such as size, orientation, resolution and pixel density, and adapt styles accordingly.

Media queries can exist in HTML or @import and @media rules in CSS. As if the name wasn’t a dead giveaway, media queries consist of a media type and a query. Media types include print, projection, screen, handheld, aural, Braille, tty, tv and all. If you’re familiar media types, you may ask why we can’t simply use the handheld type to target mobile devices. Technically you can but the Symbian browser, Opera and mobile Safari ignore the handheld type. According to Apple’s developer guides mobile Safari “ignores the print and handheld media queries because these types do not supply high-end content.”

The second part of media queries, the query, inspects media features to determine when specific styles are used. The most commonly used media features include width, height, device-width, device-height and orientation. Media features that pertain to width and height accept the min- and max- prefixes allowing us to further refine the scope of a particular style. Orientation is calculated by comparing the browser width and height. This makes it possible to query the orientation any device, not just tablets and mobiles.

One additional media feature of interest, device-pixel-ratio, allows inspection of pixel density. Querying this media feature allows you to serve higher-resolution images for the iPhone Retina display. Unfortunately, at the time of this writing, it is necessary to use vendor prefixes so you’ll need to add -webkit and -moz to make this work. Eventually you’ll be able to use just device-pixel-ratio. You can also apply the min- and max- prefixes to device-pixel-ratio.

One of the keys to successfully implementing a responsive web design is determining the resolutions at which your site should “respond”. This highly dependent upon the design of your site but you will likely want your site to respond at (or near) common tablet and mobile device resolutions (1024px and 768px for iPad, 960px and 640px for iPhone 4 and 480px and 320px for iPhone 3GS and older).

So what does a media query look like? It depends on where you put it. As mentioned earlier, media queries can exist in HTML or @import and @media rules in CSS:

Media Query in HTML

<link rel="stylesheet" media="screen and (max-width: 1024px)" rel="stylesheet" href="example.css">

Media Query in @import

@import url(example.css) screen and (max-width: 1024px)

Media Query in stylesheet

@media screen and (max-width: 1024px) { ..styles go here }

The stylesheet I use to achieve my responsive design for this site consists of a set of base styles and three sets of media queries. The base styles apply to all browsers with a width greater than 994px. Browsers that don’t support CSS3 use the base styles as well. There are several options for adding media query support to those browsers, but since the goal of my responsive design is to improve the appearance and usability of my site on mobile devices and tablets (all of which have browsers that support CSS3), I chose not to implement a fallback.

Here are the media queries used in my site:

@media only screen and (min-device-width: 768px) and (orientation: portrait),
screen and (max-width: 994px) { /* for tablets in portrait mode and desktops with less than 994px of horizontal browser width */ }

@media screen and (max-width: 320px) { /* anything less than 320px (primarily phones in portrait */ }


In addition to these media queries, I use a viewport meta tag to set the initial scale of the site and disable zooming on mobile devices and tablets. The viewport meta tag looks like this:

<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0">

Here’s what my site looks like at various browser sizes:

As much as I like responsive web design, there are some valid criticisms of the practice. Responsive web design assumes that there is only one use case for all browsing contexts which is not always the case. For instance, visitors using tablets or desktops may be interested in viewing a retail site’s photo gallery or testimonials, while someone using a mobile device may be solely interested in finding a phone number or store hours. Also, the practice of only using media queries to implement responsive design can result in unnecessary overhead when loading elements that aren’t used in smaller contexts. If a media query for a small mobile context hides a slideshow, the browser still may unnecessarily load the related script and images.

Dedicated mobile sites and native applications may be the right solution for some projects, but responsive web design with CSS3 media queries is a quick and easy way to provide a consistent user experience across all browsing contexts.

The post Responsive Web Design Using CSS3 Media Queries appeared first on Brian Hadaway.

I wanted to create a simple one-button audio player using HTML5 that would be suitable for playing samples of audio tracks. This one-button player would toggle between play, pause and loading states and would stop playing the current track when another instance of the button is clicked. Naturally, I would want to include a Flash fallback for browsers that don’t support HTML5 audio playback. I also wanted to use HTML/CSS to style a single set of controls that serve as the UI for both the HTML5 and Flash versions of the player.

What resulted from this exercise was a jQuery audiocontrol plugin that controls playback and an “invisible” Flash audio player that emulates the HTML5 <audio> element. The control lacks some necessary features such as support for playlists and “bundled” playback. This would allow users to listen to a group of tracks without continually clicking play. Also, there is currently no publicly-exposed method to kill audio playback from outside the control. This is also my first jQuery plugin so there’s probably some improvement to be made in that code. But it’s still a good basic HTML5 audio player with Flash fallback that allows you to style the buttons with CSS regardless of whether the audio is playing natively in the browser or in the Flash plugin.

The code is tested to work in the following browsers:

1. Firefox 3.6 – Mac/PC
2. Safari 5 – Mac
3. Chrome 10 – Mac
4. Internet Explorer 7+ – PC
5. Firefox 4 – T-Mobile G2 (Android 2.2)
6. Opera Mobile 11 – T-Mobile G2 (Android 2.2)
7. Default Browser – T-Mobile G2 (Android 2.2)
8. Safari Mobile – iPad and iPod Touch (iOS)

Take a look at a demo of my HTML5 audio player with Flash fallback here. Feel free to download the source and use it however you like. You’ll find some documentation in the jQuery plugin or you can hit me up with a comment or email if you have questions about how to customize this to your needs.

The post HTML5 Audio Player with Flash Fallback appeared first on Brian Hadaway.

In a previous post, I mentioned that I wanted to see first-hand how each browser renders default controls for the HTML5 audio element. I created a simple demo page and tested it in the following browsers:

1. Firefox 4 – Mac (OSX 10.6)
2. Safari 5 – Mac (OSX 10.6)
3. Chrome 10 – Mac (OSX 10.6)
4. Internet Explorer 9 – PC (Vista)
5. Firefox 4 – T-Mobile G2 (Android 2.2)
6. Opera Mobile 11 – T-Mobile G2 (Android 2.2)
7. Default Browser – T-Mobile G2 (Android 2.2)
8. Safari – iPad and iPod Touch (iOS)

As I tested the demo on the G2 in Android 2.2′s (aka Froyo) default browser I was surprised to see that I get neither the browser’s default controls nor the fallback message enclosed inside the audio element. How could this be?

It’s my understanding that any text between the opening and closing audio tags will be displayed in browsers that do not support the audio element. So if that text doesn’t appear in then the browser supports HTML5 audio, right? So why does Android 2.2′s browser display the following:

In every other browser tested, the following code rendered either audio controls or the fallback text:
<audio controls="true">
<source src="media/AwMan.mp3"/>
<source src="media/AwMan.ogg"/>
Your browser does not support HTML5 audio.
</audio>

Logically, this tells me Android 2.2′s browser doesn’t support mp3 or ogg media types which is odd given the fact that every other tested browser supports one of the two codecs. So if Android’s browser doesn’t support these codecs, which does it support? Again, I created a test page to help me answer this question. (Click here to see which audio codecs your browser supports.)

If you view the source on the test page you’ll see that first I check whether the browser can create an instance of the audio tag and whether it has the canPlayType method. If that test succeeds, I then test the most widely used codecs to see if they are supported in this particular browser. Calling canPlayType for a particular codec returns either “probably”, “maybe” or empty. Empty means that the codec isn’t supported. When I visit this test page on my Android device I see the following:

As you can see, technically Android 2.2′s default browser supports HTML5 audio (in the sense that programmatically-created element has the canPlayType method) but it can’t play any media files encoded with popular codecs. So as it turns out in the case of the native Android 2.2 browser, you can’t simply let the browser interpret the markup to make the determination as to whether it can play audio. Though Google will likely fix this in future versions of Android, it will be up to the various service providers as to when this update is distributed to users. So it’s likely that this will continue to be an issue for awhile. This is definitely something to consider when providing fallback content for HTML5 audio.

The post HTML5 Audio Support on Android Devices appeared first on Brian Hadaway.

You’ll also notice that the Native Browser on Android 2.2 (Froyo) doesn’t render the HTML5 audio controls at all. This is a known issue with Froyo and should be fixed in Android 3. Update: Read more about this here.

Take a look at how each browser renders HTML5 audio controls below:

Firefox

Chrome

Safari

Internet Explorer 9

Native Browser – Android 2.2 (Froyo)

Firefox – Android 2.2 (Froyo)

Opera – Android 2.2 (Froyo)

Safari – iOS (iPhone and iPad)

The post How HTML5 Audio Controls Render In Modern Browsers appeared first on Brian Hadaway.

What if you want to update existing declarations to be Android-friendly? Instead of regenerating the entire @font-face kit, you can simply update your @font-face declarations manually to support Android devices. Here’s a code snippet to get you started:

@font-face {
font-family: 'MyFont';
src: url('MyFont.eot?') format('eot'), url('MyFont.woff') format('woff'), url('MyFont.ttf') format('truetype'), url('MyFont.svg#webfontwTBKaDwa') format('svg');
font-weight: normal;
font-style: normal;
}

BAM!

The post Make @font-face Work on Android Devices appeared first on Brian Hadaway.