Advertise here via BSA

FROONT is a web-based design tool that runs in the browser and makes responsive web design accessible to all kinds of visual designers, even those without any coding skills.

FROONT makes responsive web design visual. Design can be done in-browser with intuitive drag-and-drop tools. After all, humans judge design with their eyes therefore it seems just normal to see right away how designs will look across all different screen sizes. Each project has its own URL, that makes it easy to test the designs on real devices right away.

Requirements: -
Demo: http://froont.com/
License: License Free

Sponsors

Professional Web Icons for Your Websites and Applications

Advertise here via BSA

jQuery.swatches is a free to use that turns a one-line div into a sweet color swatch. You can customize the class as you want. Using different classes would allow you to render groups of swatches at individual times by calling swatchify() on a different selector.

Requirements: jQuery Framework
Demo: http://maxmackie.com/jquery.swatches/
License: MIT License

Sponsors

Professional Web Icons for Your Websites and Applications

Advertise here via BSA

HTML5 Up! is a small showcase of the free responsive HTML5 + CSS3 site templates that AJ put together while developing 5grid. All of them are clean, minimal, fully responsive site templates built on HTML5 and CSS3. They are licensed under the Creative Commons Attribution license.

Requirements: Skel.js Framework
Demo: http://html5up.net/
License: Creative Commons License

Sponsors

Professional Web Icons for Your Websites and Applications

Advertise here via BSA

This article recently appeared on the Atari Arcade Developer Center, a collaboration by the teams at gskinner.com , Atari and Internet Explorer.

The Atari Arcade: a true game portal showcasing what’s possible with web standards like HTML5, CSS3, and JavaScript. Slick graphics, fast, multi-player gameplay, and platform agnostic. Initially only targeting desktop and tablet-based browsers, we’ve now endeavored to bring the arcade to mobile.

Choosing a Target

By limiting to desktops and tablets in the first release, we narrowed our scope considerably, and were able to provide a semi-responsive layout with a single game size. Our reach included most standard resolution monitors, plus tablet form-factors like Surface and iPad.

But we quickly learned that we were missing something by not targeting the huge number of users on mobile devices. That is, a vast market that now accounts for about 12% of all global internet traffic, spanning all kinds of dimensions, resolutions, and processors. Our next task was identifying an approach to bring the arcade to the mobile web. We wanted to support a variety of resolutions, including higher DPIs in new devices like Windows Phone 8 and iPhone 5.

This article discusses the goals to mobilize the arcade, as well as some approaches, the issues we encountered, and some tips and tricks where we found value.

Taking Aim

We spent a good deal of time determining what was possible on different platforms to establish a feature set that was appropriate for mobile.

Our goal was to build a site that:

1. Could re-use the majority of the site framework we had already built
2. Scaled fabulously on any resolution
3. Performed awesomely on newer devices
4. Was intuitive to navigate with touch
5. Could include some of our games at launch, and all of our games shortly after
6. Could be extended to third party developers!

With this game plan, we set upon re-architecting the front-end of the site, and making the games elastic to support the resolutions we needed.

What Works?

The first task: eliminate platforms that just won’t work. With the wide array of platforms and models of phones, we did some focused testing on the following points:

1. Technology. Some devices don’t have adequate canvas, JavaScript, CSS, or HTML support.
2. Touch capabilities. All of the games are already touch-enabled, so we eliminated any candidates with only single-input touch support.
3. Adequate resolution. Older browsers tack on a ton of browser chrome on mobile devices, and we needed enough real estate for our games to look great and display touch controls when required.
4. Performance. Once it looked right, and functioned properly, we focussed on performance and monitored frame rates.

We tested a number of devices – the primary targets being Microsoft’s Windows 8 devices (to highlight the technical capabilities of the platform), and iPhones (to reach the widest market). We also tested on a number of Android phones to see what we could support.

The results were surprising. Not all phones are created equally, but the arcade ran quite well on almost everything we tested with.

1. We got incredible performance on Windows Phone 8. It had the highest frame-rates, the site rendered as expected, and the multi-touch worked great. Unfortunately, we could only get our hands on a WVGA device (800×480) for launch, but we expect the WXGA and 720p devices will have no problems.
2. The site and games performed great on the new iPhones, but it was clear from the start that Mobile Safari’s chrome consumed too much real estate. In order to support iOS5 in mobile Safari, the arcade needs to be pinned to the home screen to run in fullscreen. We then discovered that iOS5 and below have no hardware support in pinned site mode, so although we can support it, not all games perform well.
3. We got mixed results on various Android devices we tested, including phones as well as a Nexus 7 tablet. The site and games mostly performed, but due to our short timeline, and the wide range of Android devices, we decided to focus on the other platforms first.

Interestingly, none of the devices had any trouble with loading and displaying our games, except for a hiccup with audio. We were impressed to see such consistent support across various mobile browsers.

Adapting to Surroundings

With the tech dust settled, we began the site redesign.

To hit our target devices in a single production cycle, we incorporated responsive and adaptive approaches that react to mobile visitors, and loads a scalable, flexible, percentage-based version of the arcade. It keeps everything contained in the viewport regardless of size or landscape aspect ratio. No media queries are required.

Check out the following comparisons of Windows Phone 8 (left) and iPhone (right):

We kept as much consistency in the DOM between the desktop and mobile site as possible. This let us use most of our existing site HTML and CSS structure – both of which required relatively minor edits to support the new views. We implemented a swipe-based mobile navigation which allowed us to push our artwork to the forefront, and make it easier and faster for fingers to get into the games.

The Arcade now responds to the user agent, and serves the fixed-size desktop version, the adaptive mobile version, or appropriate messaging for unsupported browsers and devices.

Initial Findings

To have the best possible gaming experience in a mobile browser, we had to get full screen, or at least as close as possible.

Windows Phone works great.
WP8 is almost there: it has a persistent browser bar at the bottom of the screen in both landscape and portrait modes (which can be easy to accidently touch), but more than enough screen real estate for an immersive in-browser gaming experience.

iOS 6 has full screen.

It works pretty well, but has some interesting issues. The full screen mode is really easy to toggle out of, and navigation buttons overlay the bottom area which can even scroll the screen if touched right. Worth noting is that full screen in Mobile Safari is a landscape-only feature, which worked out just fine for us.

iOS 5 falls back.
iOS5 gets close to full screen by virtue of a ‘pinned site’ on the users home screen. Without this workaround, Mobile Safari chrome reduces the viewport height by close to 50%. But beware: pinned sites do not get hardware support on iOS5. Some content will run poorly.

Native scroll and zoom
Mobile browsers natively include intuitive page scroll, over-scroll, and zoom. This is great for viewing web pages – but not games. Fortunately, we can block it almost entirely. This approach does not work in Windows Phone 7, which is another reason we chose not to support it. To block the native zoom, we use these meta tags:

<!-- Define the viewport -->
<meta name="viewport" content="width=device-width, initial-scale=1, minimum-scale=1, maximum-scale=1, user-scalable=0, target-densitydpi=device-dpi">

<!-- iOS helper -->
<meta name="apple-mobile-web-app-capable" content="yes" />

To prevent scrolling, we include this simple JavaScript:

document.addEventListener(
    "touchstart",
    function() { return false; },
    false
);

Adaptive Liquid Layouts

In our first release, we chose a single resolution to make game development straightforward, and settled on dimensions that worked on most displays and would still fit into the viewport on a Surface or iPad.

For mobile, we had to re-think our approach and come up with ways to make the games look as good on a small screen as they do on a large one. We couldn’t just scale the games, or simply float our assets in a liquid layout. We needed a hybrid approach, where our games both flex and scale.

Making it Fit

The first step was scaling the canvas. This provided a unique challenge, because mobile devices with higher pixels per inch (such as Windows Phone and iPhone 4+) automatically scale content to make it more readable. Through a series of tests we determined that:

• Windows Phone 7 and 8 (only tested on WVGA at the time of writing) scale content to 1.666x. Read more
  here, and here
• iPhone scales content to 2x. This can be determined by checking the CSS property window.devicePixelRatio, which is the number of actual pixels, divided by the number of device pixels or “dips”.

This means that we have to counter-scale our content in order to fit it properly on each device. To do this, we multiplied the dimensions on most HTML elements (such as the container iframe) by the inverse of the scale factor(0.6 for WP, and the 1/window.devicePixelRatio for iPhone). Read more about devicePixelRatio.

    
var factor = 1;
if (iOS) {
    // devicePixelRatio evaluates to "2" on iPhone 4+
    factor = 1 / window.devicePixelRatio;
} else if (wp7 || wp8) {
    factor = 0.6;
}

var frame = document.createElement("iframe");
frame.width = 1024 * factor;
frame.height = 622 * factor;
    

On our game canvas however, we want to see the pixels instead of scaling our game down, and having the device double it up. So we used CSS scaling instead. When you change the dimensions of an HTML Canvas via CSS, the contents are scaled, rather than just changing the viewport size and relying on the browser to recalculate. This gives us almost exactly a 1/1 pixel ratio on the screen, which looks great on a small, high resolution device.

    
var factor = 1;
if (iOS) {
    // devicePixelRatio evaluates to "2" on iPhone 4+
    factor = 1 / window.devicePixelRatio;
} else if (wp7 || wp8) {
    factor = 0.6;
}

var canvas = document.createElement("canvas");
canvas.style.width = canvas.width * factor;
canvas.style.height = canvas.height * factor;
    

The resulting (unscaled) game size is passed into the game in the GameInfo class, and the game can render everything as usual.

    
// In game code
function startGame() {
    var btn = new createjs.Shape(btnGraphics);
    // Position on the bottom right
    btn.x = this.gameInfo.width - btn.width - 10;
    btn.y = this.gameInfo.height - btn.height - 10;
}
    

Reflowing the Games

With our new viewport set up, we were still left with a few challenges:

1. Content alignment
Since the games were developed with a single use-case in mind, when the canvas changes size, the positioning of assets needs adjusting.

Most of the time UI and game elements were already anchored to an edge or centered, but not always. It reminded us that we should be using edge alignment or percentage-based positioning wherever possible from the onset.

2. Content scaling

Some reflowing wasn’t so simple. In Super Breakout, brick sprites were designed to fit exactly 13 columns in the standard viewport size. To support a smaller screen, we started by scaling everything down. Fortunately, the bitmaps rendered just fine at a smaller size, but on a small screen we were left with 13 incredibly small bricks.

This encouraged us to include a straightforward method in the developer SDK that determined what sort of resolution we were dealing with, so that content can adapt. Rather than provide something like a DPI, we opted for a simple mode: Low, Normal, and High resolution. This property is now exposed in the helpful GameInfo class of the Atari Arcade SDK.

    
// On a tiny device, scale down
if (gameInfo.quality == GameLibs.GameInfo.QUALITY_LOW) {
    myBtn.scaleX = myBtn.scaleY = 0.5;

// On a high-resolution device, scale up
} else if (gameInfo.quality == GameLibs.GameInfo.QUALITY_HIGH) {
    myBtn.scaleX = myBtn.scaleY = 1;
}
    

When games are on higher-resolution devices, images and UI elements are scaled up. In an extreme example, WXGA and 720p Windows Phones have almost double the resolution as their WVGA counterparts – so we can almost double the sprite size to have a comparable game.

In the new mobile version, we include only 10 columns, and the assets scale to fit the available space. Fortunately, EaselJS makes scaling intelligent and simple. You can scale individual assets, containers with multiple children, or even provide alternate image sources to swap out with in high resolution environments.

    
function startGame() {
    // In high-resolution, scale the entire HUD
    if (this.gameInfo.quality == GameLibs.GameInfo.QUALITY_HIGH) {
        this.gameHud.scaleX = this.gameHud.scaleY = 0.6;
    }
}
    

On-screen Controls

When changing form factors, there’s always a risk that certain aspects won’t translate well.

One of our key concerns when we conceived our plan was the player’s hands. On a device like the Surface, only a small portion of the lower corners are obscured by the user’s hands when in touch mode. On a phone-sized device, that area grows considerably.

We can’t just scale down UI controls with the rest of the game – we need them large enough to give the user enough control. Our initial plan was to only roll out 3 games, the ones not requiring UI controls: Super Breakout, Pong, and Missile Command. However after some quick tests, we were convinced that Asteroids would work too.

And it did! Controls needed to be scaled down about 60%, but the game is still playable and fun.

We hope to be able to provide the rest of the arcade and any new games submitted by developers, in the mobile site soon.

More and More Testing

Device testing can be a pain. Simulators can get you halfway there, but there is no replacement for an actual device to test with. We have a formidable cache of devices that we use on a regular basis.

But there is lots of cool things you can do to make debugging and testing easier:

1. Compat testing in IE10 provides great testing of previous IE versions without an antiquated test machine.
2. Device spoofing in browsers allows a way to test user-agents and viewport sizes. Chrome and Safari have great
   tools for this.

3. To test responsive interfaces, simply scale your browser window.
4. Remote debugging with Wienre provides awesome DOM inspection.
5. Remote debugging with iOS6 and Lion provides full web inspection just by plugging in your device. Simply enable the inspector in the iOS Safari preferences, and access it via the Safari ‘developer’ menu on the desktop.
6. iOS 5 users still have a rudimentary console, which can be turned on in the iOS Safari preferences.
7. Run a webserver like MAMP or XAMPP, and devices can access the development version over an internal network.
8. The new Test Harness HTML page that is included in the Atari Arcade SDK includes some options for spoofing mobile resolutions and touch interactions in the games. Have at ‘er!

Addressing Performance

As part of this project, we spent some quality time with Microsoft engineers and evangelists, which was incredibly insightful. Not only did we gain some awesome respect for the amazing team at Microsoft, but we learned some invaluable tips, tricks, and best practices that we have rolled into the Atari site, the Atari Arcade SDK, and the next versions of the CreateJS suite.

Most of us develop on blazing fast quad (or more) core machines, with awesome GPUs and more horsepower than we need. For this phase of the Arcade, we had to take a hard look at performance, and ensure that the arcade could move forward onto lower powered devices, including the just-released ARM-based Microsoft Surface.

Here are some bite-sized tips we took away:

1. Leave the DOM alone. JavaScript -> DOM communication is expensive. Even things like adding/removing audio from the DOM caused huge performance hits.
2. Reduce complexity and nesting in your DOM.
3. Learn to use CSS transforms instead of positioning properties like top and left. CSS transforms are hardware accelerated, and super fast. Position changes via CSS are really slow. Note that many browsers still use a prefixed transform, so the approach is more complex – but the result is worth it!

    
// Old way
div.style.top = "100px";

// New way
var props = ["transform", "msTransform", "webkitTransform", "oTransform", "mozTransform"];
var found = false;
for (var i=0; i < props.length; i++) {
    if (props[i] in div.styles) {
        div.styles[props[i]] = "translateY(100px)";
        found = true;
        break;
    }
}
if (!found) {
    div.style.top = "100px";
}
    

Fun fact: IE10 has both prefixed and unprefixed transforms, so you will only want to apply one of them if you are looking for an extra boost in performance.

4. Use CSS classes on elements instead of injecting javascript to manipulate styles.
5. Pixel access on Canvas is expensive, since it needs to reach into the video buffer. Avoid it when possible. For this reason, EaselJS does not track mouseOver gestures unless you explicitly turn them on:

    
// Create a stage
var stage = new createjs.Stage(canvasElement);

// Enable the mouseOver with a frequency
// whic is the maximum number of checks per second.
stage.enableMouseOver(10);
    

6. Touch events are really expensive. Avoid complex actions that result from touch input, and instead cache touch coordinates, and perform actions on the game tick, or using some form of invalidation.

And always, always test directly on target machines. Many of the above tips are indistinguishable on the desktop, or when simulated from the desktop. Once it's in your hands on a device, you'll really feel the changes.

What's Next?

Atari hopes to open the door shortly to developers that want to build mobile games using the Atari Arcade SDK that can be submitted to the arcade. With this latest release of the SDK, all the the necessary hooks, methods, and testing environment are available to start building and testing mobile games today. Hopefully, the submission process will extend to mobile in the near future.

So check out the resources below, clone the Atari Arcade GitHub repository, and have fun!

Resources

Pick up these awesome books. They are a few years old, but are incredibly helpful, and are required reading at gskinner.com for all developers and designers working with HTML.

1. High Performance Web Sites
2. High Performance JavaScript
3. Even Faster Websites

Here's some additional resources and references for game development in HTML5.

• CreateJS
  Learn more about CreateJS
  Community Forum and Feedback
  CreateJS on GitHub
• More HTML5 and Flash goodness on gskinner.com and the gBlog
• 50 performance tricks from Microsoft //Build/ 2012
• Internet Explorer 10 Guide for Developers
• HTML5 Labs
• W3C
• Removing legacy IE Markup with Compat Inspector
• Feature Detection for HTML5
• IE Blog
• MSDN IE DevCenter
• IETestDrive
• Windows 8 / Internet Explorer 10 : Touch Friendly
• Windows 8 / Internet Explorer 10 : Plug-in Free
• Windows 8 / Internet Explorer 10 : Pinning Sites

About the Authors

Lanny McNie, Michael Graves, and Chris Caldwell are the senior staff of gskinner.com, an agency focused on building bleeding edge interactive and creative, and bringing value to platform owners, developers, and end users alike. We produce success stories that showcase and enhance technology platforms. We recently worked with Atari to bring re-imagine the Atari Arcade using webstandards like HTML5, CSS3, and websockets.

Sponsors

Professional Web Icons for Your Websites and Applications

Advertise here via BSA

Easy responsive tabs is a lightweight jQuery plugin which optimizes normal horizontal or vertical tabs to accordion on multi devices like: web, tablets, Mobile (IPad & IPhone). This plugin adapts the screen size and changes its form accordingly.

It supports Horizontal / Vertical Tabs to Accordion. Tabs and accordion are created entirely with jQuery. It supports multiple sets of tabs on same page. It has been tested on IE7+, Chrome, Firefox, Safari and Opera. It is released under MIT License.

Requirements: jQuery Framework
Demo: http://webtrendset.com/demo/easy-responsive-tabs/Index.html
License: MIT License

Sponsors

Professional Web Icons for Your Websites and Applications

Advertise here via BSA

Editr is a HTML, CSS and JavaScript playground that you can host on your server. it is based on ACE Editor. It’s super easy to setup. It supports multiple instances on one page. Configurations are available via JS object or HTML attributes. Editr is licensed under MIT License.

Requirements: JavaScript Framework
Demo: http://idered.pl/editr/
License: MIT License

Sponsors

Professional Web Icons for Your Websites and Applications

Advertise here via BSA

Twitter has adopted a Facebook Timeline-like cover display for main profile pages, opening up a new avenue for visual creativity. Ranked as one of the ten most-visited websites and three most used social networks, twitter is definitely changing the face of social media by actively engaging with the targeted audience.

TwitrCovers collects the best Twitter Covers around the world. There are different categories you can choose from, for example, Abstract, Art, Nature, Photos, Places and etc. Here we have selected the following 35 Creative Twitter Covers for Web Designers.

Paint Brain

Smoking Pipe

Programming Code

Test Pattern

Window Panes

Cityscapes Architecture

Ubuntu

Minimalistic Humor

Nerd School

Landscapes Beach

Sea

Abstract Violet

Grass Summer

Sepia

Batman Flying

Sunset

Leaves

Glasses

Danboard Sneakers

Atari

1940 New York City

Abstract Light

Albert Einstein

Japan

Artwork

Comics

Snow

Clouds Nature

Drowning

Ubuntu

Nature Desert

Star

Thinking

Water

Desert

Sponsors

Professional Web Icons for Your Websites and Applications

Advertise here via BSA

Two.js is a two-dimensional drawing api geared towards modern web browsers. It is renderer agnostic enabling the same api to draw in multiple contexts: svg, canvas, and webgl. Two.js aims to make the creation and animation of flat shapes easier and more concise.

Two.js has a built in animation loop. It is simple in nature and can be automated or paired with another animation library. Two.js features a Scalable Vector Graphics Interpreter. This means developers and designers alike can create SVG elements in commercial applications like Adobe Illustrator and bring them into your two.js scene.

Requirements: JavaScript Framework
Demo: http://jonobr1.github.io/two.js/
License: License Free

Sponsors

Professional Web Icons for Your Websites and Applications

Advertise here via BSA

Transit is a super-smooth CSS transitions & transformations for jQuery. You can make transition on any CSS property. They will happen much smoother than if you were to use jQuery’s default .animate(). You can easily translate, rotate, scale, skew and etc.

Transit degrades older browsers by simply not doing the transformations (rotate, scale, etc) while still doing standard CSS (opacity, marginLeft, etc) without any animation. Delays and durations will be ignored. It is released under MIT License.

Requirements: jQuery Framework
Demo: http://ricostacruz.com/jquery.transit/
License: MIT License

Sponsors

Professional Web Icons for Your Websites and Applications

Advertise here via BSA

When I started out on this app I was only really just interested in seeing if the web platform had really evolved to a point where an app like the hugely popular Instagram app could be built using just HTML, JavaScript and CSS. As it turns out we can in fact do exactly that. This article walks you through the technologies that make this possible and shows how it is entirely feasible today to build interoperable web applications that provide a great user experience no matter what brand of browser the user is running.

If you happen to be one of the two or so people who have not heard about Instagram then you might be pleased to hear that it is a hugely popular photo sharing and social networking service that allows you to take pictures, apply interesting digital filters on them and share them with the world to see. The service got so popular that it was acquired by Facebook for a bag full of cash and stock in April of 2012.

InstaFuzz is the name of the app I put together and while I don’t expect to be acquired by Facebook or anybody else for a billion green it does however make the case that an app such as this one can be built using only standards compliant web technologies such as Canvas, File API, Drag/Drop, Web Workers, ES5 and CSS3 andstill manage to runwell on modern browsers such as Internet Explorer 10,Google Chrome and Firefox. And you could easily use the code to build a Windows Store app too.

About the app

If you’d like to take a look at the app, then here’s where it is hosted at:

http://blogorama.nerdworks.in/arbit/InstaFuzz/

As soon as you load it up, you’re presented with a screen that looks like this:

The idea is that you can load up a photograph into the app either by clicking on the big red “Add” button on the bottom left hand corner or drag and drop an image file into the blackish/blue area on the right. Once you do that you get something that looks like this:

You’ll note that a list of digital filters are listed on the left of the screen showing a preview of what the image would look like if you were to apply the said filter. Applying a filter is a simple matter of clicking on one of the filter previews on the left. Here’s what it looks like after applying the “Weighted Grayscale” filter followed by a “Motion Blur”. As you can tell filters are additive – as you keep clicking on filters, they are applied on top of what was applied earlier:

Let’s next take a look at how the UI layout has been put together.

UI Layout

The HTML markup is actually so little that I can actually reproduce the contents of the BODY tag in its entirety here (excluding the SCRIPT includes):

<header>
<divid="title">InstaFuzz</div>
</header>
<sectionid="container">
<canvasid="picture"width="650"height="565"></canvas>
<divid="controls">
<divid="filters-list"></div>
<buttonid="loadImage">Add</button>
<inputtype="file"id="fileUpload"
style="display: none;"
accept="image/gif, image/jpeg, image/png"/>
</div>
</section>

<!-- Handlebar template for a filter UI button -->
<scriptid="filter-template"type="text/x-handlebars-template">
<divclass="filter-container"data-filter-id="{{filterId}}">
<divclass="filter-name">{{filterName}}</div>
<canvasclass="filter-preview"width="128"height="128"></canvas>
</div>
</script>

There’s nothing much going on here. Pretty much everything should be standard fare. I will however draw attention to the fact that I am using the Handlebars JavaScript templating system here for rendering the markup for the list of filters on the left of the screen. The template markup is declared in the HTML file (the SCRIPT tag in the snippet shown above) and then used from JavaScript. The template markup is then bound to a JavaScript object that supplies the values for handlebars expressions such as {{filterId}}and {{filterName}}. Here’s the relevant piece of JS from the app with a bit of DOM manipulation help from jQuery:

var templHtml = $("#filter-template").html(),
template = Handlebars.compile(templHtml),
filtersList = $("#filters-list");
var context = {
filterName: filter.name,
filterId: index
};

filtersList.append(template(context));

As you can tell from the HTML markup all the filter preview boxes feature a CANVAS tag as does the big box on the right where the final output is rendered. We’ll go into a bit more detail later on in the article as to how canvas technology is used to achieve these effects.
The app also usesCSS3 @font-face fonts to render the text in the header and the “Add” button. The fonts have been taken from the excellent Font Squirrel site and here’s what the declaration looks like:

@font-face {
font-family: 'TizaRegular';
src: url('fonts/tiza/tiza-webfont.eot');
src: url('fonts/tiza/tiza-webfont.eot?#iefix')
format('embedded-opentype'),
url('fonts/tiza/tiza-webfont.woff')format('woff'),
url('fonts/tiza/tiza-webfont.ttf')format('truetype'),
url('fonts/tiza/tiza-webfont.svg#TizaRegular')format('svg');
font-weight: normal;
font-style: normal;
}

This directive causes the user agent to embed the font in the page and make it available under the name assigned to the font-family rule which in this case is “TizaRegular”. After this we can assign this font to any CSS font-family rule like how we normally do. In InstaFuzz I use the following rule to assign the font to the header element:

font-family: TizaRegular, Cambria, Cochin, Georgia, Times,
"Times New Roman", serif;

You might also have noticed that there is a subtle shadow being dropped on the page by the container element.

This is made possible using the CSS3 box-shadow rule and here’s how it’s used in InstaFuzz.

-moz-box-shadow: 1px0px4px#000000, -1px-1px4px#000000;
-webkit-box-shadow: 1px0px4px#000000, -1px-1px4px#000000;
box-shadow: 1px0px4px#000000, -1px-1px4px#000000;

This causes the browser to render a shadow around the relevant element. Each comma separated section in the value specifies the following attributes of the shadow:

1. Horizontal offset
2. Vertical offset
3. Spread distance – positive values have the effect of softening the shadow
4. Shadow color

One can specify multiple shadow values separated by comma as in fact has been done above. Note that I’ve also specified the shadow using vendor prefix syntax for Firefox and Chrome/Safari using the moz and webkit prefixes. This causes the shadow to continue to work in versions of those browsers where support for this capability was provided using the vendor prefixed version of the rule. Note that the W3C version of the rule – box-shadow – is specified last. This is done deliberately to ensure that in case the browser supports both the forms then only the W3C behavior is actually applied to the page.

One often finds that web developers either fail to include vendor prefixed version of a given CSS3 rule for all the browsers that support that rule and/or fail to include the W3C version as well. Often developers just put the webkit version of the rule ignoring other browsers and the W3C standard version. This causes two problems – [1] poor user experience for users who are using non-webkit browsers and [2] it ends up resulting in webkit becoming a de-facto standard for the web. Ideally we want W3C to be driving the future of the web and not one specific browser implementation. So here are some things to remember when playing with experimental implementations of CSS features:

1. Use vendor prefixed versions of CSS rules by all means but remember to specify the rule for all supported browsers and not just the one that you happen to be testing the page in (if you’re using Visual Studio to edit your CSS then you might be interested in the supremely excellent extension for Visual Studio called Web Essentials that makes the job of managing vendor prefixes about as simple as it can possibly get).
2. Remember to specify the W3C version of the rule as well.
3. Remember to order the occurrence of the rules so that the W3C version shows up last. This is to allow clients that support both the vendor prefixed version and the W3C version to use the W3C specified semantics for the rule.

Drag/Drop

One of the things that InstaFuzz supports is the ability to drag and drop image files directly on to the big blackish/blue box. Support for this is enabled by handling the “drop” event on the CANVAS element. When a file is dropped onto an HTML element the browser fires the “drop” event on that element and passes in a dataTransfer object which contains a files property that contains a reference to the list of files that were dropped. Here’s how this is handled in the app (“picture” is the ID of the CANVAS element on the page):

var pic = $("#picture");
pic.bind("drop", function (e) {
suppressEvent(e);
var files = e.originalEvent.dataTransfer.files;
// more code here to open the file
});
pic.bind("dragover", suppressEvent).bind("dragenter", suppressEvent);
functionsuppressEvent(e) {
e.stopPropagation();
e.preventDefault();
}

The files property is a collection of File objects that can then subsequently be used with the File API to access the file contents (covered in the next section). We also handle the dragover and dragenter events and basically prevent those events from propagating to the browser thereby preventing the browser from handling the file drop. IE for instance might unload the current page and attempt to open the file directly otherwise.

File API

Once the file has been dropped, the app attempts to open the image and render it in the canvas. It does this by using the File API. The File API is a W3C specification that allows web apps to programmatically access files from the local file system in a secure fashion. In InstaFuzz we use the FileReader object to read the file contents as a data URL string like so using the readAsDataURLmethod:

var reader = newFileReader();
reader.onloadend = function (e2) {
drawImageToCanvas(e2.target.result);
};
reader.readAsDataURL(files[0]);

Here, files is the collection of File objects retrieved from the function handling the “drop” event on the CANVAS element. Since we are interested only in a single file we simply pick the first file from the collection and ignore the rest if there are any. The actual file contents are loaded asynchronously and once the load completes, the onloadend event is fired where we get the file contents as a data URL which we then subsequently draw on to the canvas.

Rendering the filters

Now the core functionality here is of course the application of the filters. In order to be able to apply the filter to the image we need a way to access the individual pixels from the image. And before we can access the pixels we need to have actually rendered the image on to our canvas. So let’s first take a look at the code that renders the image that the user picked on to the canvas element.

Rendering images on to the canvas

The canvas element supports the rendering of Image objects via the drawImage method. To load up the image file in an Image instance, InstaFuzz uses the following utility routine:

App.Namespace.define("InstaFuzz.Utils", {
loadImage: function (url, complete) {
varimg = new Image();
img.src = url;
img.onload = function () {
complete(img);
        };
    }
});

This allows the app to load up image objects from a URL using code such as the following:

functiondrawImageToCanvas(url) {
InstaFuzz.Utils.loadImage(url, function (img) {
// save reference to source image
sourceImage = img;

mainRenderer.clearCanvas();
mainRenderer.renderImage(img);

// load image filter previews
loadPreviews(img);
    });
}

Here, mainRenderer is an instance created from the FilterRenderer constructor function defined in filter-renderer.js. The app uses FilterRenderer objects to manage canvas elements – both in the preview pane as well as the main canvas element on the right. The renderImage method on the FilterRenderer has been defined like so:

FilterRenderer.prototype.renderImage = function (img) {
varimageWidth = img.width;
varimageHeight = img.height;
varcanvasWidth = this.size.width;
varcanvasHeight = this.size.height;
var width, height;

if ((imageWidth / imageHeight) >= (canvasWidth / canvasHeight)) {
width = canvasWidth;
height = (imageHeight * canvasWidth / imageWidth);
    } else {
width = (imageWidth * canvasHeight / imageHeight);
height = canvasHeight;
    }

var x = (canvasWidth - width) / 2;
var y = (canvasHeight - height) / 2;
this.context.drawImage(img, x, y, width, height);
};

That might seem like a lot of code but all it does ultimately is to figure out the best way to render the image in the available screen area considering the aspect ratio of the image. The key piece of code that actually renders the image on the canvas occurs on the last line of the method. The context member refers to the 2D context acquired from the canvas object by calling itsgetContext method.

Fetching pixels from the canvas

Now that the image has been rendered we will need access to the individual pixels in order to apply all the different filters that are available. This is easily acquired by calling getImageData on the canvas’s context object. Here’s how InstaFuzz calls this from instafuzz.js.

varimageData = renderer.context.getImageData(
    0, 0,
renderer.size.width,
renderer.size.height);

The object returned by getImageData provides access to the individual pixels via its data property which in turn is an array like object that contains a collection of byte values where each value represents the color rendered for a single channel of a single pixel. Each pixel is represented using 4 bytes that specify values for the red, green, blue and alpha channels. It also has a lengthproperty that returns the length of the buffer. If you have a 2D co-ordinate you can easily transform that into an index into this array using code such as the following. The color intensity values of each channel ranges from 0 through 255. Here’s the utility function from filters.js that accepts as input an image data object along with 2D coordinates for the pixel the caller is interested in and returns an object containing the color values:

functiongetPixel(imageData, x, y) {
var data = imageData.data, index = 0;

// normalize x and y and compute index
    x = (x < 0) ? (imageData.width + x) : x;
    y = (y < 0) ? (imageData.height + y) : y;
index = (x + y * imageData.width) * 4;

return {
r: data[index],
g: data[index + 1],
b: data[index + 2]
    };
}

Applying the filters

Now that we have access to the individual pixels, applying the filter is fairly straightforward. Here, for instance is the function that applies a weighted grayscale filter on the image. It simply picks intensities from the red, green and blue channels and sums them up after applying a multiplication factor on each channel and then assigns the result for all 3 channels.

// "Weighted Grayscale" filter
Filters.addFilter({
name: "Weighted Grayscale",
apply: function (imageData) {
var w = imageData.width, h = imageData.height;
var data = imageData.data;
var index;
for (var y = 0; y < h; ++y) {
for (var x = 0; x < w; ++x) {
index = (x + y * imageData.width) * 4;
var luminance = parseInt((data[index + 0] * 0.3) +
                                         (data[index + 1] + 0.59) +
                                         (data[index + 2] * 0.11));
	data[index + 0] = data[index + 1] =
data[index + 2] = luminance;
            }

Filters.notifyProgress(imageData, x, y, this);
        }

Filters.notifyProgress(imageData, w, h, this);
    }
});

Once the filter has been applied we can have that reflected on the canvas by calling the putImageData method passing in the modified image data object. While the weighted grayscale filter is fairly simple most of the other filters use an image processing technique known as convolution. The code for all the filters is available in filters.js and the convolution filters were ported from the C code available here.

Web Workers

As you might imagine doing all this number crunching to apply the filters can potentially take a long time to complete. The motion blur filter for instance uses a 9×9 filter matrix for computing the new value for every single pixel and is in fact the most CPU intensive filter among them all. If we were to do all this computation on the UI thread of the browser then the app would essentially freeze every time a filter was being applied. To provide a responsive user experience the app delegates the core image processing tasks to a background script using the support for W3C Web Workers in modern browsers.

Web workers allow web applications to have scripts run in a background task that executes in parallel along with the UI thread. Communication between the worker and the UI thread is accomplished by passing messages using the postMessage API. On both ends (i.e. the UI thread and the worker) this manifests as an event notification that you can handle. You can only pass “data” between workers and the UI thread, i.e., you cannot pass anything that has to do with the user interface – you cannot for instance, pass DOM elements to the worker from the UI thread.

In InstaFuzz the worker is implemented in the file filter-worker.js. All it does in the worker is handle the onmessage event and apply a filter and then pass the results back via postMessage. As it turns out, even though we cannot pass DOM elements (which means we cannot just hand a CANVAS element to the worker to have the filter applied) we can in fact pass the image data object as returned by the getImageDatamethod that we discussed earlier. Here’s the filter processing code from filter-worker.js:

importScripts("ns.js", "filters.js");

var tag = null;
onmessage = function (e) {
var opt = e.data;
varimageData = opt.imageData;
var filter;

tag = opt.tag;
filter = InstaFuzz.Filters.getFilter(opt.filterKey);

var start = Date.now();
filter.apply(imageData);
var end = Date.now();

postMessage({
type: "image",
imageData: imageData,
filterId: filter.id,
tag: tag,
timeTaken: end - start
    });
}

The first line pulls in some script files that the worker depends on by calling importScripts. This is similar to including a JavaScript file in a HTML document using the SCRIPT tag. Then we set up a handler for the onmessage event in response to which we simply apply the filter in question and pass the result back to the UI thread by calling postMessage. Simple enough!
The code that initializes the worker is in instafuzz.js and looks like this:

var worker = new Worker("js/filter-worker.js");

Not much is it? When a message is sent by the worker to the UI thread we handle it by specifying a handler for the onmessage event on the worker object. Here’s how this is done in InstaFuzz:

worker.onmessage = function (e) {
varisPreview = e.data.tag;
switch (e.data.type) {
case"image":
if (isPreview) {
previewRenderers[e.data.filterId].
context.putImageData(
e.data.imageData, 0, 0);
            } else {
mainRenderer.context.putImageData(
e.data.imageData, 0, 0);
            }

break;
// more code here
    }
};

The code should be fairly self-explanatory. It simply picks the image data object sent by the worker and applies it to the relevant canvas’s context object causing the modified image to be rendered on screen. Scheduling a filter for conversion with the worker is equally simple. Here’s the routine that performs this function in InstaFuzz:

functionscheduleFilter(filterId,
renderer,
img, isPreview,
resetRender) {
if (resetRender) {
renderer.clearCanvas();
renderer.renderImage(img);
    }

varimageData = renderer.context.getImageData(
        0, 0,
renderer.size.width,
renderer.size.height);

worker.postMessage({
imageData: imageData,
width: imageData.width,
height: imageData.height,
filterKey: filterId,
tag: isPreview
    });
}

Wrapping it up

The source for InstaFuzz is available for download here. We saw that fairly intricate user experiences are possible today with HTML5 technologies such as Canvas, Drag/Drop, File API and Web Workers. Support for all of these technologies is quite good in pretty much all modern browsers. One thing that we did not address here is the question of making the app compatible with older browsers. That, truth be told, is a non-trivial but necessary task that I will hopefully be able to talk about in a future article.

This article is part of the HTML5 tech series from the Internet Explorer team. Try-out the concepts in this article with three months of free BrowserStack cross-browser testing @ http://modern.IE

About the Author

Rajasekharan Vengalil is a self-proclaimed nerd working for a company called Microsoft. He is part of their Development and Platform Evangelism team which basically means that he gets to learn all about interesting new nerdy stuff that comes out of Microsoft and then talk about it with people (like building an app in HTML5. He thinks he’s really lucky to be paid for doing what he’d anyway be doing for free!

Sponsors

Professional Web Icons for Your Websites and Applications